If you set things up so the callback is executed inside the IRQ handler, then in the cases where polling is more appropriate, it's not hard for someone to have a stub callback handler that just sets a flag and returns.

BTW it occurs to me that extending ip65 might be easier than starting from scratch - apart from an overall architecture it also provides some foundational services like DHCP & DNS. Although sometime reinventing the wheel is more fun

When I get some heavy duty coding time (maybe over Xmas) I will probably do that. Looks like it could be done in bite-size chunks, namely:

1) use the "MAC RAW" mode to provide a ethernet driver (i.e. eth_init,eth_rx,eth_tx - as implemented in cs8900a.s : http://ip65.sourceforge.net/ip65_cs8900a_s.html : with this stage, any ip65 app (e.g. BASIC on Bails) should work once linked to the WI5100 new driver, but be no more efficient in memory or CPU than the RR-NET driver

2) create new versions of udp.s (http://ip65.sourceforge.net/ip65_udp_s.html ) & tcp.s ( http://ip65.sourceforge.net/ip65_tcp_s.html ) which use WI5100 sockets - this should mean any ip65 app would also still work if recompiled with the new version, and be faster & use less RAM.

3) create new versions of udp_add_listener and tcp_add_listener (e.g. udp_add_listener_asynch) that uses interrupts rather than polling. Existing ip65 apps (e.g. BASIC on Bails) would need to be modified to take advantage of interrupts. You couldn't just start calling into the callback routines outside of an explicit poll (ip65_process) because there is often tight coupling between the application "main" loop and the callback code.

I appear to have MAC RAW mode working as an ip65 driver. more debugging to do, but I was able to use the ip65 DHCP and ICMP functions i.e. I have a test client that:
- probes for a w5100 at each of $DE00, $DF00, $DF20 (my board is at $DF20)
- if one is found, it then does a DHCP request
- if DHCP succeeds, it then attempts to ping both the DHCP server, and the default gateway

Unfortunately I had lots of problems using the 'auto increment' addressing mode. I have done the /rd and /wr decoding via a 74LS138 using Jim's suggested connections (although I am using outputs Y2 & Y3 not Y0 & Y1 - I put an LED on Y0 will doing early testing of the circuit, hence my board is on $DF20 - that shouldn't matter though)
What I found though was during reads, it was occasionally skipping over addresses, i.e. if I did say 100 successive reads, at the end, when I looked at the address pointer (i.e. reading the values of IDM_AR0/IDM_AR1) it would be maybe 3 to 5 values higher than it should be. I don't know whether there is something else on the bus generating spurious reads, or could be an intermittent signal quality issue. I guess a short noise burst in say /IO2 would result in what should be a single /RD pulse be split into 2 pulses. Unfortunately I don't have any tools to debug this with.

Anyway I have turned off autoincrement, i.e. the address pointer is set before reading or writing each byte. Which will slow things down I know, but at least lets me progress for now. If (down the track) I get a better quality board it shouldn't be much of a code change to go back to auto increment mode.

My current plan is to get an ip65 build that uses MAC RAW mode for UDP (including DHCP & DNS) and ICMP, but uses the w5100 on-chip TCP stack. At this stage I am only planning to allow a single TCP socket (since the ip65 tcp functions all work on just one socket), so I will have the w5100 socket 0 be a IP RAW socket (4KB each for tx & rx buffer) and socket 1 be the TCP socket (4KB tx & rx).

I'd be interested in what Six does. If his works, then I would chalk it up to your board. If not, then I can look at my schematic and consider changes. I admit is was quick and dirty, limited to ICs we had on hand.

Jim

my ip65 port seems to be functionally complete. This is hybrid mode outlined above, i.e
- socket 0 is MAC RAW (using 4KB buffers)
- socket 1 is for a TCP client or server (also with 4KB buffers)
- ICMP & UDP / DHCP / DNS / etc using the standard ip65 implementation (on top of the MAC RAW socket)
- TCP calls are passed through to the wiznet tcp stack on socket 1

I have compiled and tested a couple of my ip65 client apps, and they all seem to work.

The attached disk contains
- kt2wiz.prg : KipperTerm 2 for W5100 - my telnet and gopher client, which uses an 'on disk' address book. There is also the address book editor (ABE - in BASIC and very slow)
- kkwiz.prg : a KipperKart build using the w5100 driver. this is actually a cartridge image (intended to be loaded at $8000) with a short stub that shifts it into place. I will eventually burn this into an EPROM.
- WebNoter.prg - this is the first (and so far, only) 'real' app for the Kipper API - to run you first boot the kkwiz.prg image, and then from there do a 'disk boot' and load webnoter.prg. This binary does NOT have any w5100 code in it, it calls via the Kipper API, and the same binary would also work with the cs8900a version of KipperKart

The kt2wiz.prg and kkwiz.prg are both looking for a w5100 at $DF20 - if anyone wants me to provide a copy of these apps with a different address, let me know.

I am pretty confident that my other ip65 apps would port straight over now as well (e.g. BASIC on Bails). But the benefits turn out to be a lot less than I was expecting - once I decided I wanted to retain the ability to do outbound pings, plus DHCP and DNS, I've ended up having to keep most of the ip65 stack (including ICMP and ARP). For example the csd900a build of KipperTerm (using 'software' TCP implementation) is only 500 bytes larger than the W5100 version (using the hardware TCP stack).

So now I wonder whether it's really worth putting out a NIC that isn't a RR-NET clone? I'd probably be more enthusiastic if it was a WIFI board, or if there was a more complete stack onboard (i.e. if it did DHCP and DNS on-chip).

Hmm, can you breakdown the code size? I am greatly surprised that having an actual TCP/IP stack on IC doesn't bring the code size down more than a token amount.

Jim

The only part I have removed from the ip65 stack, and are using the w5100 on-chip stack for instead, is TCP.
The TCP implementation in ip65 is 1636 bytes
However the cs8900a driver is 337 bytes, while my w5100 driver (including wrappers for the TCP function) is 1459 bytes. So net saving is:
1636+337 - 1459 = 514 bytes.

I'm sure I could optimise the w5100 driver and take a few more hundred bytes out. I could also remove other parts from the ip65 stack, at the expense of loss of functionality, i.e.:

ICMP (which is 560 bytes, and also has a dependancy on ARP which is 514 bytes) - but then I would lose ability to do a ping from the c64.
DHCP - is 698 bytes
DNS - is 717 bytes (including the code to parse a dotted quad string i.e. '10.5.1.1.')

Dunno, I am always told that the cs8900 code makes it hard to write a suitable tcp/ip client solution.

However, does the Wiz stack provide performance enhancements that might make it useful?

Jim

If one was starting from scratch (i.e. without ip65, or contiku/uip or whatever) then it would definately be quicker & easier to create a tcp client app on w5100 than on cs8900a (since to do tcp on cs8900a, you would need to roll your own ARP & TCP layers).

But since there are already software stacks that talk to cs8900a, the question is, is it easier to write an app using those than using the native w5100 stack?

As the maintainer of one of those stacks, I obviously have a different perspective to most, since I will have a deep understanding of ip65, and it is thus easy for me to use. In any case, I think:

- for someone coming in cold, learning how to interface directly with the w5100 will have a similar learning curve to any other library (there are a few curly concepts, e.g. the way each socket has a circular buffer, that takes a bit of time to understand, and some of english in the datasheet is incoherent).

- learning from scratch, and then using, an existing library which has DHCP and DNS will be faster than implementing DHCP & DNS from scratch on w5100, and I think DHCP & DNS are essential for a TCP client.

- It would probably be possible to write a new library on top of w5100 that included DHCP & DNS, and would be smaller than ip65. Whether that library is easier to use than ip65 is a question of API architecture & documentation, rather than the chip on the NIC.



On my board (where auto-increment is flaky), it is definately slower to write a page of data to the w5100 than the cs8900a. However I can imagine it would be possible to use the w5100 in full memory mapped mode (i.e. with a latch that fiddled with /GAME and /EXROM at appropriate times, it would be possible to map in one of the a) the common & socket registers in wiznet address 0x0000 ... 0x7FF, or b) the TX buffers at 0x4000..0x5FFF, or c) the RX buffers at 0x6000..0x7FFF ) into say c64 address range $8000..$9FFF )

The upside though is (in ip65 at least) there are a few calls that are effectively delayed for a few network interactions. For example, in my TCP implementation, when you call 'tcp_send' to send data to a remote host, the ip65 stack doesn't pass control back until the remote host has ACKed the data. At best, there is a network round trip, at worst, there are timeouts & retransmissions, maybe even an ARP request as well. With the w5100 implementation, the call to tcp_send returns as soon as the data is written to the w5100 chip, and the chip handles ARP, retransmits etc. So application responsiveness is improved.

I found autoincrement tends to come unstuck if you write to the address registers at all. So when I want to use it, I manually set it before writing each block of data. Not sure if that's the problem you're experiencing or not.