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.
Adam Dunkels writes on 2/5/2017 on the Contiki mailing list:
[...] the original idea was that the application could just point the uip_appdata pointer to wherever the data was, but we then changed it so that the data actually had to be copied into the uip_aligned_buf buffer. So, yes, the network device driver should only need to read from this buffer. [...]
This change removes comments on the possibility of uip_appdata pointing somewhere outside the uip_aligned_buf. And it removes code in the SLIP drivers not necessary anymore.
Additionally it makes code in a SLIP driver optional that takes care of the Microsoft-specific CLIENT / SERVER / CLIENTSERVER chat.
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 running serialdump does not recover from a disconnected device but
runs indefinitely with outputting anything. This makes it quit with a
proper error message.
termios i_flags were not initialized and could be set to arbitrary values
this resulted in unpredicted behaviour of the output like additional
newlines
- 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
CC_FASTCALL was introduced many years ago for the cc65 tool chain. It was never used for another tool chain. With a798b1d648 the cc65 tool chain doesn't need CC_FASTCALL anymore.
The email and ftp programs aren't relevant anymore so support for them was removed from the cc65 builds. The explicit 80 column programs were added. The 80 colum web browser and Telnet server are built for all cc65 platforms as they are the largest and as such show best code increase issues.
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.
Using clang (on osx) yields to some warnings
(conversion between signed/unsigned, unused variable)
which gcc would only produce when used with -Wall.
This commit fixes those.
When running multiple tunslip6 instances, it collides with tun0 being already
used (cannot open file).
However, system default is already to use "tun0" and "tap0".
By putting the default empty string as name, system automatically increment and
selects a free interface, "tun0", "tun1".
Previously, the Cooja mote assumed that its file was always initially empty (file.endptr == 0). Therefore, a file uploaded to a mote's CFS could never be read by the mote, as the mote would prevent reads from going past the EOF (indicated by endptr).
By tracking the file size and making it accessible to Cooja, the correct size of the uploaded file can be reported to the mote and allow it to read the uploaded file.
Refactored RadioMediumObservable to RadioTransmissionObservable because of its function
Added correct RadioMediumObservable and updating in AbstractRadioMedium, DirectedGraphMedium and MRM
Added some documentation
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).
