First, a super short intro on me: I've been an Apple II user since 2004, and I started learning 6502 assembly language in 2010, which not coincidentally is when I joined this forum. My last project was a multitasking system called the Mouse Multitasking Demo in 2014, and the project that I'm now working on this year is a TCP/IP stack called Marina.

I don't do any cross-assembly, but instead do all programming and debugging on an Apple IIe using the Merlin Pro editor/assembler. (I will admit however that in the multitasking project, I did debug the ISR in an emulator, because I'd have been foolish not to!)

The Marina IP Stack

So, on to the main subject! The Marina project is not even a year old; I started writing it February 1st this year, and the latest release was last month.

Marina is the newest TCP/IP stack for the Apple II series, written in 6502 assembly language only. Marina uses the Uthernet 10 Mb/s Ethernet card by A2RetroSystems to connect to an Ethernet LAN. I'm also working on a driver for the new Uthernet II. With Marina, the Apple assembly language programmer has access to the UDP, DNS, ICMP, and IP protocols through a Berkeley sockets API. Written with performance in mind, the send throughput of Marina on a standard Apple II can reach 15 packets per second. The October 2015 edition of Marina adds Multicasting level 1 conformance and several improvements to the ARP and ICMP implementations.

Project Goals

I had two goals in mind for writing Marina:
1. To learn more about Ethernet and TCP/IP networking
2. To create a new TCP/IP stack for the Apple II that had more robust RFC compliance than the existing implementations

Interesting Features

Marina has several features not present in other TCP/IP implementations for the Apple II, including:
1. A Berkeley sockets API
2. An automatic DHCP client more compliant with RFC 2131.
3. An ARP implementation fully compliant with RFC 826.
4. A Link-Local addressing implementation following RFC 3927.
5. Address conflict detection implementation following RFC 5227.
6. Separate send buffers for the ARP, DHCP, and DNS modules.
7. A split-buffer design for sending user datagrams to eliminate copying blocks of data.
8. A more robust Ethernet driver that verifies each Ethernet frame has been successfully transmitted.
9. A special-case checksum routine optimized for 20 byte IP header checksums.
10. Robust error and consistency checks for incoming data.
11. Multicast level 1 conformance

Documentation

Marina is fairly well documented for a one-man project. There is a 6-page User's Manual which covers the basics, but there is also the Marina Technical Library which contains several documents describing various aspects of the system, including algorithms, source code excerpts, and implementation notes.

The source code also is pretty well commented, though I am working my way through it and improving both the number of comments, and also the formatting of them to ensure that the source is more readable.

A technical overview of the whole system, layer by layer, is given in the document Marina from the bottom up, which may be a bit dry, but it's all we've got, other than just reading the source code!

Challenges in the Design

The first challenge in the design of Marina is that the Apple II has no built-in clock or timer (except for the last model, the Apple IIgs). There isn't even a VBL interrupt on all models, and compatibility is something I want to keep for as long as I can. This will make implementing TCP retransmissions a little tricky, I think.

The second challenge is that some of the existing network interfaces don't support IRQ, meaning that I have to poll the device to see if there's new data from the network. If I don't poll fast enough, packets get dropped. Now I realize that with TCP, there will be retransmissions, but what about UDP datagrams? I'd like to avoid dropping packets as much as I can.


Testing the DNS resolver, June 2015:

That's really neat. I wonder if it can be generalized to non Apple II 6502 machines?

Probably so. I'm not using any special features to the Apple II, such as bankswitching, or ROM routines, in the core part of the stack. The network driver would of course need to be changed, but I'd imagine that the thing could be ported to another system probably with less than a week's worth of work. Total size so far is about 10 kilobytes.

I currently have two Ethernet drivers: one for the CS8900A that is fully debugged and working, and another for the W5100, which is only partially completed. I also plan on writing a SLIP interface for a serial connection, but that's low priority.

I too echo Martin_H's comments. Looking forward to further reports on this project as you move it forward. I would certainly be interested in the W5100 implementation. I've looked at including that particular device into another project, and would be interested in hearing of any problems and how it compares to using the 8900.

_________________
Michael A.

I'll eventually be interested in attaching a network interface to POC V2. Naturally, I'd be interested in porting your code to the 65C816.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I could talk your ear off on that score. I beta tested and wrote the manual for the Uthernet II by A2RetroSystems, the NIC for Apple II that uses the W5100. The manual has a fairly respectable section on programming the W5100.

Basically, the number 1 gripe about the thing is on transferring data to/from the chip. The W5100 doesn't virtualize on-chip buffer addresses like the CS8900A. What this means is that if you overrun the buffer, you run off into lala land. So your 6502 code has to anticipate this condition, and if you reach the end of the W5100 buffer, your 6502 code has to reset the W5100's address pointer back to the start of the buffer.

Ick.

Other than that, once you've got your glue/interface code debugged and working, it's a lot nicer than the CS8900A because it…. has its own TCP/IP stack!! And IRQs work! And it has a bigger on-chip buffer!



John Brooks has told me that he's probably going to write a 65C816 driver for the W5100, as used in the Uthernet II card for Apple II.

Thanks for the information on the W5100. It's too bad about the lack of address pointer wrap logic, but it is good to hear that it provides value because of its on-chip TCP/IP stack. Will continue to consider it for my next project.

_________________
Michael A.

The IP65 project has drivers for the W5100. One is in C, the other 6502 assembly.

I'm writing my own of course.

Is this going to be a generic driver or one tailored to the Apple ][ hardware? Also, who is John Brooks?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

https://twitter.com/jbrooksbsi

https://groups.google.com/forum/?fromgr ... Kgkr8wvltM

http://a2central.com/6630/john-brooks-r ... e-utility/

Mike B.

I'm guessing from reading all that that it will be an Apple-specific implementation.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

It's going to use the $Cx page slot I/O addresses for Apple II, but other than that, I don't think he'll be using any special tricks unique to the Apple IIgs.

June 2016 edition is out today. Adds several improvements to ICMP support, most notably, Marina now replies to pings!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

The web site is now at https://macgui.com/marina/

What happened? I never completed the TCP, and I moved on to other projects. :-/ I learned 68000 in 2019 and haven't looked back since.