Simplest instructions for booting arrayforth from a USB key (jumpdrive, flashdrive): make newboot.cf.usb, with the USB key inserted as /dev/sdb, to overwrite the MBR and the first 312 sectors of the device with the arrayforth. The contents of this directory should probably be in /usr/src/clusterFix and the latest arrayforth in /usr/src/af-35f-g144a12-PD, to match my system, for the fewest problems.

For booting from a USB partition (partition 1), make newboot.cf.part. This assumes a bootloader like mbrboot which leaves the partition data pointed to by BP and SI, the disk as known to the BIOS in DL, and the booted partition number in DH.

Known problems: QEMU will boot arrayforth (make okadboot.cf.boot), but video mode 4144 only shows about the top 1/3 of the screen. It seems to be a bug in QEMU.

By loading showboot onto MBR of USB key, you can see what the BIOS provides to the bootloader: in the case of this eMachines E625, some interesting items are: DX = 0x0080, meaning first hard drive (not floppy!), and DS = 0x0040, pointing to BIOS data area.

/usr/src/af-* are the newest colorForth releases (af=arrayForth).

To do, in no particular order:

Get rid of in-line args and the subroutines that use them and then mess with the stack. It throws off disassembly and is totally unnecessary. (Done[?])

Get rid of dead code. At least some of the aforementioned in-line arg routines are dead. (Done[?])

Save boot device and partition info from BIOS and/or prior bootloader, so that load/save routines can use it whether booted from MBR of USB key or a partition of it. (Done)

Consolidate data as much as possible to avoid breaking disassembly.

Jump back and forth into real mode so as to be able to use the BIOS for read and write onto known boot device. (Done)

Determine video mode by scanning modes for 1024x768x32. (Done)

Save video and load video mode from variable, not forcing in-line code to be on word boundary as it is now. (Done)

Headers for all storage, particularly that used in high-level code (hex table pointed to by address currently).

Look into text-mode cF.

Look into getting rid of Huffman coding, instead using symbol table and string table like ELF files.

Move some of the debugging bootcode into mbrboot.nasm, verify its presence with some particular value pointed to by a register.

Licensing

I'd really like to GPL this, but since Chuck made it Public Domain it doesn't seem ethically correct to put a more restrictive license on it. Unless someone convinces me otherwise, all my code is Public Domain. And actually, "my" code is mostly cribbed from other online sources, most of which are cited in the comments.

Sources

colorforth and arrayforth are from Chuck Moore and the GreenArrays company, websites colorforth.com and greenarrays.com respectively.

mandelbrot.f is Charley Shattuck's, I found on StrangeGizmo.com.

cf2010 is an older-kernel colorForth with lots of extra features accumulated by the cf hacker community over the years and put together by Howerd Oakford at http://www.inventio.co.uk/.

ciasdis and .cul files are from Albert van der Horst and are available from his website http://home.hccnet.nl/a.w.m.van.der.horst. These provide another way to disassemble and reassemble colorforth binaries.

Notes on individual files

Hints

Update 2011-12-31: to make a more hackable image, by removing the LZ77 compression, do this after booting up the USB key:
2880 nsec !
2880 ns !
80 nc !
0 block 0 80 writes
It might also be a good idea to redefine save to that last line, 0 block 0 80 writes, otherwise you'll have a compressed image again if you inadvertently type save. nsec above is the kernel-defined variable header I gave to 0 block 1 +. What the above does, of course, is to set the number of sectors and number of cylinders to the size of a floppy, 1.44 megabytes. The first time I did this I forgot to set nsec, and as a result only loaded the first 312 sectors on reboot, with predictably disastrous results. I also had a bad boot in there due to the problem mentioned on c.l.f. as possibly being due to an interrupt, where the boot process goes out to lunch before completing. Loading this larger image would be more susceptible to such a problem.

Update 2012-01-12: it turns out that the command above, 0 block 0 80 writes, can be abbreviated to 0 !work, with the added advantage that it also works under Windows or Wine (running from Okad2.exe), whereas Windows does not have the writes word defined.