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.
- 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
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 .2mg image format contains a header which is missing from our file. So our file is rather a .po image.
I opted to not add the .2mg header as it is only necessary if the metadata it contains differs from the values "guessed" when using the "naked" .po image format. On the other hand there are image file consumers not understanding the .2mg image format.
- By end of Jan 2014 SuperTweet.net was shut down (http://supertweetnews.140plus.com/). So Breadbox64 has come to an end for sure :-(
- The email app - or rather email sending app as it is SMTP only - can't be used anymore since nowadays everybody uses some "strong" authentication for SMTP session logon (thanks NSA).
- The ftp client app isn't very useful as it supports only download - for which the WGET app is almost always more useful for. But more important it doesn't support PASV which is more or less the only supported mode nowadays (especially over NAT).
- 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.
Better match user expectations by allowing to download plain disk images and configure the IP settings afterwards on the target machine - then most likely leveraging DHCP. This works for the users with the most usual Ethernet adapter and settings - which are now pre-configured in default.cfg's. Only the few users with non-default Ethernet adapter and/or settings are required to download a custom contiki.cfg and inject it manually into their disk image files.
The Atari disk image tools don't allow to place contiki.cfg at a fixed location. Therefore the byte offset of the contiki.cfg content isn't constant :-( However using the tool adir with the option -r allows to learn the block number of the contiki.cfg content. So this block number is stored for each Atari disk image in the PHP code (in the array $blk) and translated into the correct byte offset.
This additional application results in three disks for the Apple2, two disks for the C64 and one disk for the C128. Therefore the download page can't get along anymore without some JavaScript adjusting the number of downloadable disks depending on the selected machine. With JavaScript turned off access to non-existent disks (i.e. disk 3 for the C64) results in a successfull download of a zero byte sized file - not exactly great but at least a defined behaviour.
