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.
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.
The set of relevant drivers is after all different for each target. Building the combo driver wrapper individually opens the option to use .ifdef's to only include the drivers relevant for a certain 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.
The W5100 can be accessed pretty well from C without any library. A C program doing so is of course incompatible with the Uthernet and the LANceGS. So the program needs to make sure that that there' an Uthernet II. It can do so by comparing 'eth_driver_name' with "Uthernet II". However, when space it tight it doesn't seem reasonable to link all Ethernet drivers in the first place.
This is just for the "C" interface of IP65. clk_timer.s replaces
atr_timer.s (on Atari) and is new for the C64 (there wasn't an
implementation for the "C" interface before).
The C library allows us manage de-initializations via atext() so we can avoid the explict timer_exit call necessary in atrtimer.s (used for assembler programs).
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).
This was probably an artifact from early stages of porting to the
Atari. Problem manifested itself e.g. when hitting DEL in the middle
of a 'bash' input line.
The change also includes some cleanups as suggested by Oliver.
The vertical blank interrupt (which is used by the timer) runs with
60Hz on NTSC systems and 50Hz on PAL systems.
This commit also clears 'vbichain' in 'timer_exit', so a subsequent
'timer_init' would do the right thing.
FreeBSD and NetBSD, at least, have a banner message when you telnet into them
which has an empty line as first line. On those systems, an old "cursor" char
was visible at the top of the login prompt message.
This is fixed by enabling and disabling the cursor in 'get_key' while waiting
for a key press.
So far most of the time the cursor drawing was handled with a 'jsr COff - jsr COn' bracket around the drawing code. However in the area of screen erasing a different approach was used - which caused subtile issues.
4d729ec839 already fixed (most ?) of those issues for the Apple II and the ATARI. However it broke the approach 'jsr COff - jsr COn' brackets.
This is now adjusted - for all machines.
In order to manage upcoming changes relevant to all machine types it's important that the files are easy to diff. This change improves the similarity between a2<...>.s and atr<...>.s.
Lars informed me that $F142 by default produces ASCII code 0 via Ctrl-@. One just needs a way to distinguish it from the no-key-press.
This means that the further processing can be done in that same as on the Apple II - meaning to just replace in the VT100 keyboard translation table $00 with $FF as code for ignore-key.
Chris made me aware that ASCII code 0 actually is a valid character (usually entered as Ctrl-Space or Ctrl-@) and that it is actually used (i.e. by EMACS).
The Apple II allows to natively enter the ASCII code 0 via Ctrl-@. However so far get_key_if_available returned 0 in accumulator to signal that no key was pressed. In order to allow the Apple II get_key_if_available to return the ASCII code 0 in the accumulator I changed it to use the carry flag to signal that no key was pressed.
Because get_key_if_available needs of course to behave the same on all targets I changed the other implementations to use the carry flag too.
Unfortunately I don't know enough about input capabilities of the C64 to decide on how to best get Telnet65 to send ASCII code 0 there.
On the C64 the cursor is flashing (driven by a timer interrupt routine). So in order to have the cursor appear all it takes is to make sure that the interrupt routine:
- understands that it should actually work on the cursor
- has a correct understanding about what char is "under" the cursor
On the Apple II on the other hand the cursor has always to be actively drawn. Therefore all the places where the C64 code just updates the char under the cursor the Apple II code needs to actually draw the cursor.
We learned this the hard way with 'nvi'. When pressing <enter> in insert mode it sends the following data:
0d 00 1b 5b 31 42 1b 5b 4b
This means to return the cursor (to col 1), do nothing, then move it down 1 row and finally remove all chars from the cursor to the end of the line. The latter is one of the instances requiring to actively redraw the cursor (when set to be visible) as it was removed (when set to be visible).
It's imho in general a pretty unfortunate design to have IP65 check the keyboard during blocking operations. Rather it should call back into the application and have that decide what type of user abort it wants to offer.
Anyhow I don't want to change all that - at least not now. Therefore I just added the option to influence which key is considered the abort key - and provide a key value that isn't actually used and as such disables the abort check.
In order to allow setting the Apple II slot from host computer independent code the slot setting function was renamed and dummies were added for the other host computers.
