Omitting the middle digit because it is '0' must only be done if the high digit was omitted too (because it was '0'). If the high digit is '1' or '2' (and therefore not omitted) then the middle digit must never be omitted.
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.
parse_url stores the URL selector in the output_buffer - which is currently 520 bytes. A new entry point called parse_url_buffer was added which instead stores the URL selector in a buffer provided by the user.
url_download now calls the new parse_url_buffer instead of parse_url. The buffer for the URL selector is simply the download_buffer. So the download_buffer is used twice: First to hold the URL selector to be sent as request to the server and then to hold the response received from the server.
However, the URL selector still can't exceed the MSS (aka 1460 bytes).
Note: The User-Agent string was shortened by two bytes as that allows a "default" URL (incl. 'http://' but without port number) of exactly 1400 bytes to end up as 1460 bytes URL selector.
Note: The URL selector is stored in the output_buffer - which is currently 520 bytes. Beside all of the URL (apart from a potential "http://") the 'get' and the 'http_preamble' have to fit into that buffer. Therefore URLs mustn't exceed 450 chars. However, we omit a check to avoid further code size increase as most of the time URLs are known to be much shorter anyhow. If the URLs might become large we just leave it up to the user to check their length.
- There was already an explicit code path for something like 'wwww.google.com/' but that code path ended up with the protocol type unset and the port set to 0. Now the protocol defaults to HTTP and the port defaults to 80.
- There was no provision for something like http://www.google.com', rather it was just assumed that the slash after the hostname is always found. Now there's a check if the slash is actually found, and if it isn't found then an empty path is explicitly used.
The HTTP callback is explicitly allowed to send the HTTP response on its own and set the carry to signal that. Therefore it seems reasonable to export httpd_send_response to allow the HTTP callback to make use of the given infrastructure to send the HTTP response.
Together with the recent change to provide the inbound data buffer address and length to the TCP callback function as C parameters this change allows the TCP API to get along without any global variable :-)
In contrast to the multiple UDP callbacks there's only one TCP callback so it easy to provide a wrapper for the C callback that pushes C parameters on the stack.
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).
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.
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).
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
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.
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.
Bobbi Webber-Manners
Oliver Schmidt
Jonno Downes
Christian Groessler