Software Overview

When the board powers up, the processor starts to execute from ROM. The ROM contains a FORTH interpreter/compiler called CamelForth.

I have ported a number of other software environments for the board. Each of them can be started by issuing a command from CamelForth. These are the environments:

• Microsoft BASIC
• Lennart Benschop's 6809 debug monitor, BUGGY, with line assembler/disassembler and (custom for Multicomp6809) hardware single-step
• TSC's FLEX
• The open-source OS9 port, NitrOS-9 -- both Level 1 and Level 2
• Dave Dunfield's CUBIX
• Alan Cox's Fuzix

Only CamelForth is in ROM. The other environments are loaded from an SDcard and started under the control of CamelForth. All of them can co-exist on a single SDcard. For each environment I describe:

• How to start it (ie, what command to use)
• How it starts (the steps involved in getting it loaded and passing control to it)
• How its boot process works
• How to use it (or where to go to learn how to use it)
• How to rebuild it from source
• How to get the appropriate image files onto an SDcard

Of course, you might not want to use any of them, but to write stuff from scratch for yourself -- In which case you can use them as examples for guidance.

Memory Map

The memory map is straightforward (and is backwards-compatible with Grant's original design):

• I/O occupies 16 bytes from $FFD0-FFDF. I/O decode has the highest priority so that any ROM or RAM decoded at the same address is hidden.
• The ROM occupies 8Kbytes from $E000-$FFFF, which includes the address range $FFE0-$FFFF occupied by the CPU's exception vectors. The ROM is enabled at reset but can be disabled (and re-enabled) under software control. When the ROM is enabled its decode has the second highest priority so that any RAM decoded at the same address is hidden.
• The RAM is decoded from $0000 upwards ($0000-$07FFF for the 2Kbyte of internal RAM, if configured).

More details can be found in the Programming Guide