To get both blinkenlights for registers and tri-state for bus driving, use two ’574 chips in parallel rather than a ’377 behind a ’245. Tie the clock and input lines together on both. Tie the output enable low on the one driving the blinkenlights. This way the chip that the rest of the CPU depends on doesn’t have the extra work of driving any load and you only have one chip’s worth of propagation delays.
You have to be a little mad to do this but exceptionally mad to do it on at least 8 independent breadboards using no less than 4 different styles of jumper wire!
Hi Will, absolutely amazing this, I love the 'money shot' up front, there are days my desk and yours could be swapped without either of us realizing right away what happened.
The Rigol deserves a blog post of its own, I've got one too and the better I get in using it the more I'm amazed at what it can do.
I've run into the same 'all you can get is SMD' which is fine for when you're finished but a lot harder while you're still figuring things out. This is where 'proper engineers' can go straight to the finish line and I always struggle.
You also develop some kind of sixth sense for when something is misbehaving. If you haven't read it yet, 'The Soul of a New Machine' might be to your liking.
Of course while you're doing the next version you should knock out a tiny tapeout version, it should easily fit in a single cell (maybe 2 if you want to push the 256 byte sram in as well)
Hello Will, interesting read, and happy to see 8-bit breadboard builds on HN. I used to follow Ben and James years ago and built a fully functional 256-byte ROM/RAM cpu that could accept instructions from Arduino as a IO input. I gave up on extending output to add a mini OLED.
Cool to see your project and can't wait for part 4.
You can do so much before needing to buy anything or even learn any electronics. There’s a lot of good simulation options out there like Digital, Logisim-Evolution, even video games like Turing Complete and Logic World! That’s before you even get into stuff like Verilog. Thanks for the kind words!
I always applaud homebrew cpu designs but after doing so many myself I would reaaaaly advice to stay away from dip chips/breadboards/wirewraps and any attempts to put it into real physical world. Taking a build out of a logisim/verilog to real world in chips sucks away all the fun about cpu design - suddenly you have to deal with invisible issues like timing, glitchy half-dead chip, bad wire connection, etc. these are not challenges, just mundane dull work.
The only exception to „stay in the sim“ rule is if you want to make an „art statement“, i.e. like BMOW (or my relay cpu https://github.com/artemonster/relay-cpu/blob/main/images/fr... /shamelessplug)
I'm totally with you personally, but sometimes doing the actually hard part is fun. Type 2 fun.
Long ago I took a CPU architecture class and we implemented designs in Verilog as a final project. Apparently people who took the class in the late 90s (before my time) could actually tape-out their designs and pay a few hundred dollars to get fabbed chips as part of a multiproject wafer. I was always curious if those chips actually worked, or just looked pretty.
My advice would be to consider the possibility, not necessarily to stay out of the physical world. For some, those physical details may be the fun part. Some hate verilog. Some want to put it on an FPGA, some don't. I, personally, moved away from FPGAs due to bad documentation (looking at you, Lattice).
An alternative to Verilog is RTl simulation in a higher-level Language, or even higher-level Simulation.
Just remember that you can't define what is "fun".
id take it further to say dont even design your own ISA because its super rewarding watching your custom designed CPU run real software from an actual compiler (all you need is rv32i minus the CSRs)
Couldn't disagree more. To the extent building a homebrew CPU is interesting at all, for me it's _only_ making it actually work despite all of the real world hiccups that make it interesting. Designing it in the simulator is "easy".
The first image I saw gave me considerable anxiety and dread lol. I am so impressed, and have always wanted to do something like this. I took a digital logic course in university that was an absolute blast. I never wanted to stop there, but ultimately ended up doing so. However, just looking at all those wires made me feel a sense of, "Maybe I won't do this after all."
Dread was the desired outcome haha. I was also kind of excited to prove to others that you can have fast clock speeds without spending forever bending and stripping wires (for my fellow lazy/busy people).
Honestly even though it is a bit of a rats nest, in my mind it feels like a kind of organized chaos. And easy to trace any single route.
> It’s a standalone tool that lives outside the computer. I put the EEPROM into the socket, and connect via serial to my laptop to upload the binary files.
Huh, I guess I never really thought about it, but how did they program the first CPUs? Like how did they overcome the chicken/egg situation?
IIUC, that's what sci-fi LED panels of really old computers were. They showed all the internal statuses of the CPU as well as CPU-RAM bus. And the toggle switches allowed individual bit overrides.
The operator sets a CPU RESET switch to RESET, then powers on the machine, and start toggling RAM address and data switches, like HHLL HLLH HHHL LLLL. The operator then press and release the STEP push switch. The address 0b 1100 1001 is now set to 0b 1110 0000. This is repeated until the desired program or a bootloader is all complete. The operator finally sets CPU RESET to Normal, and CLOCK dial to RUN.
The CPU exits reset state, initializes program counter with reset vector, e.g. 0b1000, and start executing instruction at PC++. 1000, 1001, 1010, so on. Then oh no, the EXCEPTION indicator comes on, the LED shows 0b 1110 0000. That's divide r0 by 0, etc.
They didn't actually spend every half a day toggling those switches. They loaded their equivalents of bare minimum BIOS recovery code, then the rest wad loaded from magnetic or mechanical tapes. Only when computers were booted up blank slate or crashed and in need of debugging, the users resorted to that interface.
If they had the CPU-RAM main bus split into ROM and RAM address ranges in such ways that setting address to reset vector will yield the first byte of a BIOS program lithographically etched into the ROM chip, then simply powering on the machine will do the same thing as loading the BIOS manually.
There were also things like magnetic core memories. They didn't require lithography to fabricate, and there were both ROM and RAM kinds of those.
Of course, if you have sufficiently simple input devices that could do DMA, then you can do something e.g. IBM 1401 did:
When the LOAD button on the 1402 Card Read-Punch is pressed, a
card is read into memory locations 001–080, a word mark is set
in location 001 to indicate that it is an executable instruction,
the word marks in locations 002-080 (if any) are cleared, and
execution starts with the instruction at location 001. [...] To
read subsequent cards, an explicit Read command (opcode 1) must
be executed as the last instruction on every card to get the new
card's contents into locations 001–080.
I imagine the additional wiring on that LOAD button must have been pretty small: the READ functionality already exists in the 1402 device, it also has an output signal that tells when the read is finished (so the 1401 Processing Unit knows when the Read command is done), so you just need to tie that signal into resetting the PC to 1 and then starting the clock.
Actual application code was hardwired, entered manually with switches and lights, or with punch cards. Later, when ICs were sufficiently advanced, mask-programmed ROMs/PLAs.
Electrically, essentially what happens in most mask ROMs, but as a circuit board that allowed you to solder in a diode or not in each bit location in order to specify a 1 or a 0.
When I was building embedded controllers with 6502 processors in the 1970s and 1980s we used UV erasable EPROMS and a programmer (my own design) with a ZIF socket built on an expansion board in an Apple ][. The prototype board also had a ZIF socket but the production boards would have ordinary DIL sockets, our production volume was too low to warrant ordering actual ROMS so we used the UV erasable ones and put a metallised sticker over the window.
All programming was done on the Apple in 6502 assembler. It took 45 minutes to assemble an 8kB rom image. This meant that you took extreme care to think about what the code was doing as assembling a new image was often the most time consuming part of the Edit-Assemble-Test loop.
For the microcode ROMs they can just be “hardwired” with a zillion simpler gates. This has the added benefit of supporting way higher clock speed. For my planned program ROM you would either have to input manually like the first computers, or use other things like punch cards or your computer would be again “hardwired” to load programs from some other media
He says that's for microcode ROMs though? As opposed to a user program written in machine code that you would use the CPU to execute. I don't believe ancient CPUs had microcode. Everything was implemented in hardware.
68K, System 360, Sperry 1100, and even the 'ACE' to name the great grand daddy of them all had microcode.
Technically the 6502 and the 6800/09 did not, they used a dedicated decoder that was closer to a statemachine than microcode, even though both were implemented in hardware.
None of the smaller CPUs had 'loadable' microcode, but plenty of the larger ones did.
CPU's microcode can be surprisingly simple: The CPU has bunch of internal signals, which activates certain parts of the CPU and the logic when to turn each signal on comes from reading bunch of input signals. The microcode can be just a memory where the input signals are the memory address and the output is the control signals.
It's just that at some point when it's all physically wired up in hardware as opposed to being stored in some form of memory I have difficulty thinking of it as code or a program. By the time you're rearranging wires to enter a "program" aren't you actually refactoring the CPU itself?
Anyway I feel like the answer to the chicken and egg problem originally posed is to point out that things used to be different. Tools such as text editors and compilers are merely modern syntactic sugar.
I'm going off memory (of a book, not that I was alive in the 40s, ha) so grain of salt etc but I believe the very earliest (edit: electronic, digital) computers were literally rewired every time they need to be re-programmed.
To get both blinkenlights for registers and tri-state for bus driving, use two ’574 chips in parallel rather than a ’377 behind a ’245. Tie the clock and input lines together on both. Tie the output enable low on the one driving the blinkenlights. This way the chip that the rest of the CPU depends on doesn’t have the extra work of driving any load and you only have one chip’s worth of propagation delays.
Amazing tip! Will do
You have to be a little mad to do this but exceptionally mad to do it on at least 8 independent breadboards using no less than 4 different styles of jumper wire!
Gotta use what you’ve got! Thanks for recognizing the madness :)
Hi Will, absolutely amazing this, I love the 'money shot' up front, there are days my desk and yours could be swapped without either of us realizing right away what happened.
The Rigol deserves a blog post of its own, I've got one too and the better I get in using it the more I'm amazed at what it can do.
I've run into the same 'all you can get is SMD' which is fine for when you're finished but a lot harder while you're still figuring things out. This is where 'proper engineers' can go straight to the finish line and I always struggle.
You also develop some kind of sixth sense for when something is misbehaving. If you haven't read it yet, 'The Soul of a New Machine' might be to your liking.
best of luck with your project!
Oh, and I did read all the way to the end.
This is such a nice comment! Thanks for reading :)
No, thank you!
Looking forward to part 4.
Of course while you're doing the next version you should knock out a tiny tapeout version, it should easily fit in a single cell (maybe 2 if you want to push the 256 byte sram in as well)
Any time I see rounded corners on a PCB I know someone put love into that board. Well done
Hello Will, interesting read, and happy to see 8-bit breadboard builds on HN. I used to follow Ben and James years ago and built a fully functional 256-byte ROM/RAM cpu that could accept instructions from Arduino as a IO input. I gave up on extending output to add a mini OLED. Cool to see your project and can't wait for part 4.
Also tried to homebrew CPUs before but couldn't even start due to a wall of things to prepare;
Seeing this is just amazing to be honest. Wish you a luck on your project!
You can do so much before needing to buy anything or even learn any electronics. There’s a lot of good simulation options out there like Digital, Logisim-Evolution, even video games like Turing Complete and Logic World! That’s before you even get into stuff like Verilog. Thanks for the kind words!
I always applaud homebrew cpu designs but after doing so many myself I would reaaaaly advice to stay away from dip chips/breadboards/wirewraps and any attempts to put it into real physical world. Taking a build out of a logisim/verilog to real world in chips sucks away all the fun about cpu design - suddenly you have to deal with invisible issues like timing, glitchy half-dead chip, bad wire connection, etc. these are not challenges, just mundane dull work. The only exception to „stay in the sim“ rule is if you want to make an „art statement“, i.e. like BMOW (or my relay cpu https://github.com/artemonster/relay-cpu/blob/main/images/fr... /shamelessplug)
I'm totally with you personally, but sometimes doing the actually hard part is fun. Type 2 fun.
Long ago I took a CPU architecture class and we implemented designs in Verilog as a final project. Apparently people who took the class in the late 90s (before my time) could actually tape-out their designs and pay a few hundred dollars to get fabbed chips as part of a multiproject wafer. I was always curious if those chips actually worked, or just looked pretty.
Type 2 fun, totally stealing that!
My advice would be to consider the possibility, not necessarily to stay out of the physical world. For some, those physical details may be the fun part. Some hate verilog. Some want to put it on an FPGA, some don't. I, personally, moved away from FPGAs due to bad documentation (looking at you, Lattice).
An alternative to Verilog is RTl simulation in a higher-level Language, or even higher-level Simulation.
Just remember that you can't define what is "fun".
id take it further to say dont even design your own ISA because its super rewarding watching your custom designed CPU run real software from an actual compiler (all you need is rv32i minus the CSRs)
Couldn't disagree more. To the extent building a homebrew CPU is interesting at all, for me it's _only_ making it actually work despite all of the real world hiccups that make it interesting. Designing it in the simulator is "easy".
The first image I saw gave me considerable anxiety and dread lol. I am so impressed, and have always wanted to do something like this. I took a digital logic course in university that was an absolute blast. I never wanted to stop there, but ultimately ended up doing so. However, just looking at all those wires made me feel a sense of, "Maybe I won't do this after all."
Dread was the desired outcome haha. I was also kind of excited to prove to others that you can have fast clock speeds without spending forever bending and stripping wires (for my fellow lazy/busy people).
Honestly even though it is a bit of a rats nest, in my mind it feels like a kind of organized chaos. And easy to trace any single route.
> It’s a standalone tool that lives outside the computer. I put the EEPROM into the socket, and connect via serial to my laptop to upload the binary files.
Huh, I guess I never really thought about it, but how did they program the first CPUs? Like how did they overcome the chicken/egg situation?
IIUC, that's what sci-fi LED panels of really old computers were. They showed all the internal statuses of the CPU as well as CPU-RAM bus. And the toggle switches allowed individual bit overrides.
The operator sets a CPU RESET switch to RESET, then powers on the machine, and start toggling RAM address and data switches, like HHLL HLLH HHHL LLLL. The operator then press and release the STEP push switch. The address 0b 1100 1001 is now set to 0b 1110 0000. This is repeated until the desired program or a bootloader is all complete. The operator finally sets CPU RESET to Normal, and CLOCK dial to RUN.
The CPU exits reset state, initializes program counter with reset vector, e.g. 0b1000, and start executing instruction at PC++. 1000, 1001, 1010, so on. Then oh no, the EXCEPTION indicator comes on, the LED shows 0b 1110 0000. That's divide r0 by 0, etc.
They didn't actually spend every half a day toggling those switches. They loaded their equivalents of bare minimum BIOS recovery code, then the rest wad loaded from magnetic or mechanical tapes. Only when computers were booted up blank slate or crashed and in need of debugging, the users resorted to that interface.
If they had the CPU-RAM main bus split into ROM and RAM address ranges in such ways that setting address to reset vector will yield the first byte of a BIOS program lithographically etched into the ROM chip, then simply powering on the machine will do the same thing as loading the BIOS manually.
There were also things like magnetic core memories. They didn't require lithography to fabricate, and there were both ROM and RAM kinds of those.
Of course, if you have sufficiently simple input devices that could do DMA, then you can do something e.g. IBM 1401 did:
I imagine the additional wiring on that LOAD button must have been pretty small: the READ functionality already exists in the 1402 device, it also has an output signal that tells when the read is finished (so the 1401 Processing Unit knows when the Read command is done), so you just need to tie that signal into resetting the PC to 1 and then starting the clock.The pictures of workers weaving a program into core rope memory is peak steampunk vibes.
Weaving and computing are closely intertwined
Actual application code was hardwired, entered manually with switches and lights, or with punch cards. Later, when ICs were sufficiently advanced, mask-programmed ROMs/PLAs.
Or diode matrix ROMs were pretty popular as well.
Electrically, essentially what happens in most mask ROMs, but as a circuit board that allowed you to solder in a diode or not in each bit location in order to specify a 1 or a 0.
That would be the "hardwired" option.
When I was building embedded controllers with 6502 processors in the 1970s and 1980s we used UV erasable EPROMS and a programmer (my own design) with a ZIF socket built on an expansion board in an Apple ][. The prototype board also had a ZIF socket but the production boards would have ordinary DIL sockets, our production volume was too low to warrant ordering actual ROMS so we used the UV erasable ones and put a metallised sticker over the window.
All programming was done on the Apple in 6502 assembler. It took 45 minutes to assemble an 8kB rom image. This meant that you took extreme care to think about what the code was doing as assembling a new image was often the most time consuming part of the Edit-Assemble-Test loop.
For the microcode ROMs they can just be “hardwired” with a zillion simpler gates. This has the added benefit of supporting way higher clock speed. For my planned program ROM you would either have to input manually like the first computers, or use other things like punch cards or your computer would be again “hardwired” to load programs from some other media
He says that's for microcode ROMs though? As opposed to a user program written in machine code that you would use the CPU to execute. I don't believe ancient CPUs had microcode. Everything was implemented in hardware.
What you believe doesn't really matter.
Plenty of 'ancient' CPUs had microcode.
68K, System 360, Sperry 1100, and even the 'ACE' to name the great grand daddy of them all had microcode.
Technically the 6502 and the 6800/09 did not, they used a dedicated decoder that was closer to a statemachine than microcode, even though both were implemented in hardware.
None of the smaller CPUs had 'loadable' microcode, but plenty of the larger ones did.
CPU's microcode can be surprisingly simple: The CPU has bunch of internal signals, which activates certain parts of the CPU and the logic when to turn each signal on comes from reading bunch of input signals. The microcode can be just a memory where the input signals are the memory address and the output is the control signals.
It's just that at some point when it's all physically wired up in hardware as opposed to being stored in some form of memory I have difficulty thinking of it as code or a program. By the time you're rearranging wires to enter a "program" aren't you actually refactoring the CPU itself?
Anyway I feel like the answer to the chicken and egg problem originally posed is to point out that things used to be different. Tools such as text editors and compilers are merely modern syntactic sugar.
Even Babbage's Analytical Engine had microcode.
Would you care to elaborate? That sounds both unlikely (but I assume I'm just naive) and also interesting.
I'm going off memory (of a book, not that I was alive in the 40s, ha) so grain of salt etc but I believe the very earliest (edit: electronic, digital) computers were literally rewired every time they need to be re-programmed.
Yes, check out this https://computerhistory.org/blog/programming-the-eniac-an-ex...
Plugboards! Think telephone exchange but used as a ROM.
Here is a blog post describing how to do it with a PDP8. Note: he used an assembler but in those days you had do translate to machine code by hand.
https://raymii.org/s/articles/Toggling_in_a_simple_program_o...