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.
Independently from the aspect if the driver parameter is a base address or a slot number the parameter handling was changed too. For asm programs there was so far a specific init function to be called prior to the main init function if it was desired to chnage the parameter default. This was done to keep the main init function backward compatible. But now that the parameter (now the slot number) is only used on the Apple II anyhow it seems reasonable to drop the specific init function again and just provide the parameter to the main init function. All C64-only user code can stay as-is. Only Apple II user code needs to by adjusted. Please note that this change only affects asm programs, C programs always used a single init function with the Apple II slot number as parameter.
The IP5 usage of ld65 segments and zeropage variables was made compatible with cc65 C programs already a while ago. This commit is the next logical step which is to introduce the actual C interface to IP65.
IP65 for C programs shares the the ip65.lib / ip65_tcp.lib with IP65 for assembler programs. However the various libraries from the 'drivers' are not reused. Instead there's exactly one library for every target named ip65_<target>.lib. Those libraries contain only functions used by ip65.lib / ip65_tcp.lib.
TODOs:
- Introduce c64_timer.s and atr_timer.s.
- Add a C interface to the rest of the IP65 functionality (especially TCP).
The file telnet.s in the 'ip65' directory for sure wasn't belonging into a library as it contained a main loop. So I introduced an 'apps' directory for actual apps coming with IP65. The file telnet.s was moved to apps, renamed telnet65.s and heavily modified.
The file c64vt100.s was made up from several files taken from CaTer (www.opppf.de/Cater) and adjusted for the new use case. The was done before for KIPPERTERM. However this time I deliberately avoided unnecessary code reformatting to allow for as easy as possible integration of potential upcoming changes in CaTer.
The file a2vt100.s was copied from c64vt100.s and adjusted to the monochrome 80 column screen of the Apple //e. Again unnecessary code changes were avoided to allow to easily merge upcoming changes from c64vt100.s.
The files atrvt100.s and vic20vt100.s are for now just dummies to allow to successfully link Telnet65. Work for an actually functional Telnet65 would start with a copy of c64vt100.s (as it was done with a2vt100.s).
* CS8900A
The Contiki driver allows to adjust the chip base addr at runtime (which allows to support different slots in the Apple II) and removes received frames from the chip if there's no room to send frames.
* LAN91C96
The Contiki driver was used by IP65 more or less unchanged in the first place.
* W5100
The Contiki driver allows to adjust the chip base addr at runtime (which allows to support different slots in the Apple II) and stays clear from the W5100 hybrid mode. It presumes a fully functional W5100 register auto-increment and pre-calculates necessary W5100 frame buffer wrap-arounds and thus achieves the maximal 6502 <-> W5100 transfer speed.
- Simplify Makefile by allowing to use suffix '_tcp' to denote the requirement to link against TCP-capable IP65 lib.
- Remove 'test' or 'test_' prefix from test program names - every program in 'test' is a test program.
- Have some more test programs switch to lower case charset on the C64.
- I'm no Ruby guy so don't rely on Ruby for building disk images.
