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.
Looking forward to part 4.
Seeing this is just amazing to be honest. Wish you a luck on your project!
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.
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".
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.
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?
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.
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.
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.
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.
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.
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.
https://raymii.org/s/articles/Toggling_in_a_simple_program_o...