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).
So far the error value was set to KPR_ERROR_TIMEOUT_ON_RECEIVE on negative answer from the DNS server. Now KPR_ERROR_DNS_LOOKUP_FAILED (which was already defined) is set.
In general I consider the approach of a netmask length a typical case of over-optimzation - incl. the typical downside of an "unnecessary" bug. However as the optimization is already present I opted to not remove it but rather fix the bug:
So far the gateway was in usual environments only used if the target IP address differed already in the first byte from the local net IP addresses. Now the gateway is used correctly - even for i.e. the address 192.168.1.1 from the local net 192.168.0.x
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.
It's not save to presume any zero page variable to stay intact after using the Ethernet drivers to perform actual network I/O. In example a necessary ARP lookup may require network I/O in not anticipated scenarios. Therefore the tftp_filename is rather to be placed in a normal variable and copied to a zero page variable just-in-time.
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.
The W5100 TCP driver is intentionally very similiar to the UDP driver. It comes with its own test program (again similiar to the UDP test program) and an extension to the communication peer program to support the test program.
In order to ease exploring the W5100 UDP driver a simple test program using it was added. Additionally a communication peer program was introduced. The latter builds as-is for Windows using i.e. the VC++ command line 'cl w5100_peer.c'.
The Apple 2 web server now uses the "combo" library and optionally uses a2_set_slot to scan all slots for the Ethernet card. Combining both with DHCP allows for complete auto configuration.
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".
The HTTPD program seems to be the only one somewhat useful for demo purposes. So I added the option to build a "IP65demo" disk containing it for all supported Ethernet devices - currently for the Apple2 only.
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.
Of course one can just always call dns_resolve after dns_set_hostname. But an application might i.e. present a different user feedback depending on the fact if a name resolution is necessary at all. So given that DNS name resolution is already a two phase action it just seems natural to allow an application to read the already exsisting variable.
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."
