Close
0%
0%

ED-64: A discrete 8-bit computer

ED-64 will be an 8-bit computer built with discrete components, and will feature a ferrite core memory (documented as a separate project).

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

The nitty-gritty:

- 8 bit data width
- 64 byte memory
- Von Neumann architecture
- Instructions are divided into a 2-bit opcode field, and a 6-bit address field
- System memory implemented with ferrite cores
- Logic gates built from discrete surface mount components, as plug-in modules
- Target clock speed of 1 MHz
- Program entry/memory inspection via manual switches
- Input and output mapped to address 0x3f

Oh, and the name? 64 refers to the address space (a la Commodore 64, but without the implied 'k'), and 'ED' is in honour of a good friend's newborn (at the time of writing) daughter. Hi, Edie!

The system architecture is very basic: a single accumulator, 2-function ALU (NOR and ADD), 64-byte address space. It is based on Tim B ̈oscke's MCPU

Emphasis has been on simplicity of hardware and instruction format. All instructions fit within a single 8-bit byte. There are only 4 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.

Programs, data and the I/O ports share the same 64-byte address space.

or Rev B.zip

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

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

Download

and Rev A.zip

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

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

Download

nand Rev B.zip

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

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

Download

  • Address Register Installed

    Andrew Starr06/08/2017 at 09:40 1 comment

    The Address Register panel has been installed:

    The Address Register latches a 6-bit address from either the FC memory or the Program Counter. The output of the Address Register goes to the Address Mux/Decoder installed previously. Here's a short video of them working together:

    Next up: the Program Counter

  • Address Mux/Decoder Completed

    Andrew Starr05/24/2017 at 09:13 2 comments

    See it cycling through the address space:

    The bottom section multiplexes between 2 address sources: the address register and a manually-set address. The top section turns the selected address (blue lights) into a row/column selection for the memory (top right yellow lights).

    I need some power splitter/extender cables before I can connect it to the FC memory, that's a project for this weekend.

    Next panel: the address register itself.

  • Address Multiplexor and Decoder

    Andrew Starr05/06/2017 at 04:37 4 comments

    The next board to be added to the system - it selects between Address Register and Manual Address entry, and converts the selected address to Row/Column selection in the core memory. Pictured here with 6 partially-complete 2:1 mux modules yet to be installed:

    Note that all components get a liberal application of cat hair before installation.

  • Ch-ch-ch-ch-changes

    Andrew Starr04/12/2017 at 09:01 6 comments

      An architecture and name change: the T-1 is now the ED-64, and it is no longer a stack machine. The changes were made for several reasons:

      1. I decided I really wanted to be able to load programs into the memory manually from the operator panel, and the Harvard architecture of the T-1 (and 10 bit program word) wouldn't allow that.
      2. For an 8-bit word formatted [Opcode][Address], a 2-bit instruction width means a 64-byte address space. Since I am avoiding multi-byte instructions, that means I only need to complete a single 64-byte core matrix (which I already have).
      3. Only 4 instructions drastically simplifies the control logic and ALU, while still allowing enough complexity to do interesting things.
      4. I got bored with the 'T-1' name!

  • 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.

View all 30 project logs

Enjoy this project?

Share

Discussions

Kim Chemnitz Chemnitz wrote 05/10/2017 at 07:47 point

Hi Andrew, I am working on a series of CPU's my self but it's only simulated in the program logic.ly. I think it's really cool to see you working on one physically. It could be nice if we could find something out together

  Are you sure? yes | no

Peter lovell wrote 04/15/2017 at 19:31 point

Hi I love this could you let me know if and when you will post the 8 bit planes files

  Are you sure? yes | no

Andrew Starr wrote 04/16/2017 at 00:06 point

Hi there, yes I intend to make all design files available, and for all CAD design to be done using open source tools. If you're interested, all the current CAD files for the ferrite core memory have been uploaded: 

https://hackaday.io/project/11179-ferrite-core-memory-module/files

Please be aware though that the memory hasn't been completely tested (or even finished) so there may well be changes made in the near future.

  Are you sure? yes | no

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

"There is another system"

http://www.megaprocessor.com

  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
transportable?

  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?

http://users.ece.cmu.edu/~koopman/stack_computers/sec3_2.html

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: http://www.excamera.com/files/j1.pdf 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, http://www.hpmuseum.org/hp48s.htm ) The native RPL language (http://www.hpmuseum.org/rpl.htm) 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 http://ygdes.com/CDC/cdc6600.html 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 https://hackaday.io/project/6952-ygwm-whygees-javascript-window-manager)

Maybe a VHDL version is also possible, for inclusion in a DIPSY ? https://hackaday.io/project/6592-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