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.
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.
So far the sequence number for the first packet after the initial SYN packet was calculated directly before returning from tcp_connect. This is however far to late as the ACK packet to be send as response for the SYN,ACK packet sent by the server already needs that sequence number. Therefore it is now calculated right after a successful reception of the SYN,ACK packet is detected.
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).
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).
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.
