ANS Forth for the Rabbit 2000 or 3000

The source is written in ANS forth using gForth ( http://www.gnu.org/software/gforth/ ) 
for a cross compiler (some call it meta compiling) that targets the Rabbit.

The gForth cross compiler writes the binary image to a file.

I have this directory structure:
C:\forth\gforth\gforth (the gforth-0.5.0-win32.exe installation)
C:\forth\gforth\gforth-gdfreeze-ec (Jens Wilke's embedded control fork of gforth-0.5.0)
add C:\forth\gforth\gforth to your PATH variable
CD into C:\forth\gforth\gforth-gdfreeze-ec and invoke forth:

  C:\Forth\gForth\gforth-gdfreeze-ec> gforth -m 1000000 makegfr2k.fs
    redefined assembler with Assembler
    Include assembler
    Include primitives
    inline next Prepare booting

    Unresolved: Nothing!
    Saving to gfR2K.bin
    GForth 0.5.0, Copyright (C) 1995-2000 Free Software Foundation, Inc.
    GForth comes with ABSOLUTELY NO WARRANTY; for details type `license'
    Type `bye' to exit
    bye

then copy gfr2k.bin (the binary image) just created into C:\DCRABBIT_8.61

 

The serial port is specified in prim.fs via the constant SERIAL. This must match the serial port specified in LOADER_FS_GF_rev.C

 

With Rabbit connected using Dynamic C: Compile - Compile to Target - Compile to Flash

To generate RFU image: Compile - Compile to .bin File - Compile to Flash

 

This binary image is loaded with the Dynamic-C loader that provides flash support via the Dynamic-C bios. Here's how this works: when you compile the Dynamic-C loader program to flash, the compiler directive #ximport reads the gfr2k.bin image and writes it to xmem in flash.

 

When this program is run, it allocates a chunk of RAM and copies the gforth image from
flash to RAM, then changes the memory mapping so that the first byte of the gforth image is at 0x0000, and finally jumps to 0x0000.

 

This is similar to my eForth implementation, but uses the flash file system
to save the current Forth image (via the 'flash' word) or to restore the original Forth image (via the 'restore' word). This feature depends on FS2 in the first flash, which depends on small sector flash devices. I plan to shift to serial EEPROM if the FS2 implementation ever breaks.

 

The original implementation was done with Dynamic-C version 7.20. The block of assembly code that remapped the gForth binary image in RAM to address 0x0000 accessed three C variables. In Dynamic-C versions before 8.0, the default variable class was static.

 

Starting with version 8.0, the default variable class is auto. These three variables are explicitly declared as static. This change is first implemented in Dynamic-C source files that have a version suffix on the file name ( e.g. LOADER_FS_GF_001.C ).

If you are working with the Dynamic-C sources and testing new file system features,
it is useful to be able to completely erase the flash memory. 

 

I've switched to Dynamic-C 8.61 for USB-serial support. I run Dynamic-C in a WindowsXP virtual machine on my Mac.

 

Here's a Dynamic-C program to erase flash , or the flash erase binary (to load with RFU).
This doesn't always work because the program is running in flash!

 

All we really need is to delete the Forth image in the file system so that the image that is programmed with the loader (in xmem) gets re-loaded into the file system. Directly formatting the file system works (and is probably better than erasing all of the flash anyway).

 

Here's a Dynamic-C program to format the file system and the binary to load with RFU.

 

Here is a minimal gForth implementation that doesn't use FS2.

BUG FIX: If you are using FS2 with Dynamic-C 7.21 (and probably earlier versions):
Edit /LIB/FILESYSTEM/FS_DEV.LIB
// FAILS when FS2_USE_PROGRAM_FLASH >= 64 !! 
OLD: request = FS2_USE_PROGRAM_FLASH << 10 & mask;
NEW: request = FS2_USE_PROGRAM_FLASH << 10L & mask;

gForth Binary (to load with RFU)
R2K gForth source (to cross compile with gForth).
You can use gForth 0.5.0 or 0.6.2 (choose an appropriate platform and version),
but you must use the version of cross.fs and the rest of the sources from
Jens Wilke's EC fork of gForth 0.5.0. There is an empty directory in this zip ./arch/R2K
which is where you should unzip the separate R2K gForth source.

 

Debugging a new Forth port.

Extensions and Suggestions.

Example Programs

Files

 

| © 2005 Ken Staton