The W5100 has the undocumented feature to wrap around the Address Register on an Auto-Increment at the end of physical address space to its beginning.
However, the only way to make use of that feature is to have only a single socket that uses all of the W5100 physical address space. But having only a single socket by defining SINGLE_SOCKET comes with downsides too:
One mustn't call into IP65 network functions anymore after w5100_config(). Additionally the program doesn't support 'W5100 Shared Access' anymore (https://github.com/a2retrosystems/uthernet2/wiki/W5100-Shared-Access).
If the user fails to set the disk tool variable(s) he now doesn't get syntactically wrong commands but rather file-not-founds. Maybe he even chooses to drop tool(s) into the current directory or add the disk tool path(s) to the PATH variable...
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.
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.
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.
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.
