[cc65] Contiki on the Atari

Hi,

I just wanted to tell you that I received today positive feedback from
Dan Winslow regarding my port of Contiki to the Atari :-) That means
that beside the C64, C128 and Apple II now the Atari is the fourth
machine supported by the official Contiki code base.

First of all thanks to all who helped me getting up to speed regarding
Atari knowledge!

For me personally it was yet again a great experience to see how easy
it is with cc65 (and its C libraries) to re-target a quite large
project to a new machine. The productivity cc65 (together with free
emulators, free disk image tools and knowlege on the net in general)
makes possible today is really amazing...

Some additional remarks on the on the port of Contiki to the Atari:

- I noticed once more that the POSIX interactive input functions (i.e.
gets() ) are the ones with the biggest deviation in functionality on
the different targets: Is a cursor displayed? Is <Backspace> possible?
What happens on <Backspace> if there's nothing to delete? Does on
<Enter> get a \n printed? ...?

- Even with a modified start address of $2000 (instead of the default
$2E00) the builtin linker config has a RAM memory area even smaller
than the C128 one (which was so far the Contiki target with the
smallest RAM memory area). As there's however on the Atari "only" one
Ethernet solution there's no need to load the Ethernet driver
dynamically. So I use on the Atari co65 "productively" to link the
Ethernet driver statically. Because Contiki itself doesn't use the C
heap that change means that not only the module loader but also the
heap manager is omitted. Together with some minor Contiki config
changes this approach made it fit.

BTW: There might be scenarios which could benefit from the module
loader not being hardwired to the C heap but allowing to provide an
alternative memory manager (either at link time or as callback like
the read callback). Just think of an application that doesn't use the
heap at all but wants to load a single module (let's say a tgi
driver). With the module loader not being tied to the heap manager one
could provide a naive memory "manager" just returning on every call a
pointer to the first byte behind the end of BSS.

Regards,
Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.