A very long time ago I tried to build a computer from 74LS parts. I didn't get too far. Basically, I had a 40-bit switch input board, a 40-bit LED output board, and a somewhat reasonable ALU.
I had plans to add a register file and instruction decoder and zero clue how to go from there to memory, clock, and I/O — but when I realized how painful soldering has been, and how much worse the register file was going to be, I dropped the whole project.
It was a still fairly cool way to learn electronics, and you can check the pictures and schematics.
So building an entire computer still seems overwhelming, but here's a simpler idea.
I could skip soldering completely by just getting a stack of breadboards. It's going to be less compact, and I'll need to setup some kind of frame for them, but anything beats soldering.
I wondered about wire wrapping as another alternative to soldering, but nobody uses that.
PCBs seem even harder than soldering.
74HC are apparently the new 74LS
I've heard rumors that there are better languages than Verilog for modeling hardware. It would be nice to investigate one of them.
In addition to Verilog-level simulation, I'd like to do some wiring estimates before I start building it.
A compiler for that architecture shouldn't be too hard to build.
What I Actually Want to Build
I want ALU, a register file, and an instruction decoder.
Some Raspberry Pi (or Arduino) will hold the memory contents and interface with I/O — it will still need some kind of controller for it.
The interface between the RPi and computer will itself be somewhat complex.
I'm not sure if I'll have a separate clock, or if I'll use the RPi as clock source.
At some point, I'd like to get memory — but still, every bootup, the RPi will send contents to that memory before my computer will start running.
Even if I get memory and a clock off the RPi, it will still handle I/O, networking, etc. It's nothing unusual — today, every disk, every network card, every Wi-Fi dongle, etc. has a tiny computer on board.
- The fancy multiport register file needs to go as wiring hell, and I can have classic CISC.
Completely separating code and data will simplify a lot over shared memory architecture.
With separate code vs. data, I can make code words as wide as I'd like — it sort of offloads part of the decoder duties to a compiler.
I don't think it will need any fancy microcode — then again, any instruction will inevitably take multiple stages. I could start by having extremely wide words, and then moving parts of this logic gradually to an instruction decoder.
It feels really hard not having 32 bits. Maybe going 32-bit is reasonable — just making registers wider is simple, ALU won't get any harder (ALU won't do multiply or anything crazy like that, we'll do that in software) except for some zero checks etc., so it's just a matter of wiring all that to memory interface.
32-bit architecture would definitely require the RPi as controller — Arduino or a small 74HC chip just won't have enough memory.
Where to start
I think the first step would be to see if Raspberry Pi is a viable memory controller. The RGB LED experiment with software PWM was sort of sanity checking that, but the actual memory interface would be much more complicated.
If it can run at semi-reasonable speed, I can proceed to designing the rest of the system and building it part by part. If it doesn't, the whole approach will need rethinking.