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.
After all there's no momentum for a W5100-based Ethernet solution on the ATARI. So I revert to static linkage of the CS8900A driver as this improves program load times.
The recently added doesclrscrafterexit() allows cc65 programs to determine if the screen will be cleared after exit(). If that isn't the case then there's no need to ask the user to press a key in order to allow him to read the final program output.
- platform/atarixl/Makefile.atarixl: put two more objects into high memory
- platform/atarixl/contiki-conf.h: define WWW_CONF_WGET_EXEC
- tools/6502/Makefile: add 'clean' target; remove unused CONTIKI define
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 cc65 memory map for the ATARI XL has two holes so the linker needs hints which object files go where. Source changes lead to object file size changes requiring now and then to rearrange the object files.
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).
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.
Since introduction of mDNS (f145c17039)
the resolver process initialization depends on the tcpip process
already being initialized (because of the call to udp_new()).
The new Atari XL target allows cc65 programs to make use of
the shadow RAM. This allows to turn aon all features of the
web browser - and will allow for additional improvements to
come :-)
Don't be afraid, I'm not trying to have more retro platforms than "real" platforms ;-)
The platform 'atarixl' will replace the platform 'atari'. However I need both for some
transition period.
