So far 80 column display was an attribute of a cc65 platform. Now each cc65 application can ask for 80 column display by defining WITH_80COL. Of course this is ignored by platforms incapable of 80 column display.
I see three types of application:
* Applications not benefitting from 80 column at all and in fact looking better with 40 column display. These are now using 40 column display. Examples: ethconfig, ipconfig
* Applications taking advantage of 80 column display if it is available without drawbacks. These stay as they were. Examples: Telnet server, web server, wget
* Applications needing 80 column display so urgently that it is likely desirable even if the display becomes harder to read. These come now in both flavors allowing the user to choose. Examples: IRC, web browser
Note: This change doesn't actually introduce any 80 column display with drawbacks. This if left to a subsequent change.
The default Telnetd idle timeout of 30 seconds seems somewhat short. Best to have it user-configurable (incl. the option to turn it off with an config value of 0).
- Up to now the web browser used several fixed size arrays to hold the various types attribute data of the web page. This turned out to be way to inflexible for any non-trivial web page. Therefore now all attribute data is stored in a single buffer one after the other as they arrive from the parser only occupying the memory actually needed. This allows for pages with many links with rather short URLs as well as pages with few link with long URLs as well as pages with several simple forms as well as pages with one form with many form inputs.
- Using the actual web page buffer to hold the text buffers of text entry fields was in general a cool idea but in reality it is often necessary to enter text longer than the size of the text entry field. Therefore the text buffer is now stored in the new unified attribute data buffer.
- Splitting up the process of canonicalizing a link URL and actually navigating to the resulting URL allowed to get rid of the 'tmpurl' buffer used during form submit. Now the form action is canonicalized like a usual link, then the form input name/value pairs are written right into the 'url' buffer and afterwards the navigation is triggered.
- Support for the 'render states' was completely removed. The only actually supported render state was centered output. The new unified attribute buffer would have complicated enumerating all widgets added to the page in order to adjust their position. Therefore I decided to drop the whole feature as the <center> tag is barely used anymore and newer center attributes are to hard to parse.
ProDOS requires for each opened file a user-supplied page-aligned 1024 byte i/o buffer. This makes the generic POSIX file i/o library contained in the cc65 C-library quite heavyweight.
In contrast the lightweight pfs implementation uses the uIP packet buffer as ProDOS i/o buffer. Therefore:
- Only one file may be open at any time.
- That file may not be open while the uIP packet buffer is used by uIP. The open()/read()/close() sequence should be completed before Contiki event scheduling or inside handling a single Contiki event.
- The uIP packet buffer must be large enough to hold the ProDOS I/O buffer. Depending on the position of the uIP buffer in memory this means between 1024 and 1024 + 256 bytes. Therefore in an Ethernet environment setting the MTU_SIZE to at least 1266 is safe (So the default of 1500 is just fine).
