Since end of 2013 I'm the maintainer of the IP65 6502 TCP/IP - located at http://oliverschmidt.github.io/ip65/
So far the machines officially supported were the C64 and the Apple II (and to some extend the 32kB VIC20). Today I added the ATARI: https://github.com/o...mit/6987df44ed2
I'm sure you may wonder how my work relates to Dan's work on IP65. Although I presume he can (and hopefully will) provide better background info here are some hints from my perspective:
1. Although IP65 was in general devided into machine-neutral code (in the ip65 directory) and machine-specific code (in the drivers directory) quite some C64 specific code slipped into the ip65 directory over time. I removed all that code and presume Dan did more or less the same. One of the benefits of doing so is that adding a new machine like I did now isn't much effort - at least for someone with system programming experience on that machine. In contrast I was totally clueless so I checked out what Dan did 2 years ago in http://atariage.com/...ware/?p=2734494
2. Both Dan and I would like to make creating Ethernet applications simpler in order to tempt more people to do so. However afaik our ways to archive that goal are very different.
2.1 Dan brings IP65 much "closer" to the ATARI and converts it into a "driver" (by i.e. moving its background processing into interrupt handlers) allowing ATARI programmers to access it in ways they expect.
2.2 I want to make IP65 accessible for cc65 C programmers. I already "normalized" its cc65 segment usage and zeropage usage. The primary work left is to make the actual IP65 API callable from C programs. And then there are some rather minor topics left like "normalizing" timer usage.
As you may know Contiki for the ATARI is built completely on the cc65 abstraction layers. So one can see that pretty powerful applications can be written in pure C. Given that the cc65 C libraries are written nearly completely in 6502 code the IP65 library fits in nicely - and it fits nicely into the cc65 idea of allowing for easy cross-machine programming.
At this point some may wonder how I position an IP65 callable from cc65 C programs in relation to Contiki:
- Contiki is about apps which "wrap themselves around" the Contiki TCP/IP stack. It takes quite some effort to understand the Contiki programming model. The result are fully event driven apps reacting on multiple network connections, keyboard events, mouse events, timer events...
- "C callable IP65" is about apps doing primarily other things but needing additionally some network connectivity.
- Contiki has a LOT functionality and is written completely in C thus taking up pretty much RAM but allowing to be compiled on other machines. I.e. my recent work on the Contiki web browser was completely done on Windows using Visual Studio. Without its excellent debugger I simply would have never reached the state it is in now.
- "C callable IP65" has more limited functionality (i.e. only one TCP connection) and is written in 6502 code. Thus it is much smaller but requires 6502 skills for debugging.
Anyway I'm talking here about vaporware as it is pretty unclear when I'll actually work on that C callable IP65...
Back to facts: Please find attached a disk image with the "usual" IP65 test programs. However those test programs are mostly either rather useless or broken. PARSER.COM, DNS.COM and GETURL.COM are supposed to do "something". The only sort of interesting program is HTTPD.COM which is a web server displaying a simple form and dumping the entered data to the ATARI screen after submission by a web browser.
Right now I have no access to an ATARI (and Altirra still has afaik some issues with Dragon Cart emulation) so I'd really appreciate if I would receive feedback from Dragon Cart owners here - especially on the web server.