Glad to hear that it's going on! Time to have a closer look at the W5300 programming again...

Cool, good news, thanks a lot!!

Ah yes, I didn't have the 10MHz in mind. I had a look at it again.
Using 8-1-1-1 instead of 8-5-5-5 would save 84 microseconds on a 4MHz system per 50Hz frame, which is not so much (1,3 Rasterlines). SymbOS does a speed detection at the beginning, which could be used for modifying the mouse routine, but then you can't switch to 10MHz when you booted it in 4MHz mode. Anyway my next EP specific work will be fixing the remaining FDC issues.

But this is an intolerable situation..... Mouses for the masses! Mices for everybody!

I totally agree!

My first thought about the RTC was, that you don't need an RTC anymore if you have network, as you can get the time from the internet after startup and you are fine. The small included RAM is an interesting point. But especially because of the multi-platform way I would always store all settings in an INI file, which is loaded, when the network daemon is starting. This is probably different, when we speak about a ROM solution, which should be independant of mass storage devices.

Good to hear, that DNS is easy. It's what I am starting now to implement, since the UDP routines are finished. About DHCP, the way I am currently doing it on the MSX is exactly the way you described! I let the DenYoNet rom do the initialisation with DHCP in MSX-DOS, and after this I boot SymbOS. So the Wiznet already has all its basic network settings.
Didn't know that DHCP requires MacRaw. I thought that even without any network setting you are able to broadcast UDP packets. Anyway not so important now, I think this is one of the last items on the list!

Maybe, but you can place downloadable EP programs with both of HTTP and FTP accessible  anyway I am not sure of wiznet supports for FTP "by hardware", FTP is a quite old and brain-dead protocol (I know because of being administrator of firewalls) which opens new data connection and there is active/passive version, 7/8 bit transfer, etc, For example traditionally "listing" the content of a directory on an FTP server means remote executing the 'ls' program on the server and grabbing the output (the format is even not so standard ...) though modern FTP servers work differently because of security and performance reasons as well. I always try to avoid using FTP if possible. HTTP also allows to "download" files (not just web pages) so I prefer HTTP everywhere. But if wiznet chips supports FTP as well, why not, of course.

Oh, I didn't know that FTP is sooo bad. Dr.Zed coded the SymFTP client in 2007 and it seemed to work fine, but maybe not for all servers. Soon I should be able to resurrect it again
The Wiznet doesn't include any implementations for the application layer. So you have to implement FTP, HTTP etc. (using TCP) but also DNS and DHCP (using UDP) by yourself.

The other thing: accessing the "registers" can be done in two ways: indirect access only needs some ports, basically some allocated I/O ports would be OK. The direct access is different it needs 10 bit addressing information (if I remember correctly now). We can say, that indirect access is OK too, and it's more simple, but at the other hand it can be slower, as accessing a register needs extra work first (specifying the register number or so).

At least with the W5100 you have 4 ports, if you are using the indirect access mode:
- Port 1: accessing the MODE register directly; this is needed, as only with this register you activate the indirect access mode
- Port 2,3: set address (high, low); here you select the address (0-32767 for the W5100)
- Port 4: data read/write; after setting the address you can read or write to the W5100 by using this port; addresses are incremented automatically, so when reading a sequence of bytes you only need to set the address once

The W5300 seems to be a little bit different here due to its larger ram, but I guess in principle it's still something like this.
Anyway, if it's easier to develop the hardware for the EP by using indirect access mode (so only 4 ports are needed), I would go for it! On the CPC it will be implemented in this way, too (and I already did the routines for this way of interface ). The reason is, that it doesn't matter so much, if you loose a little bit CPU time when you access the registers in the indirect way. The code for the CPC indirect access interface is even smaller than the code for the MSX memory mapped interface, as here you have to take care about where your own code and your own data buffers are located and all these slot switching stuff.
The important thing is the data transfer. In indirect mode you use INIR/OTIR instead of LDIR (or the unrolled variant). This is only a little bit slower but in my opinion still fine - we are still speaking about loading some hundret KB of internet data to our Z80 system in seconds
At the end its the decission of the hardware developer, and I am no expert here at all. But I am already prepared for both solutions

Thanks for the information! Though I am not sure I can understand: afaik 5100 (5300 at least ...) has hardware level of tcp/ip implementation with an embedded MCU for real, or such. Thus you don't need to implement low level stuffs like with an ENC28J60 (ethernet frame, IP packet, fragmentation, windows, etc etc) but virtually you need only to tell to open tcp or udp connection to a given IP and the "hardware" (the MCU for real) will do it, also maintaining the tcp handshaking, and the connection, etc etc. I am not sure about that ESP stuff (which is wifi based if I remember correctly), it's something which can be used through an serial connection or so. There was an article on "hack a day" that you can even reprogram its MCU, but not so much interesting I think.

Yes, the W5x00 does all the stuff including the TCP/UDP layer. Basically you have functions like "open connection", "receive data", "send data", "check status" and "disconnect/close connection" for TCP, UDP, but also for lower layers. So most work is just interfacing with the W5100, but also implementing DNS lookup (and DHCP). The ESP even does DNS by itself.

Regarding VNC, some remote control could probably be implemented, it would be a funny project for sure

Maybe it's even backward compatible with W5100, so no (or minimal) modifications needed only, but of course it would not use the additional power of the 5300 for example 128K of rx/tx buffer space instead of 16 (?). The module I own now is quite nice (I would not solder something like that 5300 or 5100 chip myself ...) it costs about 20EUR at mouser. And the best, that it seems to be Z80 bus friendly (for me, at the first sight) not so much interfacing is needed for the EP too much (but the logic voltage level what I am not sure about).

I had a quick look at the datasheet, and yes, it's very similiar. What I like is the higher number of sockets (8 instead of 4), as 4 could be a little bit limited if you exhaust it to the maximum With the 5100 you have 2KB buffer for incoming (RX) and 2KB for outgoing (TX) data for each socket. This seems to be ok for an 8bit system. The 5300 has 16K RX and 16K TX buffer for each socket, which is probably the maximum what makes sense for the Z80.

Now I am only thinking that SymbOS3 will require more memory even without network support loaded (? or there will be different builds for network support). As we know now, 128K is a bare minimum for just the OS, but SymbOS 3 seems to have many new things and not only the network support, I guess ...

The base version of SymbOS 3.0 will require a little bit more ram again, but it will still run on 128K, and you will still have the possibility to start 1-3 small apps. Most of the new "big" features are now located in additional modules, which can be loaded optional. This is stuff like the network service as well as the enhanced desktop with its more Win98 like behaviour and the extended startmenu.

CU,
Prodatron