Jump to content

ol.sc's Photo


Member Since 6 Nov 2010
OFFLINE Last Active Dec 13 2018 11:24 AM

#4175870 Stock IP65 for the ATARI

Posted by ol.sc on Wed Dec 12, 2018 5:44 PM



A classic Ethernet chip "only" takes care of the Ethernet layer. This means that it's up to the 6502 to handle the TCP/IP layer. IP65 is such a TCP/IP layer for the 6502. Running the TCP/IP layer already takes away quite some resources from the 6502 not available to the "rest" of the running program. The Cirrus Logic CS8900A is such a chip - and the one usually used for 6502 based systems.


However with the rise of embedded systems there were enough systems with limited resource that there was a market to develop chips with integrate the TCP/IP together with an Ethernet (or WiFi) layer. After several rather expensive chips the Espressif ESP8266 and ESP32 are by now THE solution.


With the WIZnet W5100 Ethernet chip there's sort of a hybrid. It allows to be used both as pure Ethernet chip as well as TCP/IP+Ethernet chip.


So what type of chip to go for on what machine?


On the C64 there are quite some CS8900A-based programs. So RR-Net MK3 at the end stayed with the CS8900A used before although there was already a prototype with the W5100.


On the Apple II and the ATARI there are less network programs to be compatible with. Most/all relevant programs are based on Contiki or IP65. And both Contiki and IP65 allow to easily switch between the CS8900A and the W5100 (with the W5100 used as pure Ethernet chip). Additionally the W5100 brings options to develop code using the ESP8622 TCP/IP layer. 


On other machines I personally would consider this:


- On a machine with (nearly) 64kB RAM and reasonably well supported cc65 C library I tend towards the W5100. It allows to a) easily bring the existing Contiki/IP65 programs to the machine in question and b) make use of the W5100 TCP/IP layer for new programs.


- On a machine with (much) less RAM and/or weak/no cc65 C library I'd rather think about an ESP8266/ESP32 approach. In contrast to the W5100 the Espressif chips don't contain only a TCP/IP layer but additionally a DHCP client, DNS client and HTTP(S) client.


After these rather lengthy general remarks now for a more specific answer to "what would be the requirements in order to easily interface with IP65?": A CS8900A or W5100 or LAN91C96 with its registers mapped straight to some 6502 memory mapped I/O locations.




#4175709 Stock IP65 for the ATARI

Posted by ol.sc on Wed Dec 12, 2018 1:45 PM

>> 8bit-Dude: Oli, I have a question: [...]


> tschak909: Short answer, [...]


I wasn't aware that you call yourself 'Oli'.

#3886844 Telnet65 for DragonCart

Posted by ol.sc on Thu Nov 9, 2017 11:03 AM

I'm for sure no Atari guy so maybe I'm wrong - but I think our 6502 machines tend to be powered on and off rather quickly / often. But any Linux SoC thingy takes ~30 secs to come up and usually wants to be shut down cleanly. So I'm with you that I prefer clean integrated solutions I have by now come to the point to see the Linux SoC as an optional add-on.

#3871496 Telnet65 for DragonCart

Posted by ol.sc on Thu Oct 19, 2017 9:43 AM



I tried the wget and the browser [...]


Are you refering to the Contiki web browser and the Contiki wget?


The menu item "save URL as" [...]


Neither the Contiki web browser nor the Contiki wget have any menu.


The web browser shows the text "Would you like to download instead?" - see



The wget shows a prompt asking "Save as:" - see



But maybe you are rather refering to some web browser / wget running on some box you are connected to via Telnet. Then it's obvious that you can only download files to the file system on the box you are connected to via Telnet. 


Even if you run the Contiki wget on your Atari you will only be able to download to a file in your Atari file system, but not to "raw blocks" on your disk. Maybe I'll provide a new wget that will be able to do the latter.




#3675227 Contiki - August 2015

Posted by ol.sc on Thu Jan 19, 2017 5:46 AM



For everybody finding this thread maybe without having the complete context...


By now I've set up my own Contiki download page. Please find my latest Contiki builds at https://github.com/o...ontiki/releases




#3664182 Contiki - August 2015

Posted by ol.sc on Wed Jan 4, 2017 7:13 AM

Hi Andreas,


Thanks for pointing out the ABBUC thread to me :-)


Just two remarks:


1. Returning to DOS

- IPCONFIG returns to DOS on using the UI buttons.

- WEBBROWS and IRC return to DOS on Ctrl-C.

- WGET returns to DOS when done.

- TELNETD and WEBSERV don't return to DOS.

When I tested the programs returning to DOS worked. The only idea I have is that your issue is related to the mouse driver used. In case you find something out I'd be interested to learn via email to ol.sc@web.de


2. Adding http://

As you'd expect the web browser checks if http:// is already entered - see https://github.com/c...wser/www.c#L333

I have no idea why this didn't / doesn't work for you.


Regarding websites "usable" with the web browser you may want to check out https://groups.googl...le2/JiWYnLf22YA




#3383588 Contiki - August 2015

Posted by ol.sc on Thu Dec 3, 2015 12:43 PM



Sorry - yesterday's .zip file didn't actually fully fix the issue - this one does (hopefully)  ;-)




Attached Files

#3372908 Contiki - August 2015

Posted by ol.sc on Fri Nov 20, 2015 4:46 AM

In my opinion a Telnet Client and an IRC Client would be the most usefull applications for CONTIKI.


Just to be sure there's no misunderstanding: The .ZIP files I'm attaching in this thread actually contain an IRC client - although likely not as feature-rich and/or bug-free as desirable. Regarding the Telnet client I'm absouletly with you!


Are there any activities on the Apple II / C64 side to implement such machine abstracted CONTIKI apps?


Not that I'm aware of - so I'd say it's an educated guess to say 'no' :-(


I'm pretty sure that the cc65 CONIO layer is both fast and feature-rich enough to be used as abstracted screen output layer. And if somethings would be missing I'd be willing to cooperate on extensions. I.e. I very recently merged a soft80-based CONIO variant for C64 to the cc65 GitHub upstream. So the C64 now has a 80 column web browser (and IRC client). With about no changes to the Contiki code base. If there were a cc65 CONIO based Telnet client (either using Contiki or not) then that would have got C64 80 column support "for free" too.


What I want to say it that good coders aren't excatly standing in line nowadays to work on retro Internetworking projects. Therefore I personally would like to see the scarce resource spent well. With cc65 you get highly optimized libraries for the individual target machines written by people at home on those machines. Remember that I ported Contiki successfully to the Atari without having ever written any Atari software before. And you certianly don't have to write everything in "slow and large" C code if you don't like to. cc65 comes with a macro assembler that is at least good enough to be popular for projects not making use of anything else cc65 offers.


So for a Telnet client one might decide to implement the actual Telnet data stream parsing in 6502 code and implement the configuration menu in C. And it would still benefit from the machine abstractions. I.e. Contiki is in general of course written completely in C (as it runs on a multitude of CPUs). But for the TCP checksum calculation there's a 6502 code alternative. And the CS8900A driver is written in 6502 code. But all this 6502 still runs the same on the Atari, C64 and Apple II.


The point I'm trying to make is: From my perspective there are valid design point between the extremes of "fully machine agnostic POSIX C" and "register level hardware hacking in 6502 asm". From my perspective it's about making smart choices what tool to use for what purpose.


Just my two cents,


#3368519 Contiki - August 2015

Posted by ol.sc on Sun Nov 15, 2015 10:08 AM



I fixed several issues and created new Contiki disk images.


I'm not in control over Contiki versioning - and even if I were I'd likely not bump the version for every code drop. So in order to allow you to understand what Contiki code base was used to create the disk images the ZIP files from now on contain a ZIP comment. It's a link to the Contiki GitHub page showing the last commits (incl. their date) that are part of the code base. For the ZIP file attached that link is https://github.com/c...commits/a161dc2




Attached Files

#3324006 Contiki - August 2015

Posted by ol.sc on Fri Sep 18, 2015 1:55 AM



First of all thanks for checking out the IRC client.


I am pretty sure you've already started working more deeply in the client ...


Actually the very opposite is true. I've basically never looked at the IRC client code.


I've personally never used IRC neither in the past nor now. I must admit that I'm personally not interested IRC. Maybe I just don't know what I'm missing but I'm not into any type of text chat / messaging.


Given the above I'd appreciate if you - or someone reading (and in contrast to me understanding) your post - would look at the souce and modify it to your needs. I'd commit to make sure that I'll have it merged into the Contiki upstream repo and create new disk images. See:




If that's impossible you'd need to provide me a step-by-step guide on how to reproduce the issue you describe, what part of the screen output differs from your expectation and how that part should rather look like.




  • w1k likes this

#3311109 Stock IP65 for the ATARI

Posted by ol.sc on Sun Aug 30, 2015 5:11 PM



The IP65 project page now reflects the addition of the ATARI: http://oliverschmidt.github.io/ip65/




#3309477 Stock IP65 for the ATARI

Posted by ol.sc on Fri Aug 28, 2015 8:15 AM



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.




Attached Files

  • Attached File  ip65.atr   130.02KB   122 downloads

#3303108 Contiki - August 2015

Posted by ol.sc on Tue Aug 18, 2015 4:08 PM



Thank you for the kind words Oliver.  I am very proud of the work we have done.




For me that was/is like standing on the shoulder of giants: On the one hand the Dragon Cart behaving totally identical to the CS8900A-based devices on the C64 and Apple II - and on the other hand the work Chris and others have put into the cc65 C library for the Atari (XL).


[...] but it only had a small part in my decision to put the next hardware production oh hold.


Good to know !




#3302763 Contiki - August 2015

Posted by ol.sc on Tue Aug 18, 2015 6:32 AM



I just wanted everyone to know I have updated the Atari Ethernet website with the latest Contiki, some website fixes and the current status of the hardware.  I have been enjoying and  monitoring this thread as well as the one on the WIZNET W5100.


As starter of this thread I feel entitled to add some words from my perspective...


First of all: Without you donating a Dragon Cart both to Chris and me the current Contiki wouldn't exist - thanks :-)


Regarding the (CS8900A-based) Dragon Cart vs. a potential W5100-based cart:


- The Dragon Cart has been - at least to my knowledge - the first Ethernet solution for the 8-bit Atari. Whatever should follow, that's still a fact !


- Even if there should be no more Dragon Carts built it's already virtually immortal through Altirra's Dragon Cart emulation:-)


- Even if there should be at some point a W5100-based cart that doesn't mean for me to drop Dragon Cart support. Remember that on the C64 there is no momentum for a (directly 65xx-accessible) W5100-based solution because of all the existing CS8900A-based software. That means to me that for all cross-machine projects (like Contiki) a 6502 TCP/IP stack with two Ethernet drivers (for the CS8900A and the W5100-Raw-Mode) will stay state-of-the-art. Not even talking about not just leaving the numerous customers of CS8900A-based solutions on the C64 and Apple II behind.


And finally: I would be very unhappy if my babbling about a W5100-based cart would be the reason for you to not realize your idea of a module-less CS8900A-based "Dragon Cart II" - without any alternative actually existing for Atari users interested in Ethernet connectivity !


Just my two cents,


#3297484 TCP/IP Offloading With The WIZnet W5100

Posted by ol.sc on Tue Aug 11, 2015 7:17 AM



In http://atariage.com/...ki-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...uct-item/w5100/


- WIZnet also provides a module containing the W5100, see http://www.wiznet.co...-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.