The T-1: A discrete 8-bit Stack Computer

The T-1 will be an 8-bit stack computer built with discrete components, and will feature ferrite core program and data memories.

Similar projects worth following
Part kinetic sculpture, part tribute to technologies of yesteryear, and part learning exercise.

The nitty-gritty:
- 8 bit data
- 2 x 64 byte stacks (data and return)
- Harvard architecture: 256 byte main memory and 256 word program memory
- 10-bit instruction word
- All data memory implemented with ferrite cores
- Program memory and microcode implemented with 'core rope'-style ferrite transformers
- Logic gates built from discrete surface mount components, as plug-in modules
- Target clock speed of 1 MHz

Here's the system architecture:

It is a 2-stack stack machine, with an architecture influenced by the J1 Forth CPU. Emphasis has been on simplicity of hardware and instruction format. All instructions fit within a single 10-bit word. There are only 8 instructions, from which any required functionality can be synthesised. This will minimise the amount of control logic needed, and is a philosophy I have borrowed from the designers of the venerable PDP-8.

Data and the 2 I/O ports share the same 256-byte address space.

Here's the architecture of the 4-function ALU:

support macros for the dice program

inc - 692.00 bytes - 11/18/2016 at 23:03



simulate dice rolls with PRNG (mostly uncommented, hastily put-together)

asm - 2.09 kB - 11/18/2016 at 23:02


or Rev

Quad 2-input OR gate module, Rev B 10/15

Zip Archive - 164.35 kB - 03/20/2016 at 06:56


and Rev

Quad 2-input AND gate module, Rev A 10/15

Zip Archive - 164.01 kB - 03/20/2016 at 06:56


nand Rev

Quad 2-input NAND gate module, Rev B 10/15

Zip Archive - 121.72 kB - 03/20/2016 at 06:56


View all 5 files

  • Emulator Shield Built

    Andrew Starr11/18/2016 at 22:50 0 comments

    The emulator shield is done:

    I've written a program in T-1 assembler that simulates rolls of a dice. It uses a 32-bit Fibonacci linear feedback shift register to generate a pseudorandom bitstream, which is sampled 3 bits at a time to produce a pseudorandom number from 1 to 6 (0 and 7 are discarded):

    The 8-bit input port is just used to generate a delay.

    I'll upload the code soon.

  • Arduino Shield for Simulator

    Andrew Starr09/14/2016 at 06:55 0 comments

    I've designed a shield for my Arduino Mega 2560, that will provide the input and output ports. Once plugged in, the simulator (emulator?) will be able to do real-world I/O. Not much to it, just 8 LED drivers and 8 debounced SPST toggle switches:

  • Some Housekeeping

    Andrew Starr09/13/2016 at 09:01 3 comments

    Just a minor update - I have done some 'simplification': halved the instruction set to 8 instructions total, and reduced the ALU to 4 functions. This will allow a significant reduction in the amount of hardware I'll need to make, while still allowing meaningful programs to be written. I'm also taking some inspiration from the Kenbak-1 - the I/O has been reduced to one input and one output port of 8 bits each. If this seems extreme, recall that the T-1 is more or less an 'art project' - I'm not trying to replace a desktop PC.

    And there's always I2C/SPI :)

  • Simulator

    Andrew Starr08/25/2016 at 07:47 0 comments

    I have written an instruction set simulator for the T-1. It is an arduino sketch, and runs on an Arduino Mega 2560, using the onboard UART to provide the operator interface. Current simulator functionality includes:

    • Single step and continuous execution modes
    • Execution breakpoints
    • Inspect and modify stacks, system RAM and code memory
    • Inspect and modify top-of-stack register and program counter
    • Halt on stack under- and overflow

    To get a program into the simulator, I have written a shell script that does the following:

    1. Calls the ASL assembler to assemble the code
    2. Calls P2HEX to convert the assembled code into an ASCII hex format
    3. Converts the hex file (using awk) to a header file that is an initialised C array of unsigned ints

    When the sketch is uploaded to the arduino, the header file is included and provides the instructions for the simulator.

    The simulator will allow me to experiment with different instructions, and allow me to test programs before I commit to wiring them.

    Here's a screen capture of the main menu:

    and a code memory dump:

  • Assembler

    Andrew Starr08/12/2016 at 23:11 0 comments

    I now have a functional assembler for writing T-1 code (in order to generate wiring patterns It supports macros, which will help a lot, given my restricted instruction set. It is based on the AS macroassembler by Alfred Arnold. It is a crossassembler that supports many processor families. Arnold includes straightforward instructions in the manual for adding new processors, which I have followed to add T-1 support. Here's an extract of the list output for some simple looping code:

           1/       0 :         cpu t1
           2/       0 :                     
           3/       0 : =0xA    counter	equ	10
           4/       0 :                     
           5/       0 : 000A                push	counter
           6/       1 : 0304    loop1:	dec
           7/       2 : 0309                skz
           8/       3 : 0101                jump	loop1
           9/       4 :         loop2:
          10/       4 : 0104                jump	loop2
          11/       5 :                     

    I am currently working on an instruction set simulator, which will run an on arduino mega 2650 board (the same board I use to test logic modules after I make them). The arduino will take the assembler output and simulate execution, allowing me to test the program functionality, inspect stack and memory contents etc - before I commit to handwiring a ROM board!

  • Now with sub-projects!

    Andrew Starr04/20/2016 at 09:17 1 comment

    The T-1 project blog is beginning to get a bit unwieldy, so I have decided to document the computer sub-systems as separate projects, and use this one as a 'top level' project to tie everything together.

    The ferrite core memory is the first sub-project, it will be followed (eventually) by the ALU, program memory, etc. as I work through and build them.

  • Core Blimey Part II

    Andrew Starr04/19/2016 at 08:17 7 comments

    I had a false start with the first prototype core array, where I discovered that my core orientations and sense wire threading pattern were picking up noise from half-selected cores, causing the sense amp to register non-existent core transitions. I've redone the array wiring in such a way that the orientation of the cores and the path of the sense wire through them results in the half-selection signals cancelling out.

    Here's a photo of a 'new pattern' array:

    To date I have wired 8 core arrays, so I have enough for 1 complete 64-byte memory module.

    I've also prototyped a core selection module. This module will take as inputs an active low signal (one of the row/column selection bits), and a control bit (which will determine what the polarity that the selected drive line is driven in). It is effectively a modified dual 2-input NOR gate. The inputs are common to both gates, and one gate has a PNP transistor where the other has an NPN, so they will respond to opposite polarities of the control bit. The 2 gate outputs go to the 2 drive inputs of the H-bridge controlling a particular row or column drive line. There is a selection circuit and H-bridge for each of the 16 drive lines.

    The question is then, would the core selection circuit, H-bridge and core array all play nicely together? I hooked them up with an arduino to generate the control bit and selection signals. I further added a D-type flip-flop module to capture the output from the sense amp:

    So we have:

    Arduino -> core selection -> H-bridge -> core array -> sense amp -> flip-flop -> Arduino

    I wrote a small program to have the arduino to continuously write a '0' to the core array, then read the array, write a '1', read the array, write a '0'...etc...and report an error if what was read didn't match what was written.

    ...and success! It seems to work extremely reliably, on all the cores that I have checked. Disconnecting either of the drive lines to the selected core causes errors to be generated, which verifies the coincident-current mechanism that is the basis for this type of memory.

    The core switching takes about 1.25us, which seems about right.

    To do next:

    - build the 8 core planes into a complete module and repeat the arduino test - the planes will be wired in series and I want to make sure this doesn't cause any issues

    - test the functionality of the inhibit lines

    - build up core selection, H-bridge and sense amp modules

    - design and build the memory module carrier board

  • Ay-Ell-Yoo

    Andrew Starr03/24/2016 at 06:57 0 comments

    I've added a diagram of the ALU to the Details section. It has 5 functions: bitwise AND, bitwise NOT, Add with carry, decrement, and passthrough. The first 4 fuctions are obvious enough and map directly to opcodes. The last, passthrough, may require some explanation. Passthrough makes the output the same as the A input. This function, in combination with the 4-way mux on the A input, supports the @ and ! memory storage opcodes, and the >R and R> opcodes which shift data between the Data and Return stacks.

    For example, set the multiplexer to [T] and the ALU function to Passthrough. [T] is the data from RAM or I/O (depending on the high address bits) at the address held in T. This data is now passed through and the address is replaced by the memory contents held at that address (similar to how the Forth '@' command works). The Passthrough function in this case avoids the need for an additional register to address the memory.

  • Some housekeeping

    Andrew Starr03/20/2016 at 07:50 0 comments

    First of all, the overall design has been radically changed to something simpler and, I think, more elegant. See the 'Details' section for, well, details. There's a new architecture diagram and I have included a summary of the instruction format and opcodes.

    Secondly, I have begun to release design files, starting with the logic gate modules. You'll find the KiCAD schematic and PCB files, as well as gerbers suitable for sending to a board house.

    Lastly, I have just received the PCBs for core H-bridge drivers. There are 8 per module:

    These drivers will need additional logic to set the individual H-bridge directions. This logic in turn will be controlled by the data state (whether we are writing a '0' or '1') and gated by the row/column address decoder outputs. I am currently prototyping the H-bridge control logic.

  • Memory cores: first experiments

    Andrew Starr02/16/2016 at 09:17 0 comments

    First off, I ought to point out that I'm far from the first hobbyist to experiment with memory cores. Here are a couple of pages I've found very useful:

    Wayne's Tinkering Page

    Andrew Holme's Page

    Ferrite Core Memory Reborn

    And of course, a moment's googling will yield a wealth of further historical and technical information.

    I lashed together a couple of H-bridges to drive the select lines for a single core in the core plane, and a sense amplifier to pick up the switching transitions:

    The H-bridges are pretty rudimentary, here's the schematic:

    The sense amplifier is a tweaked version of Wayne's:

    The above amplifier is the end product of some extensive experimentation. It has a relatively clean output, which I think I'll be able to feed into my logic 'as is' without any further gating for noise immunity.

    I set up an arduino to drive the H-bridges to continuously write a '1' to a core followed by a read. Here's a scope capture of the sense coil signal (measured over a 470R resistor terminating the pulse transformer secondary):

    The big spikes are the core transitions as the magnetic orientation flips back and forth. The smaller blips are artifacts caused by the magnetic fields generated by the select line currents themselves.

    And finally, here is a scope capture of the output of the sense amplifier (orange trace), with the corresponding sense coil signal (blue trace):

    As you can see, each core transition results in a negative-going pulse. I should be able to feed this output straight into, say, the clock input of one of my D-type flip-flops (although I haven't tried yet).


    - check sense amp output can drive logic

    - test functionality of inhibit coil

    - extend prototype system to be able to drive every core in the plane

    - further extend prototype system to be able to drive multiple planes in a 'stack'

    Lots to do!

View all 26 project logs

Enjoy this project?



Yann Guidon / YGDES wrote 05/01/2016 at 03:25 point

"There is another system"

  Are you sure? yes | no

Andrew Starr wrote 05/01/2016 at 10:23 point

Wow! Now that is impressive. And he has built his own memory, instead of cheating with SRAM chips - excellent :) But the expense - 40,000 GBP!! And 18 m2 - I suppose I can start referring to the T-1 as a 'portable'!

  Are you sure? yes | no

Yann Guidon / YGDES wrote 05/01/2016 at 10:25 point

  Are you sure? yes | no

Andrew Starr wrote 05/01/2016 at 10:26 point

Well, it does fit in the back of my car, just

  Are you sure? yes | no

Yann Guidon / YGDES wrote 05/01/2016 at 10:37 point

But you have to keep the engine running to power the onboard computer...

  Are you sure? yes | no

Mike Mueller wrote 01/23/2016 at 13:15 point

Awesome work Andy

Is this the right link to a description of the processor?

Do you have details on the values of the op codes yet?

I assume the O/S will be 256 bytes of ROM? It starts execution at address 0? 

Are there any I/O ports you know you will provide e.g tty in and out?

Where are you at with the software side of things ? :D 

  Are you sure? yes | no

Yann Guidon / YGDES wrote 01/23/2016 at 13:44 point

Andrew seems to keep things under wrap :-)

It makes each progress even more surprising !

  Are you sure? yes | no

Andrew Starr wrote 01/23/2016 at 20:59 point

Not under wraps exactly, I just prefer to document things as they're done. A lot of this project is still in flux. I notice we can add files now, so I'll start releasing the CAD files for the completed logic gates soon.

  Are you sure? yes | no

Andrew Starr wrote 01/23/2016 at 20:55 point

Yes that's the one. However I'm seriously considering changing the architecture to a modified version of this: The instruction format has features that should allow better code density, the instruction decoding will be simpler and the architecture avoids the data bus bottleneck. I won't have dual-port RAM though, so I won't be able to do everything in a single cycle. And the system will be Harvard architecture.

I'll make a decision one way or the other when the RAM is up and running.

The system ROM will reside in a 256-byte space. I'll most likely add a UART at some point.

As far as software goes, I have written a first draft in pseudocode for an application I have in mind, which I will translate into machine code when the instruction set is finalised.

  Are you sure? yes | no

Andrew Starr wrote 01/22/2016 at 21:37 point

I may possibly use a diode matrix in the control logic, we'll see

  Are you sure? yes | no

Andrew Starr wrote 01/22/2016 at 21:33 point

In the same technology 'family' as Apollo, although the Apollo core selection system is somewhat more elaborate than what I will implement (they had to store a lot more information than me, and in a smaller volume!)

  Are you sure? yes | no

Yann Guidon / YGDES wrote 01/22/2016 at 21:19 point

How will you implement the ROM ?

  Are you sure? yes | no

Andrew Starr wrote 01/22/2016 at 21:28 point

At this stage, I'm thinking small 'soft' toroidal ferrite transformers. A wire threaded though a ferrite will couple a signal into the secondary, representing a '1'. It's a very old technique.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 01/22/2016 at 21:30 point

Like what they have used in the Appollo flight computer ?

  Are you sure? yes | no

Yann Guidon / YGDES wrote 01/22/2016 at 21:34 point

I was thinking of a diode matrix but your system is even more... meaningful :-D

  Are you sure? yes | no

Michael Waiblinger wrote 01/21/2016 at 12:50 point

This is amongst the most beautiful things I've seen in a long time. Like Yann said, the exposure of the internals gives depth to its blinkenlights. Very nicely done.

If anything I would prefer a little higher core density.  

If you're interested in Stack Computers you should go for an HP48 (or equal, ) The native RPL language ( is very nearly Forth and it's such a great device to have.

  Are you sure? yes | no

Andrew Starr wrote 01/22/2016 at 20:22 point

Thanks for the kind words Michael. I'm not interested in stack computers per se, I chose a stack architecture because it allows high code density. Code space is at a premium in this project, even more so than RAM (you don't need much for a control application, where you're not dealing with graphics or long text strings).

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/24/2015 at 10:50 point

In the Description part, you forgot to mention the power consumption. What are your estimates ?

  Are you sure? yes | no

matseng wrote 10/06/2015 at 02:36 point

You're using the same bus connectors as the KIM-1 back in the mid-70s !   Is this just a coincidence?

  Are you sure? yes | no

Andrew Starr wrote 10/06/2015 at 03:15 point

Yes - I only picked them because Digikey had plenty of them :) Nice to know they're sort of period-appropriate!

  Are you sure? yes | no

Andrew Starr wrote 09/17/2015 at 08:48 point

Hi Yann! Yes, I'll be releasing everything - schematics, gerbers etc. I'm using open source tools wherever I can. Schematics/PCBs are done in KiCAD, mechanical stuff (e.g. the 3D printed brackets for the mounting frames) is done in LibreCAD and OpenSCAD. 

What's your preferred method of releasing this kind of stuff?

Oh, and a simulator would certainly make debugging less painful :)

  Are you sure? yes | no

Yann Guidon / YGDES wrote 09/17/2015 at 16:15 point

Hi Andrew !
I like your project because "it exposes everything" so it has a lot of educational value, because I love how computers were made in the early sixties (culminating in the before people switched to integrated circuits) and also because it is a minimal architecture that might be easy to integrate in my JavaScript framework (a sort of "CPU development kit" based on

Maybe a VHDL version is also possible, for inclusion in a DIPSY ?

I'm looking forward to learning more about your architecture and its implementation !
Were you inspired by FORTH processors ?

  Are you sure? yes | no

Andrew Starr wrote 09/17/2015 at 20:30 point

Hi Yann, 

The original impulse for this project was exactly that - exposing everything. I wanted to build a machine where I knew the function of every diode and transistor - no 'black boxes'! 

You're right about being inspired by FORTH processors - the architecture of the machine will be pretty much the 'canonical stack machine' described in Koopman's "Stack Computers: The New Wave". Memory is obviously at a premium, and the stack machine seems to offer best 'bang per buck' in terms of codespace. Instructions will be vertically encoded (effectively user-defined in microcode). I've also chosen a Harvard architecture to allow a full 256 bytes of both ROM and RAM with an 8-bit address bus.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 09/17/2015 at 08:30 point

Please release the schematics and ISA docs ;-)

It would be fun to write a simulator !

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates