If the user fails to set the disk tool variable(s) he now doesn't get syntactically wrong commands but rather file-not-founds. Maybe he even chooses to drop tool(s) into the current directory or add the disk tool path(s) to the PATH variable...
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.
Now that we have per-target combo driver wrappers we can remove the W5100 support from the C64. There isn't any actual (known) W5100-based solution for the C64.
I don't have plans to support C programs on the VIC20. So now that there are C test programs the simplest solution is to not (try to) build VIC20 test programs as part of the default recipe.
In contrast to the multiple UDP callbacks there's only one TCP callback so it easy to provide a wrapper for the C callback that pushes C parameters on the stack.
Now that we process incoming data from the main loop - and use 'buf' both for incoming and outgoing data we should of course make sure that we never trash the incoming data with outgoing data.
The C test program may serve as copy & paste templates so it should make clear that ip65_process() is supposed to be called pretty regularly. Additionally it isn't supposed to be called recursively meaning that recv callbacks need to return quickly and defer longer processing.
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).
Now that with Telnet65 there is a "real" application there's no point anymore in the
ip65demo.dsk. Therefore httpd.slotscan is now part of the ordinary ip65test.dsk.
Re-added VT100 test that was created for KIPPERTERM development. Not very usefully as-is but a good template for any offline VT100 rendering test/debugging.
Additionally the disk images were renamed to distinguish them from the disk images created in the apps directory.
The W5100 TCP driver is intentionally very similiar to the UDP driver. It comes with its own test program (again similiar to the UDP test program) and an extension to the communication peer program to support the test program.
In order to ease exploring the W5100 UDP driver a simple test program using it was added. Additionally a communication peer program was introduced. The latter builds as-is for Windows using i.e. the VC++ command line 'cl w5100_peer.c'.
The Apple 2 web server now uses the "combo" library and optionally uses a2_set_slot to scan all slots for the Ethernet card. Combining both with DHCP allows for complete auto configuration.
Up to now every IP65 library contained exactly one Ethernet driver. In scenarios without strict memory limitations I might however be benefitial to have an IP65 library containing all Ethernet drivers available for a given target.
The Ethernet hardware detection that was already present before is used in this scenario to try to initialize one Ethernet driver after the other until one succeeds. If all drivers fail to initialize the user gets informed as usual.
The WIZ811MJ driver was primarily introduced for orthogonality reasons. There are however at least two W5100-based prototypes for the C64 so it makes at least some sense. The name was chosen as sort of placeholder for "something containing a W5100 chip".
The HTTPD program seems to be the only one somewhat useful for demo purposes. So I added the option to build a "IP65demo" disk containing it for all supported Ethernet devices - currently for the Apple2 only.
