The cc65 tool chain comes with V.24 drivers so it seems reasonable to use the existing Contiki SLIP driver to implement network access via SLIP as alternative to Ethernet.
Some notes:
- The Ethernet configuration was simplified in order to allow share it with SLIP.
- The Contiki SLIP driver presumes an interrupt driven serial receiver to write into the SLIP buffer. However the cc65 V.24 drivers aren't up to that. Therefore the main loops were extended to pull received data from the V.24 buffers and push it into the SLIP buffer.
- As far as I understand the serial sender is supposed to block until the data is sent. Therefore a loop calls the non-blocking V.24 driver until the data is sent.
On all platforms there's only one V.24 driver available. Therefore V.24 drivers are always loaded statically.
On the Apple][ the mouse driver is now loaded statically - independently from SLIP vs. Ethernet. After all there's only one mouse driver available. However there's a major benefit with SLIP: Here all drivers are loaded statically. Therefore the dynamic module loader isn't necessary at all. And without the loader the heap manager isn't necessary at all. This allows for a reduction in code size roughly compensating for the size of the SLIP buffer.
The log function writes directly to the screen. Combined with the usage of PFS this means that the POSIX layer of the C library isn't referenced anymore thus reducing the memory requirements.
Recently support for 80 column CONIO based on 320x200 graphics was added to the cc65 C library for the C64. This change leverages this for the IRC client and the web browser. Because not everybody prefers this 'soft80' display with its small 4x8 charbox the 40 column programs are still available as before (with the new programs called 'irc80' and 'webbrowser80').
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).
In order to have the wget command make some sense the write command should be present too.
- On the Apple][ reduction of the MTU seems to gain just enough RAM to have the (rather heavy-weight) full-blown C library file I/O working.
- On the C128 there's way too little RAM so there's no wget command but only the file commands.
- On the CBMs a dummy lseek() was necessary to have the read command link.
type process_data_t. This was an artifact when the choice was
made to use the void * type for the data parameter in processes.
Changed parameter 'void * data' of process_post_synch to
process_data_t for consistency.
Checked all the uses of process_start() in contiki and fixed casts
of the data parameter.
- The default mouse driver is now always named 'contiki.mou'.
- Alternative mouse drivers are present in the disk images.
- Users can select their mouse driver by renaming the files.
CFS_WRITE implies O_TRUNC which is implemented on CBM DOS by deleting an
exsisting file. Hoewever this succeeds only if the CBM DOS filetype matches.
We need a working O_TRUNC in order to be able to overwrite the contiki.cfg
configuration file.
Note: Now it has be clarified why overwriting the configuration file started to
fail the CBM PFS (platform file system) can be activated for the recently added
ethconfig program.
Since introduction of mDNS (f145c17039)
the resolver process initialization depends on the tcpip process
already being initialized (because of the call to udp_new()).
- 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.
Relevant cc65 changes...
General:
- The compiler generates "extended" dependency info (like gcc) so there's no need for postprocessing whatsoever :-)
- The linker is very pernickety regarding the ordering of cmdline options so a custom linker rule is necessary :-(
Apple2:
- The various memory usage scenarios aren't specified anymore via separate linker configs but via defines overriding default values in the builtin linker config.
Atari:
- The builtin linker config allows to override the start addr so there no more need for a custom linker config.
- The C library comes with POSIX directory access. So there's no more need for for a custom coding.
CBM:
- The C library comes with POSIX directory access. So there's no more need for for a custom coding.
Oliver Schmidt
Víctor Ariño
Roy Scheefhals
Adam Dunkels
Rémy Léone
Oliver Schmidt
Nicholas J Humfrey
oliverschmidt