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.
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.
I would have expected that no matter what causes the TCP connection to be closed would be reported as a TCP call back with lenghth = -1. However there are scenarios where this isn't true. I.e. when the user aborts during a blocking TCP retransmit opration. I'm unsure if this behaviour is to be considered a bug or if this is by some design I don't understand.
So I opted to not change that behaviour but rather add an explicit check for tcp_send returning with an error indicating that the connection is closed. This way the users gets noticed on the closed connection at least on his next key press.
It might be welcome to be able to abort DHCP, DNS and TCP connect operations. However while we're connected to the remote host we need full control over the keyboard. If TCP send operations don't work immediately the user will just have to wait until they do (or the timeout).
On the Apple II the timer_read function is actually a delay function. Therefore we want to avoid calling it if we're busy processing incoming data. Fortunately timer_read is only necessary to trigger a TCP keep alive message. But if we're busy processing incoming data then we for sure need no TCP keep alive. So we simply mark if we just processed incoming data and skip the timeout check.
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).
