Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Prodatron

Pages: 1 2 [3] 4 5 6 7 8 9 10 ... 17

Programming / Re: SymbOS

« on: 2016.June.19. 23:47:41 »

Hi guys, sorry for being silent for such a long time again.
I made a break of about 5 month regarding Z80 activities, but I guess I am back now. I finished a CPU meter widget...

...to get back into the material, that was a nice little re-entry project.
TBH I am f*ing impressed by Gflorez mouse driver patch! That's awesome!
Because of the CPU meter widget I am now working on a weather widget, as I am currently into this topic. Next step will be finishing the 3.0 release version of SymbOS, and it seems, the main work for this are the EP modifications (especially the floppy disc driver and the mouse driver).
Anyway I will be more than happy to release 3.0 this year... (now it's 10 years ago when 1.0 has been released)

Programming / Re: SymbOS

« on: 2016.February.22. 23:05:24 »

Thanks for the hint, Zozo!
I am afraid that it doesn't make sense to add this to the "usual" version of SymbOS (which also works on 128K machines), as it requires several changes in the kernel.
But there is still the plan to have the "expanded" EP version of SymbOS after the 3.0 release, which only runs on expanded machines (192K or more) and uses a higher screen resolution. This would always keep the #FF segment free for EXOS.

Programming / Re: SymbOS

« on: 2016.February.22. 22:29:08 »

Hi Guys, I am planning to release SymbOS 3.0 soon in May, so it's time to remove the last issues for the Enterprise as well!
The two important things on my ToDo list regarding the EP are currently these ones:
- fix the FDC timing issues
- add full support for the EnterMice
I don't remember about any other EP-related critical bugs, but maybe I missed something?

Programming / Re: UnZIP ("Deflate") tool for Z80 machines - any interests? :)

« on: 2015.November.17. 07:19:03 »

Sorry, now I got you, here are the latest source codes of the "object oriented" way of the implementation (by Grauw):
https://bitbucket.org/grauw/gunzip/src
See especially the folder /src/deflate/ , the main file is "inflate.asm".

And this is the version without the OOP-approach, which is more optimized and faster (by Wouter):
https://github.com/m9710797/msx-gunzip/blob/master/src/gunzip.asm

Both should be 100% stable,
the second one is the faster one, the first is a nice demonstration how to do object oriented programming in Z80 assembler.
My own version is similiar to the second one, but not 100% finished yet.

Programming / Re: UnZIP ("Deflate") tool for Z80 machines - any interests? :)

« on: 2015.November.16. 21:26:23 »

Quote from: Zozosoft on 2015.November.16. 20:48:49

Which is the latest/best version sources from the many versions?

I hope to get it finish this week. It's a little bit crazy but only because of this new UnZIP tool I discovered a 10,5 years old bug in SymbOS itself. I will publish both, so hopefully soon you will have a full working Un(G)Zip tool on the EP as well

Programming / Re: UnZIP ("Deflate") tool for Z80 machines - any interests? :)

« on: 2015.November.16. 20:46:46 »

For the command line interface (SymShell) it's more easy, so I started this one.

But a GUI based applications will follow as well, it's not that difficult

Programming / Re: UnZIP ("Deflate") tool for Z80 machines - any interests? :)

« on: 2015.November.12. 16:09:08 »

Quote from: Zozosoft on 2015.November.12. 15:52:06

Many years ago I searched about unzip for Z80, but don't found.

The only other Z80 based project I know is Samflate for the Sam Coupe:
http://sourceforge.net/projects/samflate/
The advantage of the Deflate algorithm is the fact, that the size of the dictionary is "only" 32KB. So it can still be handled by the Z80 within the visible address room in a good way. Most other modern compression algorithms are working with (much) larger dictionaries. And ZIP is still the most popular format.

Programming / UnZIP ("Deflate") tool for Z80 machines - any interests? :)

« on: 2015.November.12. 15:48:26 »

Hi guys,

in the MSX scene there is currently a rush regarding UnZIP tools, which are based on the "deflate" algorythm, which is used for ZIP archives, GZIP (GZ) files, PNG graphics etc.
- GuyveR800 released the first UnZIP tool for ZIP archives ever for the MSX in July this year
- Grauw released the first version of Gunzip in October, which is for GZ(ip) files
- as it's open source Louthrax was able to release his tool SofaUnZip for ZIP archives only 9 days later, which can even handle long filenames and subdirectories
- Grauw and Wouter managed to improve the speed of the uncompressor a lot, and so yesterday Wouter released his modified version of the Deflate uncompressor as well
- I am currently working on a version for SymbOS

So we will have 5 different Un(G)Zip tools for the MSX within one year, which is quite funny. The SymbOS version, which will support both ZIP and GZ files, of course will run on all supported platforms, so on the EP as well

I just wonder if someone is interested in building a version for EXOS directly? Using the source codes of Grauw or Wouter should be quite easy (I will release my as well as soon as it is finished).

CU,
Prodatron

Input devices / Re: EnterMice (Joy & PS/2 mouse interface)

« on: 2015.October.23. 14:46:28 »

Wow, good to see this progress here. I haven't been around here since some time unfortunately.

Is it still possible to be added to the order-list? I would like to take 3 of them.

Of course I want to support it in SymbOS. Will be back on the Enterprise in the middle of november again

Hardware / Re: Wiznet 5100/5300 /etc and Enterprise

« on: 2015.July.06. 14:49:31 »

Quote from: lgb on 2015.July.06. 14:02:42

what is the purpose of RECV command, if it is even not interesting when you send it to the w5300? That's why I think it has some important role, just we don't know what. Because if it wouldn't have importance at all, why would it be designed to be used? I am confused with this question a lot.

I think it's only to tell the W5300, that the buffer size changed. The buffer memory is the only place, which stores the information about the received packages (packet_info + data). But it's still only a FIFO buffer/data stream. So why should it be important to fetch the complete package?

Quote

Well, a TCP packet can carry some informations (like ACK) even with no data payload at all.

The example code on page 95 seem to send exactly 1 byte:

Code: [Select]

/* set RECV command */
Sn_CR = RECV;
/* Add the code that notifies the update of window size to the peer */
/* check the received data process to finish or not */
if(Sn_RX_RSR == 0) /* send the window-update packet when the window size is full */
{ /* Sn_RX_RSR can be compared with another value instead of ‘0’,
according to the host performance of receiving data */
    Sn_TX_WRSR = 0x00000001; /* set Dummy Data size to Sn_TX_WRSR */
    Sn_TX_FIFOR = 0x0000; /* Write Dummy Data into TX memory */
    Sn_CR = SEND; /* set SEND command */
    while(Sn_CR != 0x00); /* check SEND command completion */
    while(Sn_IR(SENDOK) == ‘0’); /* wait for SEND OK */
    Sn_IR(SENDOK) = ‘1’; /* Clear SENDOK bit */
}

When using a TCP connection with the W5300 there doesn't seem to be a possibility just to send an ACK package.

Hardware / Re: Wiznet 5100/5300 /etc and Enterprise

« on: 2015.July.06. 12:45:52 »

Quote from: lgb on 2015.July.06. 10:46:06

Yes, that's not a little amount of RAM Ok, you can say - in theory - that it's not problem that w5300 can't receive more packets on that socket, as the app is not interested in more bytes yet, so the reason not all bytes are read.

I still wonder what happens, if you read less bytes from the RX_FIFO than stated in the last PACKET_INFO and then send a RECEIVE command. Later you can still read the remaining bytes of the current packet (and send RECEIVE again), as you still know how much bytes are left. It would be strange, if this shouldn't work, as for the W5300 these are only bytes in its memory and nothing else. In this case you don't need these 8x1500 byte buffers on EP side. But who knows...

Quote from: lgb on 2015.July.06. 10:46:06

The specification is a bit messy here, mentioning, that you can force the window size update with an empty packet sending.

I just read that, and this seems to be a solution for such a problem that I sometimes have with the W5100 - the connection is sometimes stalled when receiving a lot of incoming data! But I think it's not possible to send an empty package? In the example the dummy data still has a size of 1 byte. Couldn't this cause issues with some protocols?

Hardware / Re: Wiznet 5100/5300 /etc and Enterprise

« on: 2015.July.05. 23:33:15 »

Quote from: lgb on 2015.July.05. 23:26:51

Yes. What I don't understand too much still, what exactly RECV command does, if internal (not transparent to the programmer) counters/pointers for buffers are maintained anyway on each FIFO reg access? According to spec, RECV command notifies that the host (we) received the data packet. Hmm.

"After memory copy, the host should inform the copy completion of data to W5300 by RECV command."

This sentence does not tell: after what kind of copy? A whole packet? Or every packets can be found in RX buffer? And why?

For the W5100 it only tells, that (after we copied a special amount of bytes from the buffer) we updated the pointers. It seems, that the W5100 doesn't poll the pointers but requires this command to know, that the pointers have been modified (which makes sense). I hope or guess, that it's the same for the W5300?

Hardware / Re: Wiznet 5100/5300 /etc and Enterprise

« on: 2015.July.05. 21:52:57 »

Quote from: lgb on 2015.July.05. 20:46:42

Hmm, that sounds odd for me. Because, what happens if you already read the packet info byte from RX buffer describing the data size, but meanwhile new packet arrives? The old packet info cannot be modified as it's already read ... That's why I thought, the new packet is stored then with its own packet-info word in the RX buffer. What I also suspected that the TCP aligned mode is just for that you mentioned: then it's one stream without any packet info in TCP mode.

Ah OK, I got your point now, but I'm afraid it's not so OK with the w5300! Just checked the "w5100 vs w5300" spec from Wiznet. It seems w5100 works like you mentioned, but w5300 does not, and it has packet info even in TCP mode (not just in UDP, though it's much more simple, only a word for packet size in TCP mode). Unless if you set TCP aligned mode. I think the difference is because w5300 being so much 16 bit organized (and maybe w5100 is not? I don't know). Thus, if TCP data would be one stream with w5300 as you mentioned then there will be problem that an odd sized packet followed by a newer packet you wouldn't know that a byte should be skipped because it's just for the word alignment "dummy" byte. That is exactly what is TCP aligned mode is for: according the specification if you are SURE that only even sized packets received (that's something I find funny, because how you can be sure ...), you can set TCP align mode, and indeed, then it will work as you mentioned: a single stream without header in TCP mode. Just because of the facts above, I doubt it's useful with that constraint we can't be sure about in a general TCP/IP solution at least (I can imagine that with a specific protocol a designer can make sure about this ...). Or it's also possible that I misunderstood something, of course.

It seems it's kinda handy to read that w5100 vs w5300 comparsion sheet from Wiznet. For me it does not mean too much (as I don't know w5100) but for you, it can be useful.

Ops, ok, I also had a look in the W5300 manual again, and yes, there is this word in front of every package.
Ok, TCP aligned mode doesn't sound good, as it is always possible to receive packages with an odd number of bytes (best example: Telnet, where you sometimes send one single bytes in one whole package).
Because of the 16bit issue this length word in front of each package makes sense!
So my next idea is to store the word in front of the package in your socket handler. When the app only requests a smaller amount of bytes you update the remaining length in your handler. If you reach the end of the package you fetch the next length word and so on. This requires a little bit more code than the "stream" solution of the W5100 (yes, here everything is just completely byte-based!), but it should still work fine!
And now I also understand how they manage any odd package sizes without problems in the RX buffer when still having this 16bit stuff. That's really interesting!

Hardware / Re: Wiznet 5100/5300 /etc and Enterprise

« on: 2015.July.05. 20:29:31 »

Quote from: lgb on 2015.July.05. 19:22:53

Honestly, I am a bit lost here with the specification (of w5300, I mean). Many things are not clear for me, ie it says packet-info word tell the size. But what happens, if multiple packet arrived before we could process? What I can imagine, that if you read FIFO RX you will get packet info which tells the number of bytes in the packet. After reading that, and still bytes in the RX buffer (according to fifo rx size) reading a word will find the next received packet's packet-info word with its length, so I know how many bytes should be read. Well, I think What I don't know, where and how RECV command is needed (fromt he spec it seems it is some kind of acknowledgement only that we really read X words, and it has no any other purposes?), and why, if internal counter of RX FIFO "knows" how much data is already transferred to the host (so: EP) from the RX buffer.

You only have separated packets with own headers in the RX buffer in UDP mode. In TCP mode the whole data is one "stream" (no single packets). At least this is how it works for the W5100.

Hardware / Re: Wiznet 5100/5300 /etc and Enterprise

« on: 2015.July.05. 15:25:15 »

Quote from: lgb on 2015.July.05. 14:38:56

I already took a look on the DHCP protocol some weeks ago, hmm, it's multiple-time rounds between the client and the server, it sounded a bit complicated at the first glance. But it seems I have to "emulate" a DHCP server somehow

DHCP implementation had quite a low priority for me, as it is only a luxury feature for lazy users

It is not important, as you can use a fixed IP/DNS configuration.
But the protocol seems to be quite easy. The reason for sending two packets on both sides (discover ->, offer <-, request ->, <- acknowledge) is probably the fact, that you can have more than one DHCP server in your local network, and the client has to make a choice after the discovery stage and tell its decission to all others.

Quote from: lgb on 2015.July.05. 15:10:42

if data is received and we can read RX FIFO I guess we must (?) read the whole byte stream (packet data?) received, but EXOS function may ask for a single byte to read only! What happens then? Should we have a buffer in EP too for EXOS to store received bytes, in case if EXOS app wants to read less bytes only?

No, that's not necessary. You can read less bytes than received from the RX buffer, you will just update the buffer pointer then in the correct way. The only thing I wonder is, if you always have to read and skip even number of bytes from the buffer because of the 16bit issue.

Regarding DHCP/DNS and interrupts: These operations work usually quite fast, so maybe you could stay in the routine until the process is finished. In SymbOS I poll the network hardware every 1/50second, which works fine as well.

Pages: 1 2 [3] 4 5 6 7 8 9 10 ... 17