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...
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.
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.
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 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.
HttpFileServer65 is inspired by "HFS ~ Http File Server" (http://www.rejetto.com/hfs/). It features an intuitive mapping of local disks and directories to HTTP paths. This allows to not only navigate to some file but to directly enter some file URL. This is especially usefull for downloads via wget, curl or alike.
However, in contrast to HFS it doesn't allow file uploads, only file downloads. On targets with complete DIO support it additionally allows disk image downloads.
Note: The Atari build currently fails as there's so far no getdevicedir() in the Atari C library.
Given that Telnet65's 80 column display requires an enhanced Apple //e anyway it seems reasonable to have the C applications benefit from building for that target too.
The date application isn't of much actual use. But it shows
- how easy to use the IP65 C API is
- the power of combining IP65 with the C library
(going from SNTP time format to a date string in two lines of code)
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).
