Multicomp Cyclone II-C

The Multicomp Cyclone II-C (v1.10) is a motherboard which provides peripheral connectivity for a Cyclone II FPGA development board commonly available on eBay. The board was designed “by committee” in the retrobrewcomputers forum during December 2015, with James Moxham doing all the actual work (schematic capture and PCB layout). One of the prime motivators for this board was to fit a 10cmx10cm footprint because the manufacturing cost of PCBs of this size is particularly attractive. It provides connectivity for the following peripherals:

• VGA Screen with PS/2 Keyboard interface
• Two RS-232 serial ports:
  • Serial A uses on-board level-shifter and DE-9F connector or external level shifter via 6-pin connector
  • Serial B uses external level shifter via 6-pin connector
• SD Card connector
• Two RAM sockets to support up to 1 MB of RAM.
• 5-pin connector for external DS1302 real-time clock and backup coin cell
• 3V3 or 5V power option for PS/2 Keyboard, with voltage clamp diodes.
• 3 LEDs
• RCA Video connector
• Jumpers for reset and for boot control
• Debug/Expansion headers for data bus and uncommitted FPGA pins

Due to the header installation on the Cyclone II module, the module is required to be mounted inverted onto the motherboard.

The photo in this section shows a minimum build configuration using PS/2 keyboard and VGA output; no SDcard, no external RAM, and no serial ports.

The FPGA pin assignment for the V110 board is a superset of the pin assignment used in Grant's original design. Therefore, his original design files should work on this design with no modification. There are two caveats:

• To use Grant's design files, the three memory links must be set correctly (see Construction (Part 2))
• Grant's original SD controller only works with SD standard capacity cards (upto 5GBytes in size). The 6809 code presented here uses a modified design which supports both standard capacity and high-capacity (SDHC) cards.
• The CycloneIIc-Z80 (18 Aug 2016) project below currently only works with SD standard capacity cards. To enable use with SDHC cards, copy the sd_controller.vhd file from the mc-2g-1024.zip project and overwrite the existing file in \Components\SDCARD and recompile.

Notes:

1. Only if you want PS/2 keyboard and VGA output
2. Only if you want mono TV output
3. Only if you want a real-time clock
4. Only if you want RS232 to 9-way D
5. Off-cuts from resistor leads will do fine for this
6. These are the current-limiting resistors for the LEDs. The schematic shows a value of 5K6 but that seems a bit large/makes the LEDs too dim. Your mileage may vary. Draft v1.11 board specifies 1K.
7. Only if you are using I2C header.

Other connectors and components optional for adding external expansion connectors:

• 6-pin 0.1” connector for Serial B external level shifter
• 6-pin 0.1“ connector for Serial A external level shifter
• 4-pin 0.1” connector and 2x 10K resistor for external I2C
• 10-pin 0.1“ connector for GPIO connection
• 8-pin 0.1” connector for Data Bus connection

You will also need:

• Altera USB Blaster programming adaptor
• A computer with Altera's (free) Quartus software installed

Component sourcing:

• The FPGA board is available on http://www.ebay.com – search for ALTERA Cyclone II EP2C5T144 CPLD FPGA Development Board.
• The PCB files are freely available so you can choose a vendor, upload the files and have a batch made. Once a couple of people have done this, there should be boards available through the forum (since few people are likely to want all 10 boards from a minimum order). I got my boards from http://www.dirtypcbs.com and they turned out well. The design is “shared” there so that anyone can order the board without the need to upload design files (You can go directly to the design at this link: http://dirtypcbs.com/store/designer/browse/9663 or you can select “PCB Store” then use your browser's page search facility to locate “Cyclone2v110”. I recommend changing the board thickness from the default of 1.2mm to 1.6mm).
• I couldn't find 2 row x 14 contact 0.1“ headers, but I found some longer ones on ebay and cut them down with a hack-saw.
• The SDcard socket is for a full-size card. There are at least 2 variants with different footprints (I had to do some minor mechanical mods to get mine to fit)
• The VGA and PS/2 connectors ought to be source-able from an old PC motherboard. Otherwise, ebay.
• Ebay again for the RAMs. Be sure to get 0.6” DIL parts. The AS6C4008 is only slightly more expensive than the AS6C1008. The Z80 system can make use of extra memory (paged RAM disk) and that capability is in progress for the 6809 system.
• The SP3232 is made by Exar. The Maxim MAX3232 is an alternative. Apparently some of the MAX3232 parts on Ebay are fakes so you might want to use Farnell/CPC/RS or some other reputable source.
• If you have no RS232 connector on your host machine you can use a serial-to-USB adaptor. Once again, ebay. Be sure to get one that can run on 3.3V power. Search for USB to serial 3.3v
• The RTC module is available on.. ebay – search for Arduino DS1302 RTC
• Surface-mount SD card socket is Sparkfun part number PRT-12769

In all cases look at the photos here to check that the component you are choosing matches the footprint on the board.

There are various build options, as indicated in the notes of the parts list above. For now, these notes assume that you will use the PS/2 keyboard and VGA display connections. You can start by assembling the bare minimum system and go through the process of programming the FPGA board with a pre-built configuration and making sure that everything is working. Then you can go on to add the remaining components and reprogram the FPGA board. When you have assured yourself that everything is working correctly with the pre-built configurations you will have a proven stable base to go forward with either hardware or software experimentation.

For a minimum build, you need only fit:

• Decoupling capacitors (four 0.1uf and the two electrolytics). In the photo, the four 0.1uF caps for the RS232 level shifter are also fitted, but they don't need to be.
• The PS/2 connector
• The VGA connector
• The 6 VGA resistors
• The 2 PS/2 pullup resistors
• The 2 zener diodes (see “PS/2 keyboard power” below)
• The PS/2 power link (see “PS/2 keyboard power” below)
• The 5V flying lead (see “PS/2 keyboard power” below)
• The 4, 2×14 connectors for attaching the FPGA board

When fitting the 2×14 connectors, attach the FPGA board to them before soldering them into position; that will ensure that they are aligned correctly.

Have a copy of the schematic to hand while assembling the board. Because the board is so dense, some of the silk-screen references are a little hard to read. The schematic should help resolve any ambiguity.

With the minimum build completed, program the FPGA using one of the pre-built minimum configurations below.

Grant's original design used 3.3V power for the PS/2 keyboard. Not all PS/2 keyboards will run at this voltage so the board provides the option of supplying either 3.3V or 5V power to the keyboard, using a wire jumper just behind the PS/2 connector.

Solder a wire jumper from the middle connection to either the 5V or the 3V connection.

The two zener diodes prevent 5V from the keyboard from over-driving the FPGA inputs. They are optional but are strongly recommended if you configure the board for 5V keyboard. With a 3V keyboard they are not needed (you can still fit them if you want; they will do no harm).

With a 5V keyboard, you also need to route 5V to the board from the FPGA board, where it is tapped off directly from the input power socket. The easiest way to do this is with a short flying lead from one of the four marked 5V pads close to the VGA connector. On the FPGA board there is a 2-pin 0.1“ connector/footprint in the corner, next to the input power socket. Use a meter to buzz out and see which pin is 5V (the other is 0V).

Theoretically, you can connect a USB keyboard using a passive USB-to-PS/2 adaptor. If anyone has done that successfully, please add a note here.

The Cyclone II FPGA is configured through internal RAM cells, and therefore its configuration is not maintained across a power cycle. The appearance of non-volatile operation is achieved by programming the configuration into a EEPROM (which is also on the FPGA breakout board) which is automatically loaded by the FPGA at power-up.

The FPGA breakout board has 2 separate 10-pin programming sockets. One is marked JTAG and is used for programming the FPGA directly (configuration endures until a power cycle). The other is marked AS (the “Active Serial” programming port) and is used for programming the EEPROM. Each connector is keyed, and the keying is rotated 180degress from one connector to the other. Programming through the JTAG port requires a .sof file. Programming through the AS port requires a .pof file. Usually, the run through Quartus will create both .sof and .pof files.

Pre-built images are available for some configurations; you can use them “as-is” or as a starting point for your own modifications. See the Downloads section below.

The USB-Blaster works fine under Linux. The user guide tells you to create the file /etc/udev/rules.d/51-usbblaster.rules and containing the text (on a single line):

BUS=="usb", SYSFS{idVendor}=="09fb", SYSFS{idProduct}=="6001",MODE="0666", PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf /proc/bus/usb/%%0
3i/%%03i $${K%%%%.*} $${K#*.}'", RUN+="/bin/chmod 0666 %c"

I found that, on my Kubuntu system, that line did not work and I used this instead:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="09fb", ATTRS{idProduct}=="6001",MODE:="0666"

Both incantations are attempting to do the same thing: to change the protection on the USB Blaster automatically when it is plugged in.

You can program the FPGA breakout board when it is still connected to the V110 PCB. You do not need to supply power whilst programming: the programming cable provides the necessary power.

Programing is very quick; it takes about 4s.

describe in detail from within Quartus

It goes without saying (I hope..) that if you have configured the FPGA breakout board for a 6809 processor design, you can only use 6809 software. However, for the initial bring-up, everything you need is in ROM.

The description here assumes that you have built a minimal system and programmed it with the minimal 6809 image, and that the programming completed successfully.

Connect the FPGA breakout board to the V110 PCB, and connect the 5V flying lead (if applicable). Connect the PS/2 keyboard and VGA monitor. Power-up the monitor. Connect power to the FPGA breakout board and power-up.

You should be greeted with a message in white 40-column text on the VDU:

6809 CamelForth v1.0  25 Apr 95

If not, and assuming nothing went bang investigate a little more:

• The keyboard caps-lock LED should be illuminated. It should toggle when you press the caps-lock key repeatedly. This is implemented in hardware and has nothing to do with processor choice or code ROM.
• The monitor should show a small flashing cursor - either after the message, or (if there's no message) in the top left-hand corner.

Here are some debug suggestions:

Once the keyboard and VDU are working as expected, try pressing a few keys; they should be echoed on the screen. The processor is running a FORTH intepreter/compiler. I think that FORTH makes a great debug monitor. If you don't know any FORTH I suggest you spend a few minutes reading the introduction and tutorial to Gforth.

A couple of things to note about CamelForth:

• It is case sensitive, so keep caps-lock on.
• There is (currently) no (easy) way to save any code, so don't write anything too big.

The final piece of testing on the minimal system is to see the colour output on the VDU. Type in this program. Be careful with case (everything is in upper case except the m near the end) and with spaces:

: DIG DUP 10 / 48 + EMIT 10 MOD 48 + EMIT ;
: GR 27 EMIT ." [" DIG ." ;" DIG ." m" ;

Now try this:

44 31 GR
42 93 GR
0 30 GR
0 41 GR
0 0 GR
31 40 GR
32 40 GR
34 40 GR
47 34 GR
45 94 GR
1 34 GR
0 0 GR
1 37 GR
: GREET ." HELLO WORLD " ;
32 40 GR GREET 44 31 GR GREET

You should see coloured output on the display. Notice the two levels of intensity (visible in the white). If your output looks different, check that R10-R15 are fitted and the correct values.

Consult Grant's site for a complete list of the ANSI escape codes supported by his VDU design.

You can leave the board like this, if you want, and explore CamelForth further. Alternatively, continue with the construction; in particular, fitting an external memory.

Once you have some signs of life from the board, you can go ahead with the remainder of the construction. Fit:

• The RAM and RAM address links (notes below)
• The on-board RS232 (connector, caps and
• An external RS232/USB adaptor
• The three LEDs and their current-limiting resistors
• The SDcard socket. The footprint for this component is not standard so you might need to improvise a little.
• The Real-time clock module. Check the pin connections on the schematic; it should wire 1-to-1 from the module down to the PCB. You can mount it on top of the RAM chip with a double-sided sticky foam pad.
• 2-pin jumpers for RESET and VDUFFD0
• Any other connectors you want to use either for debug or expansion

You can fit one or two RAM devices. If you only fit 1, it should be the device closest to the SDcard socket – three, 2-way links control the high-order addresses on that device.

To use Grant's original design (which does not drive the high-order address lines) wire all three links pin1-pin2. Otherwise, wire all three links pin2-pin3 (marked “512K” on the PCB silk-screen).

The latest Z80 and 6809 designs can access more than 64Kbytes of memory through a simple memory-mapping unit.

Use the same FPGA configuration (internal RAM) to complete the testing. Connect and power-up the board as before. It should boot as before and display the CamelForth message.

Test the reset. There is a reset button on the FPGA breakout board; once you get used to where it is, you can reach around and press it even though you can't see it! Alternatively, you can fit a switch or a jumper to the “RST” pins near the LEDs. Note that the VDU logic is not reset by reset and so the screen is not cleared by reset; the processor is reset and so code execution restarts (so you will see the CamelForth message after each reset). If you use a jumper or paper-clip to short the “RST” pins you will probably see a very bouncy reset; multiple resets in quick succession.

Test the VDUFFD0 jumper. When fitted, it swaps the hardware decode of the VDU/keyboard and the SerialA port. Fit the jumper and press reset. There should be no output to the VDU. Pressing the Caps-Lock key should continue to toggle the Caps-Lock LED.

Test the Serial A RS232 port. Use a “straight” male-to-female cable (wire 2-2, 3-3, 5-5 as a minimum) to connect to a VT100.. or a terminal emulator. Configure the terminal for 115200baud, 8 data bits, 1 stop bit, no flow control. Press reset with the VDUFFD0 jumper fitted; the CamelForth message should be displayed on the monitor, and you should be able to interact with CamelForth using the terminal.

Test the external memory. CamelForth uses RAM internal to the FPGA, in the address range 0x0000-0x07FF. The ROM and I/O occupy address range 0xD000-0xFFFF. All the rest of the memory space is RAM.

Run a single pass memory test like this:

HEX
1000 1FFF PASS

Or 16 (0x10) passes like this:

HEX
1000 1FFF 10 PASSES

If this works OK, test the whole memory:

HEX
0800 CFFF 10 PASSES

Here are the definitions for the memory test routines (you don't need to type these in; they are already in ROM):

\ simple memory test
: STUP  \ start-addr end-addr -- start-addr end-addr
  2DUP SWAP DO I DUP      ! CELL +LOOP ;
: STUPI \ start-addr end-addr -- start-addr end-addr
  2DUP SWAP DO I NEGATE I ! CELL +LOOP ;

: TSTUP  \ start-addr end-addr -- start-addr end-addr
  2DUP SWAP DO I DUP @      <> IF
  ."  Error@" I U. THEN CELL +LOOP ;
: TSTUPI \ start-addr end-addr -- start-addr end-addr
  2DUP SWAP DO I NEGATE I @ <> IF
  ."  Error@" I U. THEN CELL +LOOP ;

: PASS STUP TSTUP STUPI TSTUPI ; ( do 1 pass)
: PASSES 0 DO ." ." PASS LOOP ;  ( do N passes)

If the memory test fails, try reading and writing a small group of locations and try to infer what's wrong:

HEX                ( THIS IS A COMMENT - NO NEED TO TYPE IT)
1000 20 AB FILL    ( FILL FROM 1000 FOR 20 BYTES WITH VALUE AB)
1000 30 DUMP       ( DISPLAY MEMORY FROM 1000 FOR 30 BYTES)

( REPEAT THE FILL/DUMP LINES BUT REPLACE "AB" WITH THESE NUMBERS IN TURN: 0 1 2 4 8 10 20 40 80 55 AA FF)

This should allow you to see if there are any data bus problems (shorts/opens). To look for addressing problems try this:

HEX                ( THIS IS A COMMENT - NO NEED TO TYPE IT)
1000 2000 STUP     ( FILL FROM 1000 TO 2000 WITH AN INCREMENTING PATTERN )
1000 30 DUMP       ( DISPLAY MEMORY FROM 1000 FOR 30 BYTES)

( LOOK FOR DUPLICATE VALUES IN THE DUMP. REPEAT THE DUMP, CHANGING THE RANGE. TRY USING STUPI TO FILL IN THE OPPOSITE DIRECTION)

If the RAM appears to fail catastrophically, try removing it and see if you get the same behaviour. If you do, what you're seeing is just capacitance. Either the RAM is faulty or, more likely, you have set the jumpers wrongly (Ahem, I did exactly that and it took me ages to realise my mistake).

To save you trying it, I can assure you that fitting the RAM the wrong way around is a _bad_ thing to do; the board will not power up (in my case, my carelessness was not punished; the board and RAM worked correctly when I turned it around.

The most likely RAM problems are a short or open or a bent pin or bad jumpers. If you get stuck, go to to the forum and ask for help.

If you have a RAM problem, you might suspect a faulty PCB. Although this is possible, it's very unlikely. At least five batches of these boards have been manufactured, by multiple companies, with no apparent problems and the boards themselves are individually electrically tested.

Test the “Drive” LED. With no SDcard fitted, type this:

FLEX

LED1 should light and stay on (LED1 is the LED closest to the “RST” jumper). You need to press the reset button to recover (LED1 should go off).

Test the SDcard controller. Power-off the board and fit an SDcard (one that you don't mind corrupting). There is no card-detect mechanism so you always need to power-cycle to change the card. Type this:

HEX
200 80 DUMP
0 200 SDRD
200 80 DUMP

The 2nd line inspects the current contents of memory from 0x200-0x27F. The 3rd line loads block 0 (512 bytes in size) from the SDcard to RAM at address 0x200. The 4th line shows the final contents of memory. Assuming the SDcard is not filled with 0, you will see the memory contents change between the first and the second DUMP.

If the system hangs when you press return after the SDRD, the SDcard is not recognised or there is a connection problem.

Once everything is working, you can reprogram the FPGA with the full image - this uses the external RAM, which frees up internal RAM on the FPGA so that the VDU can be configured for 80-column operation.

For the 6809 system, the SDcard does not contain anything that would generally be recognised as a partition table or filesystem. Rather, it is a concatenated set of binaries and floppy disk images. To prepare the SDcard you need a tool like dd (for Linux or Mac OS). For Windows, there is a program on sourceforge called “Win32 Disk Imager” that claims to perform the equivalent task. I haven't tried it. Please update this if you have, or if you can recommend a suitable tool.

Download multicomp09_sd.img (see Downloads below) to your host computer and plug in the SDcard. Do not mount the SDcard. Use “tail /var/log/syslog” to identify the device associated with the SDcard

The device will be something like sdb (it may be reported as “sdb sdb1”). Copy the file to the device like this (change the device as appropriate)

sudo dd if=multicomp09_sd.img of=/dev/sdb

When the copy completes, remove the SDcard (it has no filesystem so you cannot “unmount” it.

Power off the V110 and insert the SDcard. When you power on it should boot to CamelForth as usual. The table below lists the commands used to start the different software environments that are on the SDcard image:

Although there is a “canned” software download here, the latest versions and all the component parts/source code and other notes are in the multicomp6809 repository on github. There is additional documentation on the associated wiki.

Regardless of how much memory you have fitted, the ROMed FORTH uses RAM in the address range 0x0000-0x03FF for its workspace. Definitions that you create go into RAM from address 0x0000 upwards. There are some variables stored at the top of the RAM then a region assigned for the return stack and another region assigned for the data (parameter) stack.

Here's a simple example that allows you to see how definitions are stored in memory. Reset the system and enter these commands:

: GREET ." Hello World" ;
: HI CR GREET ;
HEX 0 80 DUMP

The dump shows how the two definitions are laid out in memory. You can see the complete list of definitions built in to CamelForth by typing WORDS:

6809 CamelForth v1.0  25 Apr 95
WORDS UINIT #INIT NITROS9 FLEX BUGGY BASIC CUBIX CDTOCD EFTOCD MMUMAP PIVOTRST P
IVOT piv SDRD256n SDRD256 SDRDn SDWR SDRD SDIDLE SDLBA10 SDLBA2 PASSES PASS TSTU
PI TSTUP STUPI STUP DUMP .A .B H. .HHHH .HH .H COLD .S WORDS ENVIRONMENT? DEPTH
MOVE WITHIN POSTPONE ['] IMMEDIATE REVEAL HIDE ] [ RECURSE CREATE \ ( [CHAR] CHA
R ' ABORT" ?ABORT ABORT QUIT EVALUATE INTERPRET ?NUMBER>NUMBER ?SIGN DIGIT? LIT
ERAL FIND IMMED? NFA>CFA NFA>LFA WORD>COUNTED /STRING SOURCE C, , ALLOT HERE HE
X DECIMAL . U. SIGN #> #S #>DIGIT <# HOLD UD* UD/MOD ." S" (S") TYPE ACCEPT UMA
X UMIN SPACES SPACE CR COUNT 2OVER 2SWAP 2DUP 2DROP 2! 2@ MIN MAX */ */MOD MOD /
 /MOD * FM/MOD SM/REM M* DABS ?DNEGATE DNEGATE ABS ?NEGATE S>D R0 L0 PAD S0 LP H
P LATEST 'SOURCE DP STATE BASE>IN U0 TIB TIBSIZE BL CELL +LOOP LOOP ENDLOOP LEA
VE DO L>>L REPEAT WHILE AGAIN UNTIL BEGIN ELSE THEN IF USER VARIABLE CONSTANT ;
 : DOES> (DOES>) !DEST ,DEST ,BRANCH ,EXIT !COLON ,CF !CF COMPILE,>BODY CHARS C
HAR+ CELLS CELL+ ALIGN ALIGNED SCAN SKIP CMOVE> CMOVE S= FILL UM/MOD UM* J I (+L
OOP) (LOOP) UNLOOP (DO) ?BRANCH BRANCH U> U<> <<> = 0<0= RSHIFT LSHIFT +! 2/
2* 1- 1+><INVERT XOR OR AND NEGATE - M+ + C@ @ C! ! RP! RP@ SP! SP@ R@ R>>R P
ICK TUCK NIP ROT OVER SWAP DROP ?DUP DUP EXECUTE LIT EXIT EMIT KEY? KEY
OK

(that output was wrapped at 80 columns, the width of my terminal, and may not be the latest version)

As of the June 2016 release, CamelForth includes support for block words, for loading/storing binary blobs and has (stored as part of the SDcard image) a screen-based block editor. Here is a quick getting-started guide.

The file storage uses a traditional “block” format. Each block is 1Kbyte is size and a block can hold anything you choose: txt, source code, data or binary data. There is no management of what is stored where; that is the programmer's responsibility.

The default block file contains 256 blocks (and is therefore 256KByte in size), with source code stored in the low-order block numbers. Blocks are numbered from 0 (but, you cannot load code from block 0 for various arcane historic reasons, so block zero is just use for comments)

0 LIST           ( DISPLAY BLOCK 0)
1 LIST           ( DISPLAY BLOCK 1)
1 LOAD           ( LOAD BLOCK 1.. WHICH IN TURN LOADS SOME OTHER BLOCKS)

Once the load has completed (which takes about 10s) some new capabilities are available:

WORDS            ( WORDS NOW COLOUR-CODES THE WORDS, AND HAS A BUILT-IN PAGER - PRESS SPACE FOR THE NEXT SET)

16 LIST          ( DISPLAY THE COMMANDS FOR THE SCREEN EDITOR)
1 EDIT           ( START THE SCREEN EDITOR)
                 ( ctrl-N FOR NEXT SCREEN, ctrl-P FOR PREVIOUS SCREEN)
                 ( ctrl-E TO EXIT.. LOOK AT BLOCK 16 FOR THE COMPLETE LIST)

Also, when the code was compiled it was stored back to a region of the block file in compiled form (in a format that I call a “blob”). After a reset or power-cycle you can load it back in like this:

HEX 800 ALLOT 64 RDBLOB

For more details read follow these two links:

CamelForth CamelForth save/load

For the 6809 system, the SDcard does not contain anything that would generally be recognised as a partition table or filesystem. Rather, it is a concatenated set of binaries and floppy disk images. To prepare the SDcard you need a tool like dd (for Linux or Mac OS). For Windows, there is a program on sourceforge called “Win32 Disk Imager” that claims to perform the equivalent task. I haven't tried it. Please update this if you have, or if you can recommend a suitable tool.

Download multicomp09_sd.img (see Downloads below) to your host computer and plug in the SDcard. Do not mount the SDcard. Use “tail /var/log/syslog” to identify the device associated with the SDcard

The device will be something like sdb (it may be reported as “sdb sdb1”). Copy the file to the device like this (change the device as appropriate)

sudo dd if=multicomp09_sd.img of=/dev/sdb

When the copy completes, remove the SDcard (it has no filesystem so you cannot “unmount” it.

Power off the V110 and insert the SDcard. When you power on it should boot to CamelForth as usual. The table below lists the commands used to start the different software environments that are on the SDcard image:

Although there is a “canned” software download here, the latest versions and all the component parts/source code and other notes are in the multicomp6809 repository on github. There is additional documentation on the associated wiki.

Regardless of how much memory you have fitted, the ROMed FORTH uses RAM in the address range 0x0000-0x03FF for its workspace. Definitions that you create go into RAM from address 0x0000 upwards. There are some variables stored at the top of the RAM then a region assigned for the return stack and another region assigned for the data (parameter) stack.

Here's a simple example that allows you to see how definitions are stored in memory. Reset the system and enter these commands:

: GREET ." Hello World" ;
: HI CR GREET ;
HEX 0 80 DUMP

The dump shows how the two definitions are laid out in memory. You can see the complete list of definitions built in to CamelForth by typing WORDS:

6809 CamelForth v1.0  25 Apr 95
WORDS UINIT #INIT NITROS9 FLEX BUGGY BASIC CUBIX CDTOCD EFTOCD MMUMAP PIVOTRST P
IVOT piv SDRD256n SDRD256 SDRDn SDWR SDRD SDIDLE SDLBA10 SDLBA2 PASSES PASS TSTU
PI TSTUP STUPI STUP DUMP .A .B H. .HHHH .HH .H COLD .S WORDS ENVIRONMENT? DEPTH
MOVE WITHIN POSTPONE ['] IMMEDIATE REVEAL HIDE ] [ RECURSE CREATE  ( [CHAR] CHA
R ' ABORT" ?ABORT ABORT QUIT EVALUATE INTERPRET ?NUMBER>NUMBER ?SIGN DIGIT? LIT
ERAL FIND IMMED? NFA>CFA NFA>LFA WORD>COUNTED /STRING SOURCE C, , ALLOT HERE HE
X DECIMAL . U. SIGN #> #S #>DIGIT <# HOLD UD* UD/MOD ." S" (S") TYPE ACCEPT UMA
X UMIN SPACES SPACE CR COUNT 2OVER 2SWAP 2DUP 2DROP 2! 2@ MIN MAX */ */MOD MOD /
 /MOD * FM/MOD SM/REM M* DABS ?DNEGATE DNEGATE ABS ?NEGATE S>D R0 L0 PAD S0 LP H
P LATEST 'SOURCE DP STATE BASE>IN U0 TIB TIBSIZE BL CELL  LOOP LOOP ENDLOOP LEA
VE DO L>>L REPEAT WHILE AGAIN UNTIL BEGIN ELSE THEN IF USER VARIABLE CONSTANT ;
 : DOES> (DOES>) !DEST ,DEST ,BRANCH ,EXIT !COLON ,CF !CF COMPILE,>BODY CHARS C
HAR  CELLS CELL  ALIGN ALIGNED SCAN SKIP CMOVE> CMOVE S= FILL UM/MOD UM* J I ( L
OOP) (LOOP) UNLOOP (DO) ?BRANCH BRANCH U> U<> <<> = 0<0= RSHIFT LSHIFT  ! 2/
2* 1- 1><INVERT XOR OR AND NEGATE - M    C@ @ C! ! RP! RP@ SP! SP@ R@ R>>R P
ICK TUCK NIP ROT OVER SWAP DROP ?DUP DUP EXECUTE LIT EXIT EMIT KEY? KEY
OK

(that output was wrapped at 80 columns, the width of my terminal, and may not be the latest version)

As of the June 2016 release, CamelForth includes support for block words, for loading/storing binary blobs and has (stored as part of the SDcard image) a screen-based block editor. Here is a quick getting-started guide.

The file storage uses a traditional “block” format. Each block is 1Kbyte is size and a block can hold anything you choose: txt, source code, data or binary data. There is no management of what is stored where; that is the programmer's responsibility.

The default block file contains 256 blocks (and is therefore 256KByte in size), with source code stored in the low-order block numbers. Blocks are numbered from 0 (but, you cannot load code from block 0 for various arcane historic reasons, so block zero is just use for comments)

0 LIST           ( DISPLAY BLOCK 0)
1 LIST           ( DISPLAY BLOCK 1)
1 LOAD           ( LOAD BLOCK 1.. WHICH IN TURN LOADS SOME OTHER BLOCKS)

Once the load has completed (which takes about 10s) some new capabilities are available:

WORDS            ( WORDS NOW COLOUR-CODES THE WORDS, AND HAS A BUILT-IN PAGER - PRESS SPACE FOR THE NEXT SET)

16 LIST          ( DISPLAY THE COMMANDS FOR THE SCREEN EDITOR)
1 EDIT           ( START THE SCREEN EDITOR)
                 ( ctrl-N FOR NEXT SCREEN, ctrl-P FOR PREVIOUS SCREEN)
                 ( ctrl-E TO EXIT.. LOOK AT BLOCK 16 FOR THE COMPLETE LIST)

Also, when the code was compiled it was stored back to a region of the block file in compiled form (in a format that I call a “blob”). After a reset or power-cycle you can load it back in like this:

HEX 800 ALLOT 64 RDBLOB

For more details read follow these two links:

CamelForth CamelForth save/load

  ===== Downloads =====

In general, the pre-build FPGA bundles in the downloads section do not contain everything that you need to rebuild the project in Quartus. The directory structure looks like this:

project1/
project2/
project3/
ROMS/
Components/

Where the ROMS and Components directories are common to all of the projects. The FPGA bundle will contain the files for (eg) “project1” but only a skeleton/subset of the files needed for the “ROMS” and “Components” directories.

If you want a complete tree, start by downloading the zip from Grant's site and then overlaying it with files either from the Z80 design or from the 6809 design (because the Z80 and 6809 designs have each modified some of Grant's original files, you are advised to keep independent trees of files if you are working with both)

The additional/latest 6809 files can be downloaded from github.