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.
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).
Apple II: The MouseText chars only allow for a partial representation of the VT100 Special Graphics glyphs. Additionally the MouseText chars are not available for reversed video.
C64: The VT100 Special Graphics repurposes the ASCII(!) code points $60-$7f. And the C64 custom font used places them on the same code points. Therefore it makes sense to "tunnel" them through the usual ASCII->PETSCII->ScreenCode processing pipeline by moving them as-is to otherwise unused PETSCII code points ($80-$9f).
The reverse characters of the alternate char set are place in a somewhat strange arrangement in the Apple II character ROM. This is because of backward compatibility with the standard char set. Therefore it seems more efficient and hopefully easier to understand to use a table to select them.
http://vt100.net/docs/vt100-ug/table3-6.html says that ESC O A..D is to be send if Cursor Key Mode is set and http://vt100.net/docs/vt100-ug/chapter3.html says "A mode is considered set until it is reset by a reset mode (RM) control sequence.". So ESC O A..D is the default.
Beside this spec perspective sending ESC O A..D instead of ESC [ A..D makes i.e. aptitude and midnight commander work out-of-the-box.
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).
