I. Build Ethernet drivers individually for each target.
After all the Ethernet cards/carts are different enough to ask for customized drivers. Building the drivers individually opens the option to use .ifdef's to customize them.
II. Removed Ethernet driver I/O base.
So far the base address of the Ethernet chip was a general property of all Ethernet drivers. It served two purposes:
1. Allowing to use a single Ethernet driver for a certain Ethernet chip, no matter what machine was connected to the chip.
2. Allowing use an Ethernet card in all Apple II slots.
However, we now use customized Ethernet drivers for the individual machines so 1.) isn't relevant anymore. In fact one wants to omit the overhead of a runtime-adjustable base address where it isn't needed.
So only the Apple II slots are left. But this should rather be a driver-internal approach then. We should just hand the driver the slot number the user wants to use and have the driver do its thing.
III. With per-target Ethernet drivers we can have per-target MAC addresses.
IV. Added support for RR-Net MK3 unique MAC addresses.
The RR-Net MK3 can be operated in two modes:
- In cartrigde mode it has a startup-ROM that sets the CS8900A MAC address to the unique MAC address.
- In clockport mode the driver has to read the two lowest MAC address bytes from the EEPROM and combine them with 28:CD:4C:FF.
See http://wiki.icomp.de/wiki/RR-Net#Detecting_MK3 for details.
The driver first checks if the current CS8900A MAC address starts with 28:CD:4C:FF. If it does, it overwrites its built in default MAC address with the CS8900A MAC address.
If the CS8900A MAC address didn't start with 28:CD:4C:FF, it checks if there are two valid MAC address bytes in the EEPROM. If they are there, it overwrites its built in default MAC address with a combination of 28:CD:4C:FF and those two bytes.
V. Added support for the upcoming 'Dracarys' Ethernet PBI for the ATARI.
See http://atariage.com/forums/topic/287376-preannouncement-dragon-cart-ii/ for details on Dracarys.
So far there was only one Ethernet solution for the ATARI. Therefore the relevant driver was loaded statically. With now having two solutions we have to load the corresponding driver dynamically (like on the other machines). Fortunately this doesn't mean significant additional overhead as there are several mouse drivers for the ATARI asking for dynamic mouse driver loading. Therefore the dynamic driver loading infrastructure was linked already.
Another aspect of more than one Ethernet solution is that the Ethernet config program becomes necessary on the ATARI to select the correct driver. Although that program is pretty simple and therefore rather small it means that now only one "major" program fits on a 130kB disk. So we need now 5(!) 130kB disk images instead 3 so far.
If the setup of socket 0 to 3 with 4+2+1+1KB is detected then the W5100 is _not_ initialized, otherwise it does set up socket 0 and 1 with 4KB each. Either way socket 0 is used - now with 4KB instead of 8KB as before.
There are scenarios in which it is beneficial to search for an Etherne chip at several i/o locations. To do so the chip initialization is performed at several i/o locations until it succeeds. In order to allow for that operation model the i/o location fixup needs to be repeatable.
Note: This won't work with the RR-Net because the fixup bits overlap with the chip i/o bits.
Made Ethernet drivers easier to consume by assembly programs.
* Replaced function pointers with JMP instructions.
* Provide return values additionally via Carry flag.
Reset Ethernet chips on initialization.
Both for the CS8900A and the W5100 the data sheets just say that
the RESET bit is automatically cleared after the RESET. This may
be interpreted in two ways:
1) There's no need to be afraid of reading the RESET bit as 1 and
unintentionally trigger a RESET by writing it back after ORing in
some other bit.
2) The RESET process isn't complete before the RESET bit hasn't
become 0 again.
It's impossible for me to empirically falsify the latter option
as the drivers are supposed to work on faster machines than the
ones I have access to. And if the RESET process includes things
like oscillators then the time to complete the RESET could differ
even between multiple exemplars of the same chip. Therefore I
opted to presume the latter option.
However that means a non-exsistent chip may cause an infinite
loop while waiting for the RESET bit to be cleared so I finally
added code to detect the presence of the Ethernet chips. There's
a risk of a chip being locked up in a way that makes the detection
fail - and therefore the RESET not being performed. This catch-22
needs to be solved by the user doing a hard RESET.
It cannot be ruled out that access to the address register triggers
an address auto-increment. Therefore a temporary address register
shadow is introduced to replace the access to the address regsiter.
Additionally there are several minor beautifications.
