ED-64: A discrete 8-bit computer

Description

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!

Details

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.

Files

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

Project Logs

Collapse

Data Multiplexer
Andrew Starr • 09/30/2017 at 04:29 • 0 comments

The Data Multiplexer board is complete, and partially populated with modules. Its job is to select between accumulator and manual program data as the source for the memory data in, and select between memory data out and input port as the source for the accumulator and AREG mux.
I've run out of 2-to-1 mux modules, and need to make some more.
Program Counter Up and Running
Andrew Starr • 09/04/2017 at 09:31 • 0 comments

After a exorcising a few gremlins (a diode around the wrong way, and a couple of unsoldered(!) joints), the program counter is working. As usual, here's a blinky video. The counter resets, counts up to 63 (i.e. the complete address space), then address values 0x15 and 0x2A are loaded a couple of times. MSB is top right, LSB is bottom left:
It's interesting that the camera autofocus has a few burps. I guess the LEDs are putting out a fair amount of infrared!
Program Counter Completed
Andrew Starr • 08/27/2017 at 01:10 • 4 comments

The program counter (a presettable 6-bit up-counter) has been completed:
Testing in progress...
Address Register Installed
Andrew Starr • 06/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 Starr • 05/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 Starr • 05/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 Starr • 04/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 Starr • 11/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 Starr • 09/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 Starr • 09/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 :)

View all 33 project logs

Discussions

Charles Stevenson wrote 05/06/2024 at 18:54

Amazing!

Are you sure? yes | no

Tim wrote 04/22/2020 at 20:49

Hi Andrew,

this is a really cool project! Of course, I feel very honored, that it somehow relates to my ancient MCPU design.

I wonder, did you ever complete this?

Best Regards,

Tim

Are you sure? yes | no

Andrew Starr wrote 04/23/2020 at 07:32

Hi Tim, thanks for the kind words!

No unfortunately, cost and time commitment ballooned to the point where I lost interest. I got the ferrite core memory working, declared victory and moved on :)

At the moment I'm interested in 'move machines' - I like the idea that you can do computing simply by shuttling data around in memory

Are you sure? yes | no

Tim wrote 04/24/2020 at 06:49

Ah, too bad. But getting core-memory to work is quite an accomplishment!

Move machines always looked a little like cheating to me. They surely look very simple from ISA side, but you save very little on the hardware compare to conventional architectures, as you need a lot of registers to save instruction state and also a huge bus.

Are you sure? yes | no

Andrew Starr wrote 04/24/2020 at 06:59

Are you thinking of transport-triggered architectures? The only registers in my design (a 'pure' 2x8-bit move machine) are a program counter (in memory space), an address register, and a temporary data register.

Are you sure? yes | no

ATmel91 wrote 02/23/2020 at 19:13

Quick question, how do the multiplexers choose which data input goes through them? What selects the data? And how do the registers load the data into them? What controls that?
EDIT: AREG should probably be named BREG because the accumulator can sometimes be referenced as A or AREG.

Are you sure? yes | no

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

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

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

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

"There is another system"

http://www.megaprocessor.com

Are you sure? yes | no

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

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

transportable?

Are you sure? yes | no

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

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

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

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

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

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

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

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

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

How will you implement the ROM ?

Are you sure? yes | no

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

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

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

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

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

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

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

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

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

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

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

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

Please release the schematics and ISA docs ;-)

It would be fun to write a simulator !

Are you sure? yes | no

ED-64: A discrete 8-bit computer

Description

Details