The VT100 has (P)F1-(P)F4 keys. The C64 F1-F4 keys are mapped them. Additionally the C64 F5-F8 keys are mapped to the XTERM F5-F8 keys. However as we pretend to be a VT100 applications tend to ignore them.
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 currently used font doesn't contain any Latin-9 glyphs so it doesn't make sense to try to process Latin-9 chars. Instead now only 7-bit ASCII chars are processed - as the original VT100 does. Setting LANG=C in the host shell should make programs aware of the fact that only 7-bit ASCII chars are to be generated.
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 commit e1a29ae411 was missing the font file. It sports the VT100 'special graphics and line drawing' glyphs in the chars $60-$7F. However so far the code to make use of them isn't implemented.
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).
The ][ doesn't have lower case but the //e defaults to lower case so we need to allow both upper case and lower case (and convert to lower case before DNS lookup).
On the A2 get_key deletes any already pressed key. Therefore it's a bad idea(tm) to call it to retrieve the key detected in get_key_if_available. So now get_key_if_available insteads retrieves the key on its own via direct hw access. This was already done the very same way in check_for_abort_key. And apart from not working as expected the benefit of get_key displaying a cursor wasn't useful here anyway because get_key was supposed to return right away with the pressed key so the cursor wouldn't have been visible at all.
- The C64 variant already used get_key and I don't see a reason why the A2 has different requirements when it comes to the question when it is necessary to call ip65_process.
- On the A2 get_key does display a cursor while get_key_ip65 does not. However get_filtered_input is used to get a string of characters. This is exactly the scenario asking for a cursor.
If the setup of socket 0 to 3 with 4+2+1+1KB is detected then the W5100 is _not_ initialized, otherwise it does set up socket 0 and 1 with 4KB each. Either way socket 0 is used - now with 4KB instead of 8KB as before.
There are scenarios in which it is beneficial to search for an Etherne chip at several i/o locations. To do so the chip initialization is performed at several i/o locations until it succeeds. In order to allow for that operation model the i/o location fixup needs to be repeatable.
Note: This won't work with the RR-Net because the fixup bits overlap with the chip i/o bits.
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".
Behave just like the CS8900A driver: Both the CS8900A and the LAN91C96 dynamically share a buffer for received packets and packets to be send. If the chip is exposed to a network with a lot of broadcasts the shared buffer might fill quicker with received packets than the 6502 reads them (via polling). So we might need to drop some received packets in order to be able to send anything at all.
The pretty small check_for_abort_key is used by DHCP and DNS which means it is used by about every IP65 program. The pretty large get_filtered_input on the other hand is very seldom used so it makes sense to put the latter in a separate module to keep it from ending up in binaries unused.
The previous chip detection was inspired by the old IP65 driver code. For some reason it didn't work as expected. The new code is simpler and based on this statement in the chip datasheet: "The upper byte always reads as 33h and can be used to help determine the I/O location of the LAN91C96."
* CS8900A
The Contiki driver allows to adjust the chip base addr at runtime (which allows to support different slots in the Apple II) and removes received frames from the chip if there's no room to send frames.
* LAN91C96
The Contiki driver was used by IP65 more or less unchanged in the first place.
* W5100
The Contiki driver allows to adjust the chip base addr at runtime (which allows to support different slots in the Apple II) and stays clear from the W5100 hybrid mode. It presumes a fully functional W5100 register auto-increment and pre-calculates necessary W5100 frame buffer wrap-arounds and thus achieves the maximal 6502 <-> W5100 transfer speed.
It's the very purpose of the DATA segment to consolidate all items that potentially need to be copied from ROM to RAM. So there's no need to / point in doing that on a per-item-base.
- Added exit_to_basic symbol.
- Aligned linker config with C64 linker config.
- Made switch to lower charset compatible.
Allow all test programs to run with LANceGS card.
Aligned C64 input file name.
- Tab chars were partially used with the unusual width of two blanks. I removed them altogether.
- Line endings were inconsistent even iniside individual files. I normalized them.
- I introduced a consistent coding style regarding comment indenting and blank line usage.
- I removed trailing spaces.
- I removed newlines following unnamed labels.
- ...
- Simplify Makefile by allowing to use suffix '_tcp' to denote the requirement to link against TCP-capable IP65 lib.
- Remove 'test' or 'test_' prefix from test program names - every program in 'test' is a test program.
- Have some more test programs switch to lower case charset on the C64.
- I'm no Ruby guy so don't rely on Ruby for building disk images.
