Software

Love it or loathe it, it's hard to avoid it. I designed my system architecture so that it could run some existing software, to avoid having to spend lots of time producing it myself.

Atom BASIC Interpreter

This is quite handy for simple experiments. It is on a par with the 8052AH BASIC but with an added built-in assembler, text/graphics display, and PS/2 keyboard interface. Not bad, considering they are of similar size (8K, or 12K with floating-point).

BBC BASIC Interpreter

This is a much more capable language. It requires 16K ROM for the BASIC interpreter plus extra for the Kernel. Fortunately there is plenty of external ROM. The FPGA logic has to be modified so that the Atom's middle two 16K areas are swapped, as per the original language conversion board.

Cross-development Software Tools

For more serious applications, the PC is a much better development environment. You can develop BASIC programs as text files on the PC and download them through the LPT slave port, but it takes effort to cram programs into a BASIC with only 26 integers, 26 arrays and 26 floats. The assembler uses a slightly different syntax to be consistent with the BASIC: @ for immediate and # for hex. So I looked around for more serious tools.

Gnu C is the first choice that springs to mind, but there is competition. CC65 is specifically designed for the 6502, rather than Gnu which compiles to a virtual CPU that has to be implemented in each new target. Therefore CC65 can concentrate on optimisation for the one target.

Neither compiler is ported to the Atom or the BBC micro - yet. Not surprising as they were built for people to open and change ROMs etc. So most of the many parts were socketed. Their contacts will eventually tarnish leading to unreliable connections. A short drop was a well-known solution in the eighties. Twenty years later, not many of them are reliable. In contrast, machines not designed to be modified used fewer parts and soldered them directly to the PCB, making them fairly reliable even today.

CC65 compiles C to assembly code files, which are then sent to CA65 to produce object code files which are finally linked together by CL65. I have exercised CA65 by getting to to assemble source code for the Atom firmware. See http://www.stairwaytohell.com/atom/wouterras/ for the original disassemblies. So far I have object code but not binary files for verification.

Porting CC65 is something I'd rather leave to other people but it looks like I'm the default volunteer! I am currently having a look at the task. Most of the work seems to be in creating a run-time library for each new target. Some of the ready-written ones are quite large, but that does not mean that a lot of code is required to get started. In theory, one should be able to make a good start just by implementing code to read the keyboard and write to the screen. After that, one can just add target specific features one at a time.

TCP/IP

This will be essential if wishing to connect to the internet, which is the most interesting use of serial ports. It is non-trivial to implement TCP/IP, let alone applications that use it. I don't have the knowledge or time to do from scratch.

I have heard of a well-recommended book "TCP/IP Lean" by Jeremy Bentham, which has source code for the PIC. It is quite astounding to do something that complex in such a tiny device! I used to work with Jeremy at Arcom, and for some time he lived a few streets from me - although I didn't know it at the time. So I bought the book, 540 pages of detailed information.

Fortunately, there's software more suitable for the 6502. Adam Dunkel's website discusses his uIP tiny TCP/IP stack for small machines. Also designed for ease of porting, it has already been ported to quite a few machines. CC65 is the preferred compiler for the 6502-based machines.

Operating System

Adam Dunkel has also developed the Contiki graphical operating system. It uses his uIP software as the foundation. This looks a good candidate for the Atom.