What do you think: make a adapterboard which can be used for connect the module to any standard EPROM socket?
lgb hold on to your wiz830mj I have just started working on an Enterprise network interface using one of these. I'm not sure of all the differences between the 5100 and 5300 but I think they are basically the same but with more RAM on the 5300. The 5100 should do the job fine for the Z80 but as they are the same price might as well use the better part which is also more readily available (here in the uk anyway). Don't hold your breath though, it will not be instant and I've only just seriously started looking into it. :)Wow, that sounds very interesting! Bruce, what are your thoughts about the interface? Direct or indirect addressing?
I think the FTP: will more useful as EXOS device :-)
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).
:) 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 :)
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.
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 :P
I think not needed to support all ftp servers in the world. Just enought ftp.enterpriseforever.com or ftp.ep128.hu or something similar where will upload all Enterprise programs. :-) And developers can easy add the new programs.
Further down the line some integration with EXDOS would be nice eg. being able to map a drive letter to a network resource and DIR, COPY etc.
EXDOS doesn't currently have a way of using other file systems - it would probably need a new version of EXDOS with a patch on the function call entry points to see if the drive letter is a network drive etc. But the command line part and IS-DOS don't know anything about FATs etc (mostly, anyway) - they just do EXDOS calls so DIR and COPY etc should just work. SMB was created to basically map MS-DOS calls to the network so there is quite a close correlation between EX-DOS and SMB :)
Wow, you are faster than my thoughts :) I was just about to ask you what MSX uses, direct or indirect with that DenYoNet. I tried to find information about DenYoNet (schematics, detailed description, programming etc) but not so much success yet, can you help in that? I guess it would help a lot to see how MSX guys solved the problems (or even cared at all ...) I talked about like logic level shifting. Anyway, maybe you're right and indirect access is more simple with using some I/O ports only, and nothing more ...The DenYoNet card is using the memory of a full MSX slot/subslot (this is a 4x16K range which can be partially or fully mapped into the visible 64K area). The lower 32K are for the included flash ROM, in the upper 32K you can map the 32K of the W5100. This is separated into 2x16K, the lower are the registers, the higher are the transfer buffers. There are two additonal bits which select if and which part of the 32K is mapped to #8000 and if and which to #C000. Unfortunately I have no idea how this is done internally/wired, but it uses the memory-mapped based slot/subslot technology of the MSX standard.
"AppStore"This is definitely planned!! :P
MAC addressYes, you have to set the MAC address by yourself. On the MSX the producer of the card ("Sunrise") owns 4096 MAC addresses, which is enough :D (not sure about the exact range)
The flash idea is not so bad, and usually it should be set once, so I guess it's not a big deal to re-flash a whole flash page because of that (as far as I know, flashes can be written only per page, not at byte level though).No, only the erase works with pages. Then the erased bytes (FFh) can be written. (At the write you can overwrite 1 to 0, but can't 0 to 1)
No, only the erase works with pages. Then the erased bytes (FFh) can be written. (At the write you can overwrite 1 to 0, but can't 0 to 1)
So most work is just interfacing with the W5100, but also implementing DNS lookup (and DHCP)
My first thought about the RTC was, that you don't need an RTC anymore if you have network,
Didn't know that DHCP requires MacRaw. I thought that even without any network setting you are able to broadcast UDP packets.
I am thinking right now, whether a ENC28J60 would be good for this purpose. This IC can 10mbps, we don't need more. To interface it to EP, I would take a MAX2 CPLD. It cost's not much, and thus the SPI can interface with paraller EP externsion. The only disdvantage is that we have to learn how to control the IC.
In my oppinion a memory-mapped access would be the best solution, because at Z80 it is faster as IO access.
Something like this http://www.tme.eu/en/details/wiz811mj/moduly-wiznet/wiznet/ (http://www.tme.eu/en/details/wiz811mj/moduly-wiznet/wiznet/) ?
As I read in the All-In-One thread there is currently some development going on with the Wiznet W5x00 hardware?
Any news about this or is it currently too far away from publishing details? :)
Glad to hear that it's going on! :) Time to have a closer look at the W5300 programming again...
Which ports are used on MSX for this purpose? I have the faint memory that you told once: on MSX the memory mapped mode is not used only through for I/O ports. If the I/O ports would be the same, it would be even more easy for programming.You probably mixed it with a planned W5100 hardware for the CPC :) About the MSX hardware I wrote the following here:
The DenYoNet card is using the memory of a full MSX slot/subslot (this is a 4x16K range which can be partially or fully mapped into the visible 64K area). The lower 32K are for the included flash ROM, in the upper 32K you can map the 32K of the W5100. This is separated into 2x16K, the lower are the registers, the higher are the transfer buffers. There are two additonal bits which select if and which part of the 32K is mapped to #8000 and if and which to #C000. Unfortunately I have no idea how this is done internally/wired, but it uses the memory-mapped based slot/subslot technology of the MSX standard.
Well, if w5300 is compatible with w5100 with ignoring the new features of w5300 and possible with some extra initialization the same code can be used more or less, I guess. However I am not sure if it worth to use the extra features of w5300 (more buffer ram, more "sockets", probably, as far as I can remember).No, AFAIK the W5300 doesn't provide a "compatibility mode".
You probably mixed it with a planned W5100 hardware for the CPC :) About the MSX hardware I wrote the following here:
Everything else seems to be the same, just with the double amount of sockets, more buffer and maybe some other little improvements. It's not much work to rewrite the W5100 routines for the W5300.
Indeed :) The confusion because "DenYoNet" seems to use a wiznet chip and also we talk about that. However it seems the details are different.Yes, it's using the W5100 :)
Even if it's done not in the memory mapped mode?Yes, that doesn't matter. I developed the Wizenet code in a two-layer way. The lower layer is for writing/reading Wiznet registers and transfering data from/to the buffers. This layer is different for I/O and memory mapped, and has to be rewritten for different computer platforms. These are only a few and simple routines ("write byte to register memory", "write word to register memory", "read byte from register memory", "write data to buffer memory" etc.).
Congratulation Bruce! These are fantastic news!
I want to play battleship on my EP against another Z80, soon :P
(Attachment Link)
I have spoken to the WIZ 5300, and it has replied :) :) :)
My idea would be to do some kind of self modification on start-up for the I/O ports used inside the code (after the detection when you know what they would be modified to ...).This is what I would do in any case. At least my W5100 driver for the Amstrad CPC (which would use indirect I/O as well) only has two routines, which really have to deal with the base I/O port: setup the address and return the data port; one for register memory access, one for RX/TX buffer access. The W5300 shouldn't be much more complex. So such an I/O port "relocator" is not a problem at all.
This is what I would do in any case. At least my W5100 driver for the Amstrad CPC (which would use indirect I/O as well) only has two routines, which really have to deal with the base I/O port: setup the address and return the data port; one for register memory access, one for RX/TX buffer access. The W5300 shouldn't be much more complex. So such an I/O port "relocator" is not a problem at all.
lgb your description of the data transfer, and your code snippets, agrees with my current understanding (perhaps not surprising as we have read the same datasheet!!) but I hope to be able to confirm for real very soon.
It's a bit disappointing: at first glance of the datasheet with its auto-incrementing register I thought we'd be able to use INIR etc but on closer inspection it seems not. :(
All the code examples in the datasheet just have a loop which reads/writes the bytes from/to the data register.
prodatron there is a bit (8) in the Mode Register that byte swaps. So your loops would reduce to INI, INC C, INI, DEC C unless I have misunderstood it :) (very possible :oops: )
Please don't do that. :)
ok, I won't, I hadn't read that example! :oops:
Regarding fast data transfer:
That was my first thought if auto-incrementation would work:
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!
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).
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
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?
DHCP implementation had quite a low priority for me, as it is only a luxury feature for lazy users :D It is not important, as you can use a fixed IP/DNS configuration.
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.
I'm aiming for EPNET to be useful without disks so if the IP address etc has to be set by user commands after each boot that will be a pain! Though that is how I will do "manual configuration".
I'm trying hard to resist "feature creep" so that I stand a chance of getting it finished! My thoughts were that with a network connection a RTC is less important because you can at least use NTP or something to get the date/time from somewhere else.
I assume you do not have to read the whole buffer immediately if you don't want to, but you'll probably have to read it a word at a time, so hold a byte "in hand" for the EXOS device - not too hard. But there should be enough RAM there to buffer it if that turns out to be necessary.
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.
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.
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.
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.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?
"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?
To the user at least it is not a circular buffer - incoming data just goes further and further up the buffer until it runs out. Maybe RECV resets the pointers back to the beginning. Or maybe I am being symplistic - if I was doing it I'd make the buffers circular so the pointers wrapped round the start and maybe that is what happens internally.
I wonder what happens if a new packet comes in between you reading the last byte and issuing the RECV?
Yes and a bit of a pain if you are using all 8 sockets: I do not have the RAM to have 8x1500 byte buffers. I was planning on using just socket 0 for the EXOS device so that would be ok, but later with EXDOS integration I was thinking one socket per mapped network resource. I will do some experiments as soon as I can to see if this really is the case!
But things goes quite complicated then, at least at the first glance for me ...Yes, I did not go beyond a brief glance at that point! :???:
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... :ds_icon_frown:
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?
My initial goal with EXOS integration is for network LOAD/SAVE in BASIC to work (and other applications of course) and I was thinking first of LOAD "ftp:blahblah" etc. (or LOAD "http:blahblah" as we have discussed before). Here the protocol on top of TCP/IP is FTP and the EXOS FTP: device will handle that.
What you are talking about is the EXOS app implementing a different protocol itself on top of TCP/IP, eg POP3 in your example, and I have not given much thought to that, but it needs to be possible. eg open a channel to "NET:192.168.0.20:1001" (can you have two : s and a filename that long?). But at least in this case the application is network-specific so it can work
whatever EXOS's blocking-or-not behaviour is. EXOS has a read status call which says whether a character is ready or not (shame it doesn't say how many are ready! :oops: ) and I would say block read should return whatever is available, possibly less than the user asked for. Surely protocols are designed so the "reader" knows how many bytes he is supposed to read? In the case of POP3 the responses from the server are single text lines which you could read character-by-character, or as a block returning however many are available, and then when a mail message itself is downloaded you already know how many to expect, so you loop doing block reads until you have the message, presumably with a timeout. Avoiding a waiting-for-network loop within EXOS seems like a good idea if at all possible!
EXOS has a read status call which says whether a character is ready or not (shame it doesn't say how many are ready! :oops: )What do you think about EXOS 10? It is can be used for network files?
What do you think about EXOS 10? It is can be used for network files?
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... :ds_icon_frown:
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?
Hmm, do you mean EXOS 9, or really 10? But the problem - I think - is not exactly this, but the fact that - as far as I can see - with disk files EXOS will return less bytes than asked on reading only in case of EOF (so no more bytes). Thus, maybe many EXOS apps can think that less bytes read than requested is the sign of end-of-file, so game over. With network channels the situation is not that (so not compatible) as EXOS call for a network channel can return less bytes than requested because of no data is sent by the network peer. But in this case this does not mean end-of-file, but the app should re-try later if more data is received meanwhile.
So basically me problem: EXOS apps maybe used to deal with "real files" behind the notion of "channels", but in our case network channel is a bit different as it's not an "already ready" stream of data on the disk, but received on reading, etc, in "real time". The problem that we can ask (maybe with EXOS 9) if there is any byte to read or not, but we don't know how much is that "any". Also, if EXOS 9 returned with "no characters" then what an app can think: "end of file" (closed connection like stuff) or just try to re-ask later. Maybe network channels are more like KEYBOARD: EXOS device than "real" files! And that is what EXOS apps are maybe not ready. For newly written apps it may be not a problem.
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?
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:
/* 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 */
}
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?
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.