Jump to content
IGNORED

TCP/IP Offloading With The WIZnet W5100


ol.sc

Recommended Posts

Hi,

 

In http://atariage.com/forums/topic/241436-contiki-august-2015/I mentioned the WIZnet W5100 Ethernet controller because Contiki (and IP65) have a driver for it.

 

However the W5100 might be of some interest unrelated to Contiki so I opted for a new topic...

 

- The current W5100 datasheet can be found at http://www.wiznet.co.kr/product-item/w5100/

 

- WIZnet also provides a module containing the W5100, see http://www.wiznet.co.kr/product-item/wiz811mj/

 

- I implemented several W5100 drivers (see links below) and recently wrote some notes on the W5100 I'm presenting here:

 

1. Operation Modes
1.1 MAC-Raw
In MAC-Raw mode the W5100 behaves pretty much like a CS8900A or a LAN91C96. The W5100 is usually only configured with a MAC address which is used by the W5100 to limit incoming frames to those sent to its MAC address (or broadcasts).
1.2 IP-Raw
IP-Raw mode is usable to implement non-UDP/non-TCP IP protocols like ICMP. The W5100 is usually configured with a full IP profile (IP addr, netmask, gateway). It transparently takes care of incoming/outgoing ARP and optionally of incoming ICMP Echo (aka Ping).
1.3 UDP
UDP mode is pretty simlar to IP-Raw mode but additionally takes care of header checksum calculation.
1.4 TCP
TCP mode is rather different from the other modes. Incoming/outgoing data isn't delimited by headers like in all other modes. Rather the W5100 behaves like a BSD socket delivering/taking a data stream - in chunks not necessarily related to data packets received/sent. The W5100 transparently takes care of TCP flow control by sending ACK packets. It advertises a receive window identical to the free space in the its receive memory buffer.
The W5100 offers up to 4 'sockets' allowing to specify the operation mode for each socket individually. However MAC-Raw mode is only available for the first socket. It is possible to combine MAC-Raw mode with other modes for the other sockets - which is called 'hybrid TCP/IP stack'. I have no personal experience with this hybrid TCP/IP stack and see open questions:
- Are packets delivered to other sockets filtered from the first socket?
- Who takes care of incoming ARP and incoming ICMP Echo?
The W5100 divides its 16kB memory buffer statically into 8kB for receive and 8kB for send (in contrast to the CS8900A and the LAN91C96 which both do dynamic receive/send buffer division). When using several sockets it is additionally necessary to statically assign the two 8kB memory buffers to the sockets.
2. Memory Buffer Access
In 6502 machines the W5100 is accessed using its indirect bus interface. This interface optionally allows for pointer auto-increment (like the CS8900A and the LAN91C96). However in contrast to those two Ethernet controllers the W5100 does NOT virtualize access to its memory buffer! So when reading/writing data from/to the W5100 and reaching the end of the memory buffer assigned to the socket it's the responsibility of the 6502 program to continue reading/writing at the begin of the memory buffer. Please note that the pointer auto-increment does NOT take care of that wraparound operation! I have implemented several ways to handle this difficulty.
2.1 Copy Split
If it is necessary or desired to have the interface to the upper layers being based on a receive/send buffer and one can afford the memory for a little more code than it is appropriate to check in advance if receive/send will require a wraparound and in that case split the copy from/to the buffer into two copy operations. That approach is used in all WIZnet code and I implemented it in pretty optimized 6502 code for the Contiki/IP65 MAC-Raw mode driver located in drivers/w5100.s - however the copy split technique is in general applicable to all W5100 operation modes.
2.2 Shadow Register
When it comes to using as little memory as possible I consider it in general questionable if a buffer is the right interface paradigm. In many scenarios it makes more sense to read/write bytes individually. This allows i.e. to directly write bytes from individual already existing data structures to the W5100 or analyze bytes directly on reading from the W5100 to decide on processing of subsequent bytes - and maybe ignore them altogether. This approach splits a receive/send operation into three phases: The initialization, the individual byte read/write and the finalization. The initialization sets up a 16-bit shadow register to be as far away from overflow as the auto-increment pointer is away from the necessary wraparound. The individual byte read/write then increments the shadow register and on its overflow resets the auto-increment pointer to the begin of the memory buffer. I implemented this approach in two drivers using heavily size-optimized 6502 code for the W5100 UDP mode and TCP mode showing that the shadow register technique yields the smallest code. They are located in supplement/w5100_udp.s and supplement/w5100_tcp.s with C test programs located in test/w5100_udp_main.c and test/w5100_tcp_main.c. There's a Win32 communication peer for the test programs located in test/w5100_peer.c.
2.3 TCP Stream Split
A correct BSD TCP socket program never presumes to be able to read/write any amount of data. Rather it is always prepared to call recv()/send() as often as necessary receive/send the expected amount data in whatever chunks - and the very same holds true for any program using the W5100 TCP mode! But this already necessary complexity in the upper layers allows to handle W5100 memory buffer wraparounds transparently by artificially limiting the size of a read/write operation to the end of the memory buffer if necessary. The next read/write operation then works with the begin of the memory buffer. This approach shares the benefits of the shadow register technique while avoiding its performance penalties coming from maintaining the shadow register. Additionally it allows the upper layers to directly access the auto-increment W5100 data register for individual byte read/write because it is known to stay within the memory buffer limits. Therefore the TCP stream split technique avoids both the overhead of a buffer as well as the overhead of function calls for individual bytes. It sort of combines the best of both sides but it means larger code than the shadow register technique and is only applicable to the W5100 TCP mode. I implemented the TCP stream split technique in a C-only driver located in supplement/w5100.c with a test program representing the upper layers located in test/w5100_main.c being compatible with test/w5100_peer.c.
Regards,
Oliver

 

  • Like 2
Link to comment
Share on other sites

Hi Oliver,

this is very interesting.

I learned a lot just by reading your descriptions and looking at the CONTIKI source code.

Programming for CONTIKI requires solid low level C and networking knowledge.

You can be proud of what you achieved in this area :) Great work :thumbsup:

I'm not sure if you are aware of my activities related to the SIO2BT project: http://atariage.com/forums/topic/228860-sio2bt/

Recently I started the second part - adding a SIO networking device to the SIO2BT Android App.

Imagine a socket-like interface mapped to the SIO commands.

The ATARI acts as a TCP/IP client connecting to a TCP/IP server listening on some port.

Of course all the TCP/IP stuff will be managed in the Android Phone.

The ATARI SIO commands will be as simple as: GETSTATUS, OPEN, READ, WRITE, CLOSE.

Having a CIO handler in the system, it should be even possible to use networking from a BASIC language.

I wondered how difficult would it be to adapt the CONTIKI code (TELNET, IRC, BROWSER, etc.) to use socket interface?

Regards

Marcin

Link to comment
Share on other sites

Hi,

 

You can be proud of what you achieved in this area :) Great work :thumbsup:

Thanks for the nice feedback :-)

 

Recently I started the second part - adding a SIO networking device to the SIO2BT Android App.

Imagine a socket-like interface mapped to the SIO commands.

The ATARI acts as a TCP/IP client connecting to a TCP/IP server listening on some port.

Of course all the TCP/IP stuff will be managed in the Android Phone.

The ATARI SIO commands will be as simple as: GETSTATUS, OPEN, READ, WRITE, CLOSE.

Having a CIO handler in the system, it should be even possible to use networking from a BASIC language.

I (sort of) see...

 

I wondered how difficult would it be to adapt the CONTIKI code (TELNET, IRC, BROWSER, etc.) to use socket interface?

 

Usually I'm asked to have Contiki use some "external" TCP/IP stack. That's from my perspective more or less impossible as Contiki primarily consists of the TCP/IP stack.

 

However it might be possible with some major effort separate a certain Contiki program (like the web browser) enough from Contiki to retrofit it to another TCP/IP stack. However I've never really thought about the details - and I'm not interested in doing so.

 

Regards,

Oliver

Link to comment
Share on other sites

I had tried pretty extensively in the past to get a SIO-to-ethernet connection going, using an sio2pc connection to a small SBC that had its own OS and TCP stack on it. It worked, up to a point. I found that the polling overhead was just not going to allow me to be able to support my target, which was a fast UDP layer for gaming. It would probably work for telnet and 'web browsing' and so forth, but at that point you might as well just connect to APE or something on a regular PC.

 

Now, a W5100 in a direct access cart, such as the Dragoncart, is a completely different matter, and would be a great target for development. I am finishing out the driver for the current Dragoncart, which will support access from regular atari dos and from languages like Basic and Action, and seems to be able to support the speed necessary for gaming. If someone were to develop hardware like the dragoncart using a W5100, I would be very interested in supporting that as well.

  • Like 3
Link to comment
Share on other sites

Hi,

 

I had tried pretty extensively in the past to get a SIO-to-ethernet connection going, using an sio2pc connection to a small SBC that had its own OS and TCP stack on it. It worked, up to a point. I found that the polling overhead was just not going to allow me to be able to support my target, which was a fast UDP layer for gaming. It would probably work for telnet and 'web browsing' and so forth, but at that point you might as well just connect to APE or something on a regular PC.

Thanks for sharing that from my perspective pretty interesting experience. I see that nowadays "everybody" seems to think in the direction of hiding networking capabilities behind existing interfaces - be it Atari SIO, CBM IEC or Apple SmartPort. This allows for easy access to networking from BASIC etc. However performance seems to be a reason to allow for direct access from the 6502 to the Ethernet controller.
I really know that I know WAY to little about the Atari to start a discussion like this but nevertheless...
Given that I seem to have understood that "Fast SIO" requires significant OS ROM patches: Wouldn't it be an interesting option to use Ethernet/TCP/IP as transport media and have an OS ROM that directly uses a W5100 to exchange the data usually exchanged over SIO - at least as switchable ROM? I see that many Atari users don't run any real SIO hardware anymore anyway - at least in day-to-day operation. Maybe it's time to move away from having all those "soft" devices emulate SIO but rather have the Atari talk the lingua franca? I see SIO2BT as a step towards that direction - and as far as I understand it already loses the full SIO compatibility. So maybe go all the way: Drop compatibility with games using own SIO routines, have OS ROM (and SpartaDOS X) with W5100 routines and gain native direct TCP/IP access.
Maybe that's too far-fetched for one or the other but on the Apple II I'm moving optionally(!) even from the LAN to the WAN (aka Internet). This is NOT about trying to be compatible with existing protocols like HTTP. This is about running a drive emulator not on a PC or a Smartphone but on an Internet server. There might be public servers with R/O disks. However I primarily see the user having an account on the server. He logs into his account right from his 6502 machine. That creates a simple TCP connection used by the server to identify further traffic instead of tokens or alike. That connection lives as long as the user session (like i.e. Telnet does). Using TCP additionally allows for much more robust NAT operation than UDP. And using the W5100 TCP is even simpler than UDP from the 6502 perspective. As soon as the login program has established the TCP connection (and the user has selected the disk(s) to be mounted) the W5100 can transparently handle the session with the server without any help from the 6502. The 6502 then can just push/pull bytes with pretty small routines - as I have proved.
If you are there then you can of course think of a web front end to the server allowing i.e. to enter URL of disks on the Internet and have them copied and decompressed on the server side. Or have other disk(s) mounted in the emulated drive(s) when it's not opportune to use the program on the 6502 machine to do so.
You see: Native TCP/IP allows to talk to every device in the LAN without issues like missing serial ports, missing USB ports, missing BT protocols. TCP/IP allows to talk to servers on the Internet. But the "trick" is to not try to be compatible with something out there (like the Contiki webbrowser or Dan's Telnet client). Rather create a custom communication peer tailored to the needs of the 6502 machine. Now there's a common communication ground easy to access for both the 6502 (with the transparent TCP handling of the W5100) and its peer (with the BSD TCP socket interface available in about every environment / language).
As mentioned all this may just not be applicable to the Atari for reasons well beyond my scope. However it might nevertheless be interesting where I'm heading to on the Apple II.

 

Now, a W5100 in a direct access cart, such as the Dragoncart, is a completely different matter, and would be a great target for development. I am finishing out the driver for the current Dragoncart, which will support access from regular atari dos and from languages like Basic and Action, and seems to be able to support the speed necessary for gaming. If someone were to develop hardware like the dragoncart using a W5100, I would be very interested in supporting that as well.

 

Contiki already coming with W5100 support, Dan committing to add W5100 support plus new opportunities due to TCP/IP offloading. Can it get anymore tempting, hardware guys? ;-)

 

Maybe: Think about this... As pointed out above I see the 6502 program reading directly from the W5100 data register and process it - no buffers in 6502 RAM. What about an (unrolled) loop that simply stores the values read right into mode 8 video RAM? Calculate what bandwidth such a loop may produce given that it can just keep reading from the same absolute address because of the auto-increment. It's save to presume that the 6502 is the bandwidth bottleneck ;-) Given the tiny 2kB frame size you get interesting frame rates. You "just" need a communication peer that (like above with the drive emulation) exactly knows the needs of the Atari and delivers the data as pure TCP stream. I don't see an issue with creating mode 8 frames from a video source in real time allowing for (Internet) live video streaming (although - at this point - without sound).

 

Regards,

Oliver

Edited by ol.sc
Link to comment
Share on other sites

Hi Oliver!

 

Big thumbs up for your work, that's really awesome!

 

I ran accross the W5100 several years ago but never found the time to actually do anything with it (didn' even buy the Wiznet module...).

 

As for "intelligent" interfacing on the Atari, there are several options:

 

You can do that via SIO, it even has 2 interrupt inputs ("Interrupt" and "Proceed"), so you don't have to use polling. AFAIK no other SIO devices are using these pins so there shouldn't be any conflicts. Using something like an Arduino plus ethernet shield (or some other micro with eth connectivity) would be a way to go. IIRC Sven on the ABBUC forum is experimenting with this.

 

If you go this way the external SIO eth adapter can happily coexist with other SIO devices like (emulated) floppies which will be quite important to load the software and actually do anything with the Atari. HDD interfaces do exist for the Atari, but they are not too widespread - I'd guess the majority of people is still using SIO floppies.

 

Bumping the serial speed from ~19.2kbit/sec up to 50-125kbit/sec can also be done purely in software and could be used for a SIO eth device as well.

 

Another option is to create a PBI device. This hooks up to the 6502 address/data bus ("PBI" or "ECI+cart" connectors at the back of the Atari), supports IRQs as well and - if done correctly - can coexist both with other PBI devices and SIO devices.

 

The big plus of PBI devices is that they include the necessary device driver code in their own ROM and they are accessible via the standard Atari OS functions right after power up - quite similar to PCI cards with ROM on a PC. So you could put all the socket interface layer code into the ROM, people wouldn't have to load drivers and no precious RAM would be lost.

 

Hardware wise PBI devices can bank in their own memory in the $D800-$DFFF area, the Atari OS controls the high level stuff of that (which of the up to 8 PBI device ROMs will be active). 2k isn't really a huge amount of memory, but with some clever bankswitching one can squeeze in quite a lot of code. If you need some scratch RAM for internal state/buffers/... you'll either have to bank it into the 2k area as well, eg by a 1k/1k or 0.5k/1.5k RAM/ROM memory split or use some of $D1xx for that (which you most likely will also use for the hardware and banking registers).

 

so long,

 

Hias

  • Like 1
Link to comment
Share on other sites

I had tried pretty extensively in the past to get a SIO-to-ethernet connection going, using an sio2pc connection to a small SBC that had its own OS and TCP stack on it. It worked, up to a point. I found that the polling overhead was just not going to allow me to be able to support my target, which was a fast UDP layer for gaming. It would probably work for telnet and 'web browsing' and so forth, but at that point you might as well just connect to APE or something on a regular PC.

 

I'm not planning (for SIO2BT) any support for real-time gaming. However turn-based games, telnet, irc, etc. should work well over SIO using polling.

 

Given that I seem to have understood that "Fast SIO" requires significant OS ROM patches: Wouldn't it be an interesting option to use Ethernet/TCP/IP as transport media and have an OS ROM that directly uses a W5100 to exchange the data usually exchanged over SIO - at least as switchable ROM? I see that many Atari users don't run any real SIO hardware anymore anyway - at least in day-to-day operation. Maybe it's time to move away from having all those "soft" devices emulate SIO but rather have the Atari talk the lingua franca? I see SIO2BT as a step towards that direction - and as far as I understand it already loses the full SIO compatibility. So maybe go all the way: Drop compatibility with games using own SIO routines, have OS ROM (and SpartaDOS X) with W5100 routines and gain native direct TCP/IP access.

 

Contiki already coming with W5100 support, Dan committing to add W5100 support plus new opportunities due to TCP/IP offloading. Can it get anymore tempting, hardware guys? ;-)

 

Regards,

Oliver

 

SIO is a well established standard - I believe no one would like to give it up and it was not my intension to loose any compatibility with SIO.

The OS modification for SIO2BT was a "trade of" and the OS with changes for SIO2BT remains compatible with the original one (only timeouts were changed).

Atari programmers understand CIO and SIO and only very few people have so deep knowledge about TCP/IP stack as you do :)

 

Bumping the serial speed from ~19.2kbit/sec up to 50-125kbit/sec can also be done purely in software and could be used for a SIO eth device as well.

 

 

 

I guess 125kbit/sec over SIO for TCP/IP would not be a very good idea, because the ATARI would be completely busy at that time.

Rather 19.2kbit/sec and the user would not even notice the background communication (see XBIOS features).

Link to comment
Share on other sites

Hi Hias,

 

First of all thanks for joining in here and your detailed post !

 

Big thumbs up for your work, that's really awesome!

I appreciate your feedback :-)

 

You can do that via SIO, it even has 2 interrupt inputs ("Interrupt" and "Proceed"), so you don't have to use polling. AFAIK no other SIO devices are using these pins so there shouldn't be any conflicts. Using something like an Arduino plus ethernet shield (or some other micro with eth connectivity) would be a way to go. IIRC Sven on the ABBUC forum is experimenting with this.

 

As I already mentioned this seems to be the most popular approach nowadays: Use the given interface (Atari -> SIO, CBM -> IEC, Apple II -> SmartPort), implement it on an MCU and access an SD Card from the MCU.

 

Then one starts thinking about alternatives to exchanging the SD Card between a PC and "the device". So one adds WiFi. Finally one wants thinks about using WiFi not only for SD Card access but also for networking on the 6502 host. So one comes up with a clever pseudo-drive / virtual-channel / <you name it> allowing to open a (usually single) TCP (usually only client-) connection.

 

There might be a good reason why this is popular. It might just be the most useful solution for most users. Nevertheless it's not my solution. It's after all just a question of taste...

 

- Such approaches treats the 6502 host (more or less) as a black box as they aim for maximum compatibility with existing 6502 software. Almost all development is done on the MCU. But I want to make use of my experience in programming the 6502 host and create new 6502 software. I'm not really into MCU coding.

 

- Such approaches look to much like wag-the-dog to me. About every MCU offers a multitude of resources of the 6502 host. About every task coming up in the future would be solved quicker and better by offloading it to the MCU. Why go through the hassle of 6502 coding / optimizing at all?

 

One can of course use the W5100 in such a device (see http://www.retroswitch.com/products/flyer/ or http://www.cometplus.net/ ) and drive it from the MCU. However that's not what I'm personally after...

 

Some thoughts on interrupts: Maybe they are important in the Atari for reasons beyond my knowledge but in general I see them as not necessary or even benficial. I think there are in general two reasons for having a communication device interrupt the 6502:

 

- The device has a small input buffer and one wants to grab the data before it's lost (think usual UART). The W5100 has input buffers larger than what one would usually want to spend in 6502 RAM. So the data is just fine in the W5100.

 

- The communication protocol requires to react in some way based on the data received. And may it be only to tell the communication peer to stop sending further data (think 6502 TCP/IP stack). The W5100 handles TCP flow control transparently. If the 6502 stops receiving, the W5100 input buffers fill upand if they are full the zero-sized receive window blocks the sending peer.

 

So conceptually I don't see why a 6502 program would want to read data from the W5100 (via interrupt) before it is actually at the point of processing it (in it's foreground code).

 

I presume that interrupts are interesting here to avoid the SIO overhead just for polling the W5100. However if the W5100 is directly accessible from the 6502 then polling is in the range of 20 instructions - very little in my opinion when taking into account that interrupt handling doesn't come for free either.

 

Another option is to create a PBI device. This hooks up to the 6502 address/data bus ("PBI" or "ECI+cart" connectors at the back of the Atari), supports IRQs as well and - if done correctly - can coexist both with other PBI devices and SIO devices.

 

Unfortunately I cannot really follow you. However maybe this isn't actually directed to me but rather towards somebody thinking about an Atari W5100 device...

 

The only thing I can/want add here is that it is from my personal perspective obligatory to allow the 6502 to directly access the W5100 (using its indirect bus interface). This allows to i.e. read data from the W5100 with a loop like

 

ldx #$00

: lda w5100_data_reg

sta target,x

inx

bne :-

 

So there's no checking of some line to become high/low or alike. It's just reading (with auto-increment) as fast as possible - afaik only DMA could beat that.

 

The big plus of PBI devices is that they include the necessary device driver code in their own ROM and they are accessible via the standard Atari OS functions right after power up - quite similar to PCI cards with ROM on a PC. So you could put all the socket interface layer code into the ROM, people wouldn't have to load drivers and no precious RAM would be lost.

 

That sounds of course great !

Hardware wise PBI devices can bank in their own memory in the $D800-$DFFF area, the Atari OS controls the high level stuff of that (which of the up to 8 PBI device ROMs will be active). 2k isn't really a huge amount of memory, but with some clever bankswitching one can squeeze in quite a lot of code. If you need some scratch RAM for internal state/buffers/... you'll either have to bank it into the 2k area as well, eg by a 1k/1k or 0.5k/1.5k RAM/ROM memory split or use some of $D1xx for that (which you most likely will also use for the hardware and banking registers).

 

I must admit that I'm still almost totally lost when it comes to all the RAM/ROM config options on the Atari. What probably makes sense to add from my side:

 

As already mentioned the code to actually receive/send data from/to the W5100 can become pretty small - a few hundred bytes. I'd hope that this helps to makes it compatible with a wide range of software making its own use of specific RAM/ROM locations.

 

There's however the initialization / setup / login phase. There one would like want to have DHCP and DNS (which are not implemented in the W5100). Additionally there would be some interactive program (?). My gut feeling is that one 2kB bank would be sufficient.

The interactive part can be fully driven by the communication peer. Think of the 6502 machine just sending keystrokes and the peer sending full text screens (in the right format) the 6502 machine just copies as-is to its text video RAM. Very little code on the 6502 side and full flexibility regarding the UI. A simple LAN peer just presents a list of disks to mount. An Internet server with accounts (as described before) presents a login first.
Regards,
Oliver
Edited by ol.sc
Link to comment
Share on other sites

Hi,

 

SIO is a well established standard - I believe no one would like to give it up and it was not my intension to loose any compatibility with SIO.

The OS modification for SIO2BT was a "trade of" and the OS with changes for SIO2BT remains compatible with the original one (only timeouts were changed).

I'm sorry for my misconception :-( Likely it wasn't a good idea to refer to SIO2BT in the first place - given how little I understand it.
What I originally wanted to express is that my idea/proposal/<you name it> isn't about "TCP/IP over SIO" but rather "SIO (content) over TCP/IP".
I somehow felt that SIO2BT would be "SIO (content) over BT" and therefore thought that the relation might help to make my point...

 

Atari programmers understand CIO and SIO and only very few people have so deep knowledge about TCP/IP stack as you do :)

 

On the C64 I saw people offering easy networking opportunities being pretty sobered by the lack of adoption. I put quite some effort into tools for broader adoption in the past. By now I'm more focused on "end user" benefit. However I may not be able to estimate the Atari user benefit of "really fast natively TCP/IP based LAN/WAN drive emulation" as I'd describe it.

 

I'll move forward into that direction on the Apple II. I thought I'd share my ideas and experience so far with the Atari community. There would be obvious synergy effects if there would be a momentum for a "W5100 directly accessible from the 6502" type device for the Atari. But I'm - as mentioned - way to far away from the Atari world to say: That's THE thing to do.

 

What I didn't mention so far is that there were plans for such a device for the C64 from the manufacturer of "THE" C64 CS8900A. However he moved back to the CS8900A in the last minute because he realized that there was too much C64 CS8900A software out there without a perspective to be adjusted for the W5100. And that's the difference to the Apple II: There's less CS8900A software available for the Apple II and it could be made sure that all will be adjusted. So given that there's even less CS8990A software for the Atari I felt I should point out what seems like an opportunity to me...

 

Regards,

Oliver

Link to comment
Share on other sites

Hi Oliver!

 

Big thumbs up for your work, that's really awesome!

 

I ran accross the W5100 several years ago but never found the time to actually do anything with it (didn' even buy the Wiznet module...).

 

...

 

so long,

 

Hias

 

@Hias,

Perhaps you could design a new network PBI device based on W5100 ?

If you combine your ATARI expertise together with Oliver's networking experrience, it would be a really great project :)

A new PBI device supporting the ETHERNET mode and the TCP/IP socket mode :-o

  • Like 1
Link to comment
Share on other sites

Hi,

 

 

@Hias,

Perhaps you could design a new network PBI device based on W5100 ?

If you combine your ATARI expertise together with Oliver's networking experrience, it would be a really great project :)

A new PBI device supporting the ETHERNET mode and the TCP/IP socket mode :-o

 

I'm not sure if Hias actually needs me to help him along with regard to networking ;-)

 

However I'd be very interested to collaborate with Hias on such a project. Beside contributing my W5100 experience and the already implemented drivers I'd commit to implement simple/small DHCP and DNS clients based on my W5100 UDP driver.

 

Regards,

Oliver

Link to comment
Share on other sites

Hi,

 

 

I'm not sure if Hias actually needs me to help him along with regard to networking ;-)

 

However I'd be very interested to collaborate with Hias on such a project. Beside contributing my W5100 experience and the already implemented drivers I'd commit to implement simple/small DHCP and DNS clients based on my W5100 UDP driver.

 

Regards,

Oliver

I was looking into the WS5100 a while back, I planned on making a PBI device. I think I'll still do it, once I'm at school, I'll have more time than when I was working I hope, so I'll order some dev stuff and see what I can do. Also, I was looking at the W5300, basically the same as the 5100, except more RAM and more sockets, and only $1 more. The more sockets thing probably won't be a big help, but the extra RAM for buffers might be good to have.

Link to comment
Share on other sites

Hi,

 

Also, I was looking at the W5300, basically the same as the 5100, except more RAM and more sockets, and only $1 more. The more sockets thing probably won't be a big help, but the extra RAM for buffers might be good to have.

 

I looked at the W5300 too. From my perspective its primary benefit isn't the additional RAM but the virtualized memory buffer access - making all the funny things I described in my original post simply unnecessary.

 

However looking at the WIZnet errata docs it seemed to me that there are new issues not present in the W5100 - and they seemed to me to be hard(er) to workaround so after quite some consideration I decided to stay with the W5100. Unfortunately I don't remember the details anymore - and I didn't take notes...

 

Another aspect is that the W5300 is primarily targeted towards 16-bit access. It supports 8-bit access but is optimized for 16-bit access. Especially reading/writing the actually data is always done in 2 bytes. But what if the number of bytes to read/write happens to be odd? You read/write a 2-byte-header specifying the number of bytes following. If it is odd you read/write a dummy byte. But that means that the TCP mode isn't a "transparent" byte stream mode anymore.

 

I certainly don't say that this is worse than the missing buffer memory buffer virtualization of the W5100. But in the end programming the W5300 is much more different from programming the W5100 than most people assume. If I had to implement a W5300 driver in 6502 code I'd probably even rather start from scratch than trying to adapt my W5100 code. Anyway I personally am not interested to go through the same knowledge building process again in went through for the W5100 ;-)

 

Regards,

Oliver

Link to comment
Share on other sites

Hi,

 

16-bit access should present no problem if divided into two 8-bit registers, one or the other triggering transfer (this is how several IDE host adapters on the A8 work, removing the need to run the media in 8-bit PIO mode).

 

I must have been way too unclear :-(

 

There's no problem at all with 16-bit access. The W5300 even has explicit 8-bit access support. The "problem" is that the 16-bit oriented architecture complicates the interface on a higher level as it needs in TCP mode a "workaround" for receiving/sending odd sized data. This workaround is totally independent from 8-bit / 16-bit access!

 

Regards,

Oliver

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...