Regarding fast data transfer:
That was my first thought if auto-incrementation would work:

Hmm, I guess you wanted to exchange every two bytes but it's not needed. So I guess, that's enough:


As far as I can see (from code examples in datasheet) for 8 bit FIFO transfer, bytes are still in the "good order", eg, reading the network packet contain "abcde" would result in the following scheme:

IDM_DR0 reads as "a"   (always start with IDM_DR0!!)
IDM_DR1 reads as "b"
IDM_DR0 reads as "c"
IDM_DR1 reads as "d"
IDM_DR0 reads as "e"
IDM_DR0 reads as SOMETHING, since always _even_ number of transfer needed, but in our case you need to ignore this byte but you MUST read it!

This also means that you need always start with IDM_DR0 and end with IDM_DR1 and you must be careful to use this strict "altering" method of using I/O ports, so w5300's internal counter in buffer won't go mad (as it would use that for 16 bit ops, but we use w5300 in 8 bit mode!).

Actually, this can be surprising because of the opposite byte order of w5300 what we're used with Z80, but still, RX/TX FIFO stuffs seems to be "the right order". This is because (I think!) giving eg network port, it's a 16 bit value, so it's really high byte FIRST, then low byte, but TX/RX buffers DOES NOT contain 16 bit values, but 8 bit bytes! So maybe byte order simply does not apply here too much because of the nature of byte grained data. Still, the bus interface of w5300 is 16 bit oriented with "8 bit mode hack" so you need to access this altering order of ports and always even numbers (which would be natural in 16 bit I/O + bus mode).

What is also important still: if there is even number of bytes to be read/written, there is nothing special. If you need odd number of bytes, then you need to read one more bytes to be even number (and ignoring the last byte), or send a dummy byte if it's a write op for TX FIFO. That's natural, as w5300 expect word I/O, so for 8 bit I/O it's n * 2 ops of 8 bits (n would be the number of 16 bit I/O ops needed), thus it is always even number of 8 bit ops then as n * 2 for any n is always even!

Again, this is my understanding of the situation! It can be wrong ...

Great, thanks LGB and Bruce for the clarification! These are good news, transfering data will be very fast!
I am currently working on the DHCP implementation, but as soon as it makes sense I can start with the W5300 driver for the Enterprise.

But I think SymbOS needs generic, SymbOS-platform-independent DHCP implementation anyway user can modify settings also other platforms may not have this job done already, etc etc ...

Yes, exactly. As soon as there is EXOS support for EPNET it makes sense to set the IP and DNS config there (including DHCP usage).
On the MSX there is a tool for MSX-DOS for this task as well, but it is optional.
The Amstrad CPC probably won't have this (at the beginning).
So it's necessary to have it in SymbOS, too. DHCP is a nice "nice to have" feature but it makes the whole solution more completed.

Nice find lgb - thanks for that, that clarifies it! INI, INC/DEC C is still one T faster than one INIR interation so maybe not *quite* as fast an an "unrolled" plain INIR but I can certainly live with that!

Yes I agree, I would hope DHCP could be done at startup by the EXOS device/code but there is probably a case for being able to set the subnet, ip etc manually too, even if just for testing (the w5300 really ought to doing the DHCP stuff!). I am now wondering whether the "use DHCP y/n" setting and the manually-set subnet & ip should be stored in flash along with the MAC address.

It might be a bit of pain as I'm not using interrupts - might have to have an EXOS timer interrupt and do it from there. The alternative is to do it synchronously on the first application EXOS call.

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.

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.

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.

Yes, but for not-so techy people, I guess this is a must. At the other hand, maybe not my mother will run SymbOS. Or use EP. Or EPNET

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.

16 bit is an issue, the specification says as something like "it is NOT allowed to access any other w5300 register than low byte of the FIFO if high byte is already accessed before" (that is, in indirect mode: IDM_DR1 must be accessed if IDM_DR0 has been  accessed before, and you can't even set another register to be selected with IDM_AR before you complete a 16 bit access. It seems this strict access method is only for the FIFO registers, others can be accessed for only a "8 bit half" of the register and continue with another register then!). So you must read (or writes) even number of bytes, always. Thus. if app wants odd number of bytes, you still need to buffer (ie in your network daemon, whatever) at least one byte! Of course if it was last byte in RX  buffer, you read two bytes from FIFO but ignore the other (and then not buffer).

Quoted from the specification (page 87):

"If  the host system  uses  8  bit  data  bus  width,  Sn_TX_FIFOR0  and  Sn_TX_FIFOR1  should  be accessed  in  a  pair.  When  copying  1 byte  data  into  internal  TX  memory, the host  writes  the  1 byte data in Sn_TX_FIFOR0 and dummy data in Sn_TX_FIFOR1. Sn_TX_FIFOR should be accessed with 2 byte size. Access the Sn_TX_FIFOR0 of low address register  first, and the Sn_TX_FIFOR1 of high address register. After accessing Sn_TX_FIFOR0, it is not allowed to access other W5300 registers except for Sn_TX_FIFOR1."

Of course, it translates a bit different for indirect mode, since there it means writing IDM_AR to be able to use other register, and IDM_DR1 for the already selected Sn_TX_FIFOR1 for example. Thus, if IDM_AR is set for the Sn_TX_FIFOR and then you accessed for write IDM_DR0 then you _must_ and _can only_ access IDM_DR1 not any other register. As far as I can see. The same for the other direction (RX FIFO reg).

For the RX direction (page 88):

"If  the host system uses  8  bit  data  bus  width,  Sn_RX_FIFOR0  and  Sn_RX_FIFOR1  should  be accessed  in  a  pair  as  like  Sn_TX_FIFOR.  It  is  not  allowed  to  access  Sn_RX_FIFOR0  and Sn_RX_FIFOR1  right  after  accessing  Sn_TX_FIFOR0  and  Sn_TX_FIFOR1.  Theseare  cause for the incorrect read.   In   order   to   prevent   this,   after   reading   Sn_TX_FIFOR0   and Sn_TX_FIFOR1, the host reads any register such as Sn_MR and then access Sn_RX_FIFOR. When the host reads the received DATA packet in internal RX memory through Sn_RX_FIFORby 2 bytes, the low and high data in internal RX memory can be readthrough Sn_RX_FIFOR0 and  Sn_RX_FIFOR1respectively.  The host  performs  RECV  command  after  processing the received DATA packet in internal RX memory. "

So about the same issue but for another direction. What seems to be odd for me, this RECV command ... If reading RX FIFO reg updates w5300 internal pointer stuff etc for the socket RX buffer, what exactly does. I had not so much time to try to analyze this part of the specification yet! Also for RX there seems to be more rules given by the spec, see what I've copied here above. Unfortunately I hadn't much time too much at the weekend, still I would need time to try to understand these. I guess ...

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.