To Do List

Here are some things that could be done, should be done, whatever.

MMC/SD (MultiMediaCard/Secure Digital card) support

lpc2106: The MMC/SD worked for the earlier versions for the lpc2106, using the SPI interface. That code may still work with this version of Riscy Pygness, but it needs to be checked. (It uses the mode that ignores CRCs. I would like to add the CRC support, so if someone would like to work out the algorithm for caculating the CRCs, I would be glad to add it.
lpc2378: The lpc2378 and lpc2368 have hardware support for MMC/SD, including the CRC calculations. Code needs to be written to advantage of this.

Other disk support

I would like to support SmartMedia Flash disks (because, with their parallel connection, they should be faster than MMC disks) in case MMC is not fast enough for some applications.
If the specs could be dug out, it would be nice to support SD (Secure Digital) flash disks using their native mode rather than merely their backwardly compatible SPI-mode. Apparently it is difficult to get the specs. Furthermore, it appears the built-in support on lpc2378 for MMC/SD does allow the parallel data path (4 wires) even though it is either native MMC mode or SPI mode, so this may give us all the speed we need (if anyone does timing tests, please let me know what you find out).
Maybe CompactFlash support. I have mixed feelings in that I love the 7-wire interface (4 important wires) of the MMC and hate the thought of the 50-wire (20 or so important?) interface to CompactFlash. On the other hand, if someone else does the work, it can't hurt to have it available.

File systems

The file fat16.forth in the distribution contains basic support for FAT16.

Documentation

I would be delighted to link to 13 write-ups of how you install the GNU ARM toolchain, Lisp, compile and download to the target, use the debugger (not very important), etc. I plan to describe the basics, but alternative (and perhaps more thorough) descriptions can't hurt.

Alternative threading models

The current version (16-bit tokens with lookup table) is a good compromise. It allows access to the entire address space and yet is quite compact. For anything that is not fast enough, we can drop down to CODE words. Still, we could have alternate threading implementations for special cases:

16-bit tokens with table for flash but 16-bit tokens without a table for RAM (good for chips with lots of flash but little RAM).
16-bit tokens without a lookup table for either flash or RAM (good for chips with limited flash and limited RAM).
32-bit tokens (addresses) for faster speed.
subroutine threaded code for faster speed.

Rewrite some high-level Forth words as CODE words (for speed)

such as CMOVE and CMOVE>

Move some words from the target to the host (for compactness)

such as .S, DUMP, DU