When we learn about the internals of a microprocessor, we are shown a diagram that resembles the 8-bit devices of the 1970s. There will be an ALU, a program counter, a set of registers, and address and data line decoders. Most of us never go significantly further into the nuances of more modern processors because there is no need. All a processor needs to be is a black box, unless it has particularly sparked your interest or you are working in bare-metal assembly language.
We imagine our simple microprocessor as built from logic gates, and indeed there have been many projects on these pages that create working processors from piles of 74 series chips. But just occasionally a project comes along that reminds us there is more than one way to build a computer, and our subject today is just such a moment. [Olivier Bailleux] has created his “Gray-1”, a processor whose only active components are memory chips, both ROM and RAM.
The clever part comes with the descriptions of how the ROMs are used to recreate the different functions of the processor, through careful programming. Some functions such as registers for example use loops, in which some of the address lines are driven from the data lines to maintain the ROM at a set location. The name of the computer comes from its program counter, which counts in Gray code.
The full processor implements a RISC architecture, and there is a simulator to allow code development without a physical unit. The write-up is both comprehensive and accessible, and makes a fascinating read.
It’s safe to say this is the only processor we’ve seen with this novel approach to architecture. Some more conventional previous features though have been an effort to create a processor entirely from NAND gates, and another made from 74 logic.
The PDP 11 series had a shed load of ROM on the CPU board which it used for the microstepping of the instruction set… Easy to understand and quite flexible.. A bit too geeky for me these days but nice effort though.
this reminds me of a weird idea I had… if some kind of very basic processor could be made entirely out of power transistors. (more specifically, TO-3 packaged ones). Is it even possible? If so, it would be neat to see… just how crazy it would be. Also curious how much power it would require to run.
I don’t see why it should not be possible. But TO-3 is bigger than some relays I have. :-)
This guy built a 6502 out of discrete transistors – looks like he used something surface mount, though.
http://hackaday.com/2016/05/16/a-dis-integrated-6502/
If you built a 6502 out of TO-3s (maybe with some blinky LEDs like the project in the link above), you could put a glass top on it and use it as a dining room table. And, of course, if you do end up building a 6502 out of TO-3 transistors and make it the size of a dining room table, I’d like to see it.
A discrete computer turned into a dining room ?
That creates a LOT of problems, like : “will we ever eat ?” “not until I have checked the halting conditions of this random blinkenligh program”
OTOH this could solve the “plate warming” problem, as the food will stay warm :-D
Why not ?
I’m trying to design a discrete computer with Ge transistors, https://hackaday.io/project/13409-germanium-ecl/ and TO3 transistors might be as slow, yet more space-consuming :-D
As for the current : you don’t need to run them at full power, 5 to 10mA might be enough.
https://hackaday.io/project/8449-hackaday-ttlers has more links to discrete computers, look at the contributors of the project and check their totally crazy ideas :-D
Power transistors have low gain, huge miller capacitance etc. It can be done, but you won’t get much performance (i.e. sloooow) out of it vs smaller switching transistors optimized for the job.
If you’re building a processor like that, you’re not doing it for speed!
Check this out — I helped build one of these in high-school: https://archive.org/stream/Pop195710/Popular%20Electronics/Pop-1961-03#page/n59/mode/2up
Wow !
This paper is a great resource for my current research about 2TFF
https://hackaday.io/project/10698/log/52102-more-bistables
Thanks for sharing !
this reminds me of a weird idea I had… if some kind of very basic processor could be made entirely out of power transistors. (more specifically, TO-3 packaged ones). Is it even possible? If so, it would be neat to see… just how crazy it would be. Also curious how much power it would require to run.
Well a working 6502 has already been made from SMD transistors so I don’t see why TO-3 packaged ones wouldn’t be possible: http://monster6502.com
Makes sense… ROM is the simplest form of programmable logic device, basically a look-up table, which is what FPGAs are built on.
Only the “ROMs” that make up the FPGAs look-up tables are typically less than 128 bits worth of storage.
I was thinking the same thing. Isn’t this just like building a CPU in an FPGA?
It seems pretty much like an FPGA implementation with the LUT’s. The most conspicuous difference is the lack of physical registers though. I bet it is a beast to close timing on!
Thinking more about this, the number of address lines going into a ROM/RAM chip are not that many. This means that you would not get many LUT’s per device using the FPGA LUT methodology. The FPGAs that I use have probably got 7 or 8 lines going into each LUT, with a single bit output. This would mean that a 64K ROM/RAM would only provide 2 LUT’s each. Something else must be going on here.
Well at the very least it allows for a more concrete understanding of how FPGA works.
Now we can tell students that FPGAs are just a bunch of ROM and RAM chips shoved into a tiny package :P
Ah now that is a beautiful piece of work, I’ve had one running in a sim for a while but I’ve never built it in actual hardware or had to deal with the real world complexity that entails.
Mine just uses RAM so when you turn it off there is nothing left, no computer and no data, more secure then an iPhone. ;-) And yeah you need to halt it and inject the state machine then let it run, so it is the ultimate in reconfigurable hardware.
Did you do the sim in a computer or in an FPGA (with RAM LUTs)? :-)
It was a component level sim, I called it RAMB0. It was to settle an argument as to how simple and compact a computing substrate could be therefore how probable it was that machine intelligence could spontaneously arise somewhere in the universe. Memory doesn’t need to be a fixed structure either, it just needs to be a mechanism to allow for the propagation of a self interacting pattern through time. This means that the limits are way down at the sub atomic level in virtual particle pairs amongst the quantum foam, so very small indeed, and everywhere in the universe, even in apparently empty space. This leads to the conclusion that the entire universe must already be a computer and probably sentient.
I find this extremely interesting, I wish there was a book about this.
Do you have some schematic and/or documentation of the project? It would be nice to have a look at it. Thanks for sharing this idea.
Amazing post that was very well written! I love finding out more about CPU’s and reading stuff like this really helps. Got a little bit confused at the Microcode schematics but maybe that just means I will need give it a second read :).
Reminds me of an old Z80 hack for cpu 16 bit output, the BC registers were expressed on the
address lines with the relevant instruction encoded via the data line & appropriate sync
with processor signal lines. ie Look for that instruction & latch the full 16 bit address lines for
output only with a little specialised hardware.
I built that add on for an embedded one running CP/M in 1982 in a console in front of the gear
lever in a 9172 Ford Escort – the cpu non maskable interrupt (NMI) line ran from the distributor
ignition signal ostensibly to fire injectors with all the auto electrical fruit from a VW combi usin
Bosch parts mostly… It worked in a fashion but not ideal, part of my EE thesis – still in the library
of the now Curtin University, Bentley Western Australia (used to be W.A.I.T)…
The BC register pair was used to drive 8 off 7-segment LEDs multiplexed. The cpu’s NMI line
also switched Z80 EPROM code space between CP/M & injector code. Air Flow Meter was a
restrictive flap type not ideal at all for a ford escort inlet manifold & I kept the carbie as a backup…
The ROM/RAM coding issue was used in a table to “decide” upon flags for the EFI state
machine side. Its an old technique and with care re flag states & semiconductor timing is fully
deterministic though simple whereas current operating systems & some embedded systems
seem to take on a more unsettling probabilistic paradigm :/
The ROM/RAM approach was also trialed for ascii graphic character recognition in
a Universal Adaptive Logic Circuit (UALC) simulation on a KL-10 running tops 10 (by DecSystems)
but, there we had some basic code to tally up the match hits on the image ram to show
a recognition probability the asci character graphic was one of the 26, upper case only.
Clunky with slow user interface having to type the row/column to enter the graphic pages
but worked to a good degree…
iirc
Hewlett Packard used a similar rom/ram decoding as part of their micro word architecture
for their first Silicon on Sapphire 32 bit micros – circa mid 1980s…
Need an edit feature please… ?
Doh 1972 Ford Escort Mark 1.
1600 dual down draft progressive carb with bottom of the manifold milled to
take 4 off 2L VW combi injectors…
Couldnt run any floppy io whilst engine running, Cp/M command line for inspection
re peek & poke etc…
Very interesting and cool project, thanks for writing that up! Very inspiring for a young EE major!
Very good article, thank-you for posting this.
I have used ROM for logic functions before but have never seen anything anywhere near this size!
Another project where ROM is ostensibly used instead of logic (for price and ease): dypled.com
https://hackaday.io/project/8693-dypled
“Also keep in mind, that members of the “puritan TTL Nerd fraction” may sneer at you for juggling with lookup tables beyound 1MB.”
(c) Dieter Mueller 2004
What’s the transistor count?
Whenever you see capacitors on digital lines, watch out!
Curious readers will have noticed that SD cards and the PROM storage on their NanoPi’s and BBBs are called NAND storage, implying a connection between PROM and NAND gates.
ROMs made with wired connections – “fusible link ROM” – can do any combinatorial logic function. It is all lookup table. The input is the address of the output.
Cool project. Actually building it and working out the whole thing is great. This was called microcode in the old days, and would have taken a full time team at DEC a couple years!
And these days it seems all the USB flash has almost the same type
of 32 bit micro handling the flash reliability with records of past failures
and the code set looks suspiciously like code variants of 8/16 bit 8051
[I understand the code can be quite sophisticated, moving stuff around
as a consequence of its own internal scans (not observed outside the
device) to ensure data reliability…]
It should be noted there are many possible data hacks here allowing
all sorts of intrustions & opportunity for identity theft , such as:-
1. The USB flash device reporting its 8G when its really 32 G, thus allowing
the embedded micro (with the help of a driver that ostensibly runs & registry
scan & “backs” up to that same USB) scanning your HD & any connected devices
for anything that looks like passwords, personal data eg resume’s, bills, trade
data, myob, excel files eg stock trade data, FP markets. XTrade logs etc
2. Hiding various DLLs & other system compatible code in a hidden partition
even if it doesn’t overtly make wrong claims of its size as in 1 & then if the
occasion arises making this “available” to svchosts & other windows programs
as well as matching a subsequent driver “upgrade” for non related devices.
3. Other, best I not mention but, can be found (I am told) on high end hack
forums…
As always buyer beware, now its user beware – as in determinism becomes lost !
Someone should design a large scale USB intercepter that has a large rom/ram
space to trap data patterns in same format as the virus scans we are used too…
Don Lancaster wrote about using ROMs for such tasks in the “TTL Cookbook” which is still a very useful book 42 years after initial publication.
Why do people waste their time with projects like this? If you want to build/mimic an (e.g.) Micro-Controller “Core”, depending on the scale, just use a simple programmable logic device (e.g., CPLD/FPGA). I’ll never understand this mentality.
Why can’t you understand the idea of “wiked fun” ? I don’t know, since I enjoy it.
But at least understand that the goal is not efficiency :-D
And my endeavours have led me to learn a LOT.
It’s not about the destination but the path :-D
I think you are on the wrong site…
Why do people buy jig-saw puzzles when they can just get a poster instead ?
Why do people get a jigsaw when they could buy a rep-rap, hack it for 4-colour printing with a home-made inkjet head, make a CPU from ROM to control it, and print a poster?
who do people like you waste your time commenting anti-hack mottos on a CLEARLY pro-hack website? did you notice the URL… hackaday…
you will never understand that mentality because it is not the mentality of the article at all, it is not about building a core of any kind at all; it is about using an oldfashioned ROM/PROM/EPROM (but not EEPROM) chip for something other then “use-by-CPU”.
maybe your frustrated cuz you need a little bit more then a software-download to make it work enough to prove something? maybe the author started the entire project with the specific intent of pissing YOU off, as the rest of us enjoy HACKS on HACKaday.
PS: i love the idea of ROM as complex decoder logic, cheap(er) as/then chips (pun intended) and impossible to work with for people that cant take thier hands off of thier keyboards and internet-connections long enough to connect 30-40 wires in a breadboard. (nothing to track, infect, or update)
Harry Lythal SM0VPO als odis osme epxeriments on using EPROMS for designer logic some years back:
http://213.114.137.49/eprom/e-pla-00.htm
So it’s an FPGA design built as a circuit board?
FPGAs have registers after every look-up table. ROMs do not, which makes this a bit trickier.
A great problem to get started with this kind of thing is: How would you use a ROM to add “instant” multiplication to a micro? In fact, use a ROM to convert lower case to upper case and ASCII values to numerals and any other conversions or simple calculations that normally take some addition and/or branching. You need a micro with address and data bus, and you can add a lot of really cool and very fast features with a PROM/ROM.
> You need a micro with address and data bus, and you can add a lot of really cool and very fast features with a PROM/ROM.
For long time I had the idea to build a CPU (with basic TTL chips and registers) with one global address- and data bus (where RAM, program memory, I/O, … can be found) that handles basic stuff like reading from an address, writing from an address, interrupt (1 line, controllable), program counter, very few registers, conditional jump, and maybe just bare minimum arithmetic (increment/ decrement/ maybe shift), and leave out all that optional stuff that is calculation or so. That can be placed on the data bus as external devices. Well, and I also want to add a line where the devices on the data bus can signal “wait, I am slower than you” (just clock inhibition or so), to allow for higher clock speeds than the slowest device on the bus.
Well, and I am just thinking if the registers itself can be just part of RAM?
;-).
I had once obtained a precision absolute pressure transducer that had a serial 16 bit output with 14 bits used for the binary value. I built a circuit with a 16 bit shift register that was used to address a 64Kbyte eprom that I programmed with the 4 digit bcd value of the barometric pressure. Then a 2 bit counter to drive the A0 and A1 lines to readout the value to 4 bcd to 7 segment decoders for an LED display. I had a lot of fun with that project.
Well done, an elegant solution in its simplicity of implementation no processor
required. Talk to graduates even 20 years ago & they had great difficulty thinking
up a solution from discrete logic as uni’s of the day focused on bloated dev kits
centralised around the latest leading edge micros with all the overhead. Its even
harder these days in the engineering sphere to impress that an i7 embedded running
WIn 10 isn’t necessary for a simple piece of gear to do a simple safe industrial interface
task with linear/rotary positioning – especially as so many out there etc…
I used to be engineering manager of Pretron electronics circa 1985, we used cheapest
simple optical quadrature encoders which we made ourselves from acrylic disks & photo
sensors used for press-brake back-gauging for positioning metal sheets prior to bending.
Conventional readouts used complex discrete logic & proprietary LED interfaces. A local
co came up with a dead simple low cost design with a front end 74C86 & 2 resistors/2 caps
to delay edges of the quadrature feed such that it produced a combined 4 bit parallel
value feed into a MC68705 CPU with minor TTL to produce an interrupt whenever the
4 bit pattern changed such that the CPU multiplexing of the LEDs wasn’t interrupted unless
a change in position occurred but, even large positional changes were accommodated
so fast one couldn’t see any flicker – all this for 0.1mm resolution metal positioning for bends.
The display decoding used almost exactly the same format as you describe re pressure
but for segment decoding into an array as the CPU had plenty of parallel output lines…
We also did brushless motor control & theorised the same means could be used to lookup
the motor’s PWM values from a (large) segmented table which got its address from the delta
position re current position & set-point ie No need for PID for the cheapest simplest setup.
The curve of the values in memory previously determined/checked could be fixed in rom for a
particular motor characteristics in a narrow dynamic range utility environment or in ram (from
a rom backup init) with of course means to amend the table to deal with mechanical changes
such as spring constant, loading outside settling range & power fluctuations etc. This approach
minimised CPU overhead & offered a system with intrinsic stability not dependent on CPU
computations other than subtraction. This allowed the CPU to also offer background code for
things like reporting stats re job use for the press-brake, logging etc
Although elegant we never produced one – the technical director preferring a very
expensive but facile “bought one” ie not one that we could use & market which had many
superior options :/ Nuff said about that lost opportunity.
These days many of these variations already used & patents well expired :shrug:
I have to agree with you on some of the younger grads. The tendency is to use an FPGA when a few gates will do. There also seems to be a real lack of understanding of analog/power circuitry.
Indeed Eugene :-)
My tutor at WAIT (Now Curtin Uni Bentley, Western Australia) back then 1979 Ian James got a
request to design an HP-1000 bus to HPIB/Serial interface to drive a largish A0 sized flat-bed
plotter & from an architectural co that had a couple of 19″ rack cabinet HP-1000’s with tape
drives & a whopping 10MByte removable platter. They’d exhausted local design firms that
wanted to use CP/M Northstar computers to do the job & a couple of co’s in US that wanted
to supply a $5000 interface that a simple plugin card *should* handle. He selected me as I
had some patience to deal with odd ball convergent approaches irreverent of tradition ;-)
We ended up designing a plug-in card with about 11 discrete LS chips & a UART on a
wire wrap board – no external $3000 CP/M North star with its 12MByte 8″ floppies & at a
lot less too – I got paid, Ian got his dept qudos and whilst at it I wrote Xcom (did a figure
of 8 x 8 poll at 4MHz yet did 19200 Baud fine on many (~8) devices) for 8080/Z80 to provide
a telnet like comms session across many Northstar/Amiga desktops – just needed a ‘hub’
for switchable RS232 devices, in those days no mean feat as many handshake lines
“got in the way” so the h/shake lines got fudged by loop backs so they didnt matter *grin*
What bothered me about the other co’s was their reliance on latest populist tech that
had nil Provenance with an unclear development pathway – all I did was analyse, simplify
with the benefit of a couple of hrs of truth tables linked to code segments in a classic
state machine architecture. Thing is all this in contemporary uni text books all over the
place yet never read it seems by competitors – as mercans say so often – go figure ;-)
That was all decades ago, now I fart around with day trading but, still get my end in now
& then re strange designs much removed from electronics into biochem realm – go figure that…
That’s more or less what I did with #DYPLED :-D
https://cdn.hackaday.io/images/6897711450044640936.png
Actually today Flash is the best, cheapest, most flexible solution.
Very nice piece of work, very interesting. It is a practical demonstration, but it is not practical in the usual meaning of practice. Thanks for sharing it with others. Thank you.
That’s pretty clever, all-round. I dig using an address-input for clocking, I bet with a little work this could avoid the glitching-problem which was solved, here, by adding capacitors to data lines. E.g. setup the data-outputs with the low clock, then duplicate those outputs with the high clock, one data-output could change indicating data-valid, which would be the clock for the next device… maybe the values aren’t low/high-active, but edge-sampled, or maybe a second/seperate identical ROM and two-phase clocking might act as a more stable ‘latch.’ Got me thinking!
Article is in the web archive: https://web.archive.org/web/20190919182312/http://2x-1.net:80/ob/gray1/