Now that we have per-target combo driver wrappers we can remove the W5100 support from the C64. There isn't any actual (known) W5100-based solution for the C64.
The set of relevant drivers is after all different for each target. Building the combo driver wrapper individually opens the option to use .ifdef's to only include the drivers relevant for a certain target.
After all the Ethernet cards/carts are different enough to ask for customized drivers. Building the drivers individually opens the option to use .ifdef's to customize them.
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.
Tweet65 is sample application for triggering an IFTTT maker webhook. If ~450 chars are not enough for the URL then either the IP65 output_buffer needs to be increased or url_parse needs to be modified to use a different buffer. E.g. when called from url_download then the url_download_buffer could be temporarily used to hold the 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.
Beside the code for the actual feature this change introduces analysis of the URL to extract a potential filename to be used for saving. Doing so was a prerequisite for disk download because the filename extension in the URL is the only hint for distinguishing ProDOS sector order disk images from DOS 3.3 sector order images.
So far only the URL input was potentially repeated. Now the file input is potentially repeated as well. For normal file paths there's deliberately still no check. But when entering a drive specifier ("!Sx,Dx") then it is checked for plausibility - and there's an additional confirmation question to keep the user from overwriting the "wrong" disk.
With now having both the URL and file input potentially repeated it became clear that loading and saving the input history shouldn't be repeated - and if the user quits without having entered a valid input the history deliberately isn't saved at all.
So far we were reading (much) more bytes from the W5100 than necessary when processing the HTTP header. The byte were memmove'd to the beginning of the buffer.
However, when downloading a DOS 3.3 sector order disk image (*.dsk / *.do) then we need to place every DOS 3.3 sector at a certain point in the buffer to avoid additional memcpy's later. Therefore the HTTP header processing mustn't read (or rather commit) any body bytes from the W5100. So we now just check for the "\r\n\r\n" after each and every byte. This is of course less than optimal but small/simple - and the header isn't supposed to be that large anyway.
- 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.
After quite some thoughts it was considered best to simply have the timezone configured in the source code and rebuild if a change is desired/necessary.
IP65 doesn't support TCP flow control. Therefore it doesn't make sense to write a program receiving a significant amount of data via TCP using IP65. From that perspective it makes sense that IP65's HTTP client doesn't allow to handle incoming data with a callback but requires a buffer being able to hold the whole HTTP body.
However, on the Apple II there's the Uthernet II card with its W5100 Ethernet controller chip. That chip has it's own TCP implementation supporting TCP flow control. Therefore the wget65 program uses the W5100 TCP capabilities for the HTTP client.
But even with the W5100 TCP implementation in place IP65 still plays a role for the wget65 program as it desires DHCP and requires (usually) DNS. Both are not supported by the W5100 capabilities.
Nowadays register variables are out-of-style. So if they appear in some source code they can be assumed to be explicitly meant for cc65, so don't ignore them.
- Maybe not all Apple II C programs want to use the special I/O buffer setup.
- All Make-target-specific variables should go at the top of the Makefile as they are user settings.
The W5100 can be accessed pretty well from C without any library. A C program doing so is of course incompatible with the Uthernet and the LANceGS. So the program needs to make sure that that there' an Uthernet II. It can do so by comparing 'eth_driver_name' with "Uthernet II". However, when space it tight it doesn't seem reasonable to link all Ethernet drivers in the first place.
The Apple II file I/O needs a $400 byte page-aligned buffer for every open file. The default implementation takes those buffers from the heap. However, if a program doesn't use the heap for anything else it is more efficient to place those buffers below the program at $800 by linking iobuf-0800.o and thus avoiding to link any heap code at all. If a program never opens more than one file at a time it can have its start address at $800 + 1 x $400 = $C00.
It may be useful to be able to run the C programs right from the selector (without loading BASIC.SYSTEM first). Or maybe run them on boot by placing the LOADER.SYSTEM as first file in the root directory.
If there's RTC active then the user can at least have the current date set. However, if the machine runs for several days the user needs to re-run Date65.
