Mark 1 FORTH Computer

I bought my first TTL data book in 1979. I was learning 6502 machine code at the time and dreamt of building a simple TTL CPU. I sketched some circuit ideas; but that was as far as it went. Now, 25 years later, I've finally done it! Working evenings and weekends, the Mark 1 took a month to design, 4 months to build and a month to program. Here's the result:

Myself is a standard way to implement recursion in FORTH. Even if you're not familiar with FORTH, if I tell you it's a stack-based language, and uses reverse polish notation (RPN), you might be able to figure out how this works.

Specification

System Overview

µ-Instruction Format

The Mark 1 is a micro-programmed machine with a highly encoded "vertical" microcode. The microinstruction (µ) is only 8-bits wide. One normally thinks in terms of "horizontal" microcodes, which are wider and less encoded. Some are very wide indeed. The Mark 1 is more like a RISC processor.

The 8-bit µ-instruction (µ) is encoded as follows:

The source and destination fields of the move instructions are coded as follows:

The Mark 1 executes 1 µ-instruction per clock cycle (1MHz).

Decoding is done centrally using 74HC138 1-of-8 decoders. Decoded control signals are distributed via the back plane. Simple gating is then required at card level to complete the decoding.

The conditional is a skip not a branch. It inhibits loading of another µ-instruction for a specified number of cycles if the test is true. The skip distance is decremented to zero at which point normal execution resumes.

The "µPC←OP*16" instruction (1011xxxx) a.k.a. XOP loads the uppermost 8-bits of the program counter (µPC) from the operand register. It's a form of indirect jump.

The other jump instruction (1001xxxx) has a 4-bit operand and can only reach the first 16 bytes of the µ-ROM.

The 74181-based ALU requires 8 control signals. These are decoded from the 4-bit ALU function field in the µ-instruction using a 7x16 diode matrix ROM. The shaded squares indicate positions where diodes are fitted:

The control signals are transmitted from the diode matrix to the ALU via the data bus.

M is hard-wired to µ3.

D6 and D7 control the carry input as follows:

FLAG selects sign or overflow testing. Sign testing routes the most significant bit of the ALU result to the conditional test multiplexer. Overflow testing required the addition of a quad-XOR gate. The 74181 does not generate an overflow signal (the later 382 variant does). This was not used in the end because FORTH implements signed comparison by testing the sign of the result after subtraction.

Backplane

The Mark 1 is housed in a 3U 19" IEC297 sub-rack with a 64-way DIN 41612 backplane. The bus layout is shown below. The "A" row resembles a standard 8-bit microprocessor bus. The "C" row carries the µ-instruction and various decoded control signals. The fully-bussed pins (1, 2, 31, & 32) carry power supply and clocks.

The clocks are in quadrature. CLK1 risesfalls at the beginning of the machine cycle. CLK2 is used to generate write-enable signals for the RAM and I/O.

All control signals are active low.

Microcode sequencer

The sequencer has a 12-bit micro-program counter (µPC). The uppermost 8-bits can be loaded from the OP Latch, effecting a jump to one of 256 microcode routines. Each routine starts on a 16-byte µ-page boundary.

Opcodes, the machine language of the macro-machine, are loaded into the OP latch from the data bus under micro-program control. They can be fetched from memory using one of the index registers as a program counter. A simple micro-interpreter consists of the following 3 µ-instructions:

OP←Memory[Index]     Load OP latch from memory
Index←Index+1        Increment "program counter"
µPC←OP*16            Execute microcode routine

How do these 3 µ-instructions get executed? One possibility is to append them to the end of every µ-routine. A slower but more space-efficient option is to append a jump to them. Mark 1 microcode has a jump specifically for this.

Virtual machine

It's possible to customise the the instruction set and thereby create a "virtual machine".

Opcodes can have zero, one, or more operands. The µ-routines consume operands by incrementing the program counter. During development, I used this two-operand POKE instruction to test the UART. This expects a 16-bit address followed by a data byte:

Poke:    Index.Lo ← Memory [PC]        ; Address LO
         PC ← PC+1
         Index.Hi ← Memory [PC]        ; Address HI
         PC ← PC+1
         Temp ← Memory [PC]            ; Data byte
         PC ← PC+1
         Memory [Index] ← Temp         ; Do the POKE
         Jump Next

The Mark 1 was designed to support the FORTH virtual machine. The following FORTH primitives are micro-programmed:

Forth model

My original plan was to build a subroutine-threaded FORTH. High-level definitions were to be called explicitly, primitives were to be compiled inline:

I abandoned this idea because most FORTHs use indirect threading and I wanted a full-featured standard FORTH with all the usual compiler facilities. Many compiling words are tightly coupled to the indirectly threaded model.

Indirectly threaded code is a list of execution tokens. An execution token is a code field address. The code field is a pointer to machine code. This presented a problem on the mark 1 because it has separate macro and micro address spaces. What should go in the code field? My solution was to shorten it to 1 byte and store the opcode:

 Foo:       DB OP_DUP
            DB OP_SWAP
            DB OP_DROP
            DB OP_EXIT

 Bar:       DB OP_OVER
            DB OP_CALL
            DW Foo
            DB OP_ROT
            DB OP_EXIT
	

 cfa_Foo:   DW Enter
 pfa_Foo:   DW cfa_DUP
            DW cfa_SWAP
            DW cfa_DROP
            DW cfa_Exit

 cfa_Bar:   DW Enter
 pfa_Bar:   DW cfa_OVER
            DW cfa_Foo
            DW cfa_ROT
            DW cfa_Exit

 cfa_Exit:  DW pfa_Exit
 pfa_Exit:  .. code ..

 cfa_DUP:   DW pfa_DUP
 pfa_DUP:   .. code ..
    

 cfa_Foo:   DB OP_ENTER
 pfa_Foo:   DW cfa_DUP
            DW cfa_SWAP
            DW cfa_DROP
            DW cfa_Exit

 cfa_Bar:   DB OP_ENTER
 pfa_Bar:   DW cfa_OVER
            DW cfa_Foo
            DW cfa_ROT
            DW cfa_Exit

 cfa_Exit:  DB OP_EXIT
 cfa_DUP:   DB OP_DUP
 cfa_SWAP:  DB OP_SWAP
    

In Mark 1 assembly language, the FORTH inner interpreter (NEXT) looks like this:

NEXT:        mov w.l, [ip]       ; W ← XT, IP ← IP+2
             inc ip
             mov w.h, [ip]
             inc ip

             mov op, [w]         ; OP ← [CFA]
             inc w               ; W ← PFA
             xop                 ; µPC ← OP*16

It follows the convention of invoking primitives with the PFA in W as required by ENTER:

ENTER:       dec rsp             ; Push IP
             mov rs, ip
             mov ip, w           ; IP ← PFA
             jmp NEXT

EXIT:        mov ip, rs          ; Pop IP
             inc rsp
             jmp NEXT

Note: My microcode assembler expands 16-bit moves into a pair of 8-bit µ-instructions.

Notice how the last 3 µ-instructions in NEXT resemble the simple micro-interpreter described earlier. This was used to advantage in the implementation of multiplication and division.

Math primitives

The math primitives U* and U/ were split into 3 opcodes to optimise performance:

cfa_UMUL:    DB OP_MUL_BEGIN, 16 DUP(OP_MUL_BIT), OP_MUL_END
cfa_UDIV:    DB OP_DIV_BEGIN, 16 DUP(OP_DIV_BIT), OP_DIV_END

I use the Microsoft Assembler (MASM) to create ROM images for the macro memory space. The syntax "16 DUP()" tells MASM to repeat the enclosed byte 16 times. It's equivalent to:

cfa_Uxxx:    DB OP_XXX_BEGIN
pfa_Uxxx:    DB OP_XXX_BIT, OP_XXX_BIT, OP_XXX_BIT, OP_XXX_BIT
             DB OP_XXX_BIT, OP_XXX_BIT, OP_XXX_BIT, OP_XXX_BIT
             DB OP_XXX_BIT, OP_XXX_BIT, OP_XXX_BIT, OP_XXX_BIT
             DB OP_XXX_BIT, OP_XXX_BIT, OP_XXX_BIT, OP_XXX_BIT
             DB OP_XXX_END

First, NEXT calls _BEGIN with the address of the PFA (i.e. the first _BIT) in W. _BEGIN and _BIT end by jumping to the 3^rd from last instruction in NEXT. This executes _BIT 16 times incrementing W as it goes. W acts as the loop counter or temporary program counter. Finally, _END jumps to the high-level NEXT.

Power-on reset

Reset forces µPC to 000H. The first 8 bytes of the µ-ROM contain the following:

RESET:       mov w, 0            ; W ← 0002h
             inc w
             inc w

             dis                 ; Disable IRQ

             mov ip.l, [w]       ; IP ← Cold start vector
             inc w
             mov ip.h, [w]

Next:        ...

This initialises the high-level instruction pointer (IP) from a cold start vector at location 0002h in main memory. It then drops through into NEXT.

The high-level ROM assembly begins like this:

.Model Tiny
.Code
             Include OPS.INC
             ORG 0

             DW 0FFFFh           ; Reserved for IRQ vector
             DW Reset            ; Cold-start vector

Reset        DW UART_Init
             ...

Offset 0000h is reserved for the interrupt vector.

Software development

Burning EPROMs soon became tedious and I wrote a ROM-resident monitor to accept Intel Hex downloads via the serial port. This is how FORTH was originally loaded; but the latest version is ROM-resident. I now have a PC-based simulator for debugging, FORTH is fairly stable, and there's less need for the monitor.

My original FORTH, posted here in 2003, reversed the stack order of quotients and remainders left by division words. This has been corrected. Here's the latest code:

This implementation of fig-FORTH is based on the original May 1979 Installation Manual for the 6502 by Bill Ragsdale. It deviates from the standard in the following ways:

• ANSI names for header navigation words e.g. PFA>CFA
• ?DUP instead of -DUP
• Vocabulary support omitted
• CFA is 1-byte wide

STOP PRESS - Mark 1 Cloned!

More homemade computers

You'll find more homemade computers on my links page.
Please visit the other sites on the web ring (below) and don't forget to have a look at my Mark 2 FORTH Computer.

Join the ring?

Copyright © Andrew Holme, 2003.