Jump to content
IGNORED

Stock IP65 for the ATARI


ol.sc

Recommended Posts

Hi,

 

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/oliverschmidt/ip65/commit/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/forums/topic/211161-dragoncart-software/?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.

 

Regards,

Oliver

ip65.atr

  • Like 8
Link to comment
Share on other sites

Good stuff. As Oliver mentioned, the IP65 library was where I started. The prototype I dropped a couple years ago taught me a lot, but I have since embarked on a major reorganization and there is little left of the original. The original IP65 is a capable system though in itself, and can form the basis of development for anyone interested. I will also be making the 'AIP' driver, as I call it, open source, including a direct C API and the ability to make CIO calls from any language. Right now I am implementing TCP, which I expect to take a few months, and probably will have a first release around the new year.

 

Oliver - if you get a hold of some atari hardware and would like a dragoncart, just let me know.

Edited by danwinslow
  • Like 2
Link to comment
Share on other sites

Hi,

 

Good stuff.

 

:-)

 

[...] including a direct C API [...]

 

Does 'C' refer to cc65 here? Anyway I'd appreciate if you write me a short email with a hint when it becomes available.

 

Oliver - if you get a hold of some atari hardware and would like a dragoncart, just let me know.

 

Thanks - but I have both a Dragon Cart (donnated by Mark) and a 130 XE (donnated by the ABBUC). I'm just currently > 1500 km away from both. I presume that Avery would like to know if HTTPD.COM works on real hardware. Therefore I'm asking here for feedback asap.

 

Regards,

Oliver

Link to comment
Share on other sites

Hi,

 

I just started converting IP65 to MADS format last week as a means of learning how it works. [...] One distant day I'll want a relocatable IP stack for the Graphical OS, and this seems an excellent way to start.

 

- The ca65 assembler comes with pretty extensive macro support. Maybe it's reasonable to have a single IP65 source usable for both ca65 and MADS...

 

- The ld65 linker already supports the .o65 relocatable format. It is designed to support multiple output file formats: http://cc65.github.io/doc/ld65.html#ss5.7Maybe it would make sense to add support for the relocatable format in question to ld65. That would btw. open the option to use the cc65 C compiler to produce files in that format too...

 

In general I'm wondering why there is so little communication about potential synergy effects. From my perspective open source isn't about grabbing source and doing with it what is necessary but about collaboration. I'm always against fragmentation - but seem to be rather alone with that idea...

 

Just because I'm no regular reader of the AtariAge forum and for sure no Atari guru that doesn't mean that I'm not approachable. I see my role as maintainer of cc65 and IP65 not as primary implementer but as manager of an upstream repo to avoid fragmentation. If you check out the cc65 git log you'll see that I'm actually not contributing a lot...

 

Regards,

Oliver

Link to comment
Share on other sites

Thanks Dan and Oliver both. The Graphical OS drivers use the MADS' assembler proprietary relocatable binary format, plus which I'm using ENUMs, structs and other stuff unique to the assembler in that project, so it won't be very generic. But if I can throw questions your way, I'd appreciate it, plus any other help, since I'm learning the whole protocol as I go. ;)

Link to comment
Share on other sites

Hi,

 

Re-reading my last message it now seems (too) easy to misunderstand :-( What I wrote wasn't meant as criticism of you. I regularly read threads in some forum about people discussing their issues with cc65. Those issues occur mostly from abusing the tools because of missing understanding. The result are pretty ugly workarounds. But they some to not even consider to join the cc65 mailing list and ask there for hints...

 

Anyway I'm happy that you doesn't seem to have interpreted my message in the wrong way :-)

 

Thanks Dan and Oliver both.

 

:-)

 

The Graphical OS drivers use the MADS' assembler proprietary relocatable binary format, plus which I'm using ENUMs, structs and other stuff unique to the assembler in that project, so it won't be very generic.

I see.

But if I can throw questions your way, I'd appreciate it, plus any other help, since I'm learning the whole protocol as I go. ;)

I'd be happy if I could add a little to the success of your GOS project - I read (most of) the corresponding thread here - pretty impressive !
Regards,
Oliver
Link to comment
Share on other sites

Re-reading my last message it now seems (too) easy to misunderstand :-( What I wrote wasn't meant as criticism of you. I regularly read threads in some forum about people discussing their issues with cc65. Those issues occur mostly from abusing the tools because of missing understanding. The result are pretty ugly workarounds. But they some to not even consider to join the cc65 mailing list and ask there for hints...

 

Anyway I'm happy that you doesn't seem to have interpreted my message in the wrong way :-)

I can see no problem here, unless there's a fundamental objection to acknowledged and credited use of open source code as the basis for a driver for a specific project. The GOS drivers and applications will be open-source anyway (what better way to encourage third-party development), but there seemed to me little point in trying to mould the main IP65 trunk into something which is simultaneously the stand-alone multi-platform project and every off-shot project which it happens to spawn. The GOS drivers use inter-process communication so in that sense the augmentations required to the current Atari code are not trivial. A while ago I asked Matthias Reichl if he would endorse the inclusion of his open-source high-speed SIO driver for the A8 in my PBI BIOS for the Ultimate 1MB. He happily agreed and I incorporated his driver into my code with what turned out to be relatively minor changes, although I did a lot of reformatting so the source "fit" into the host project. I was subsequently lucky enough to avail myself of Hias' debugging skills too. Most importantly (for me), studying, transcribing, and adapting Hias' code was a great educational experience for me, since I came out of it with a much better grasp of the SIO protocol. It would be wonderful if something similar could happen with the IP65 code, although at the end of the day, when the GOS driver API is published, anyone who wants to write an IP stack based on whatever code they like is absolutely free to do so. Me: I just like to know how things work. :)

 

I'd be happy if I could add a little to the success of your GOS project - I read (most of) the corresponding thread here - pretty impressive !

Fantastic - thank you! Expect many questions from me as I study the project more closely, and - as already said - contributions from those who want to write drivers when some API is eventually published would be very warmly welcomed indeed. ;)

  • Like 2
Link to comment
Share on other sites

  • 1 month later...

One distant day I'll want a relocatable IP stack for the Graphical OS, and this seems an excellent way to start.

 

Oh snap! My dream of being able to do my day job (web coding (vim), database (cli sql client), etc.) on my 1200XL may one day come true! ;)

 

(Technically, I could use Ice-T and some expensive RS232-to-Internet get-up, too, I suppose...)

Link to comment
Share on other sites

Such a driver is under development currently,although its targeted at regular Atari dos's and not at the amazing GUI FJC is doing. It is a heavily modified version of IP65 that runs in the VB and is driven by CIO calls. Should be out for Beta testing in a couple months.

Edited by danwinslow
Link to comment
Share on other sites

  • 1 year later...
  • 1 year later...

@8bit-Dude:

 

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.

 

Regards,

Oliver

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

@Oli: A CS8900A or W5100 or LAN91C96 with its registers mapped straight to some 6502 memory mapped I/O locations.

OK, that's a very concrete answer.

I am thinking of using an arduino with LAN module to prototype the hardware side, so I will investigate if I can get the same ethernet layer as hardware you listed
I assume that once the hardware is mapping these registers to a continuous memory block, then it is a simple matter of giving the start address to IP65.

Onto the next question then: Do you have a short list of those registers needed by IP65?

Link to comment
Share on other sites

> I assume that once the hardware is mapping these registers to a continuous memory block, then it is a simple matter of giving the start address to IP65.


That's exactly how it works.


> Onto the next question then: Do you have a short list of those registers needed by IP65?


This is something you usually get from the datasheets for the chips in question. However for your convenience:


CS8900A:



W5100 (in indirect bus I/F mode):



LAN91C96:



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...