Mid-May, just came across this draft from about a month ago... Still pondering the idea off-n-on.

...

I'm almost certainly in no position to be, right now, but the past two months have finally calmed a bit, and I desperately need to feel like I'm accomplishing something, which I don't get outside my realm... which basically includes everything I probably should be, or have been forced to be, doing.

...

So, I've been revisiting old ideas, one of which is that of building *something* from old CPUs I have laying around, but haven't the experience with to just throw into a project.

Before the crazy-shizzle started (crazier than normal, which has been crazy itself)  I'd spent months (more?) on my TI-86, learning about z80s and more... #Vintage Z80 palmtop compy hackery (TI-86) . (Really, I'd probably kill two birds with one stone if I'd just pick up where I left off on that... but my brain doesn't switch tasks like these easily, there's a huge process involved, this is probably that process). Anyhow, one of the results of that project thus far is a renewed interest and much better understanding in the make-use-of-processors realm.

So, now, I have a pretty well-mulled-over idea of a sort of "homebrew computer" build-process that builds it in pieces, each step along the way doing /something/ blinky and interactive. And a sort-of general-path that should work with a wide variety of CPUs I've stumbled on in my collection; z80, 6800, 6502(?), 8088... even up to the 486. 

E.G. The first step is an easily hand-wired board that merely shows LEDs for the address bus (maybe just 8 bits), and simply wiring the data-bus to NOP (jumper-disableable)... Oh, AND the circuitry necessary for single-stepping. This board will have a header for an IDC-Connector-cable (E.G. an old IDE cable?) connecting the necessary pins for 16bit addressing and 8 bits of data. Though, I'm half-tempted to make it even simpler by just using a chip-clip to breakout to the next boards.

The second board will connect there, and add switches (and LEDs) for the data bus. Unlike other switch-driven systems like the Altair, this won't (alone/initially) be used to enter a program /into memory/ to be run later. Instead the idea is to have a small program which will be entered in "realtime." The processor requests an address, the user toggles the switches for the opcode, then hits "Step," repeat.

Now, with two tiny boards we have 8 bits of the address bus visible on LEDs, 8 bits for data on switches and LEDs, and a step button.

From there, I think the next board will contain a jumper-enableable diode-ROM (and couple/few-bit address demultiplexer) for a program maybe as simple as "jmp address 0". If I get this right, the Diode-ROM containing these instructions (this instruction?) could be mapped in various locations in the address-space via jumpers, and the default NOP from the previous board would be accessed otherwise. Now we have a binary counter (the program-counter) visible on LEDs and resetting at, say, a  selectable count of 4+3=7, 8+3=11, 16+3=19...128+3=131. Basically +3 because all the CPUs I've encountered so far have a 1-byte NOP and a 3-byte absolute-jump. And then, powers-of-two since its easiest to decode with one jumper.

Anyhow, the idea is... I don't want to throw these efforts away, and they're too big to hang on the fridge... So, if Imma build a homebrew computer, maybe I can make each "step" along the way /useful/ even in the "end-product". Each step will introduce more features... When RAM's added, the switches/LEDs on the data bus from the second board will be used to load the memory. The RAM board then will probably add switches and 8 more LEDs for the address bus...

One board early-on may add line-drivers/buffers, then break out to a new header with the same pinout...

Another board down the line might add memory-mapping for more than 64k, So, those same boards from before could be moved /after/ this addition... same pinout. Maybe a second IDC cable could be added for decoded higher addresses, which could then be connected in place of the jumpers on the earlier boards.

Anyhow, I kinda dig the idea, and I /think/ the "bus" can be generalized-enough to work with all these processors... Of course, the NOP and Diode-ROM (and CPU card!) are processor-specific, but the memory and LEDs/switches, line-drivers, and even memory remapping should be doably pretty universal. And I dig the IDC cable over, say, a backplane... Want to add a new card? Just crimp another connector. Want to move your 32K RAM to a mapped address? Unplug from main cable, plug into mapper cable.

Yeah, some of it will be a bit redundant (using only 64k address space from an 8088? 486?! Never switching out of "Real Mode?!")...

But, herein lies another thought-process: ALL these CPUs seem to share a sort-of base level of commonality... The 650x was developed with the idea that the 6800 instruction-set was just too complicated. I feel the same about the 8088 and the z80. Their idea was to /Reduce/ the 6800's Complex Instruction-Set down to only a few necessary instructions... Hmmm.... Sounds RISCy to me.

So, what if I did the same with these /other/ processors? Or at least /treated/ them as though they'd done the same... Suddenly those 486 386 286 chips floating around, the 186s in weird embedded systems long-forgotten, the z80s sitting in old Hayes-Compatible modems that'll never see a landline again, the 6502s in scrapped/dead Commodore floppy drives or old CD players, and So Much More, (what about 8051's?) now become darn-near identical in functionality... Which, yeah, would've been stupid back when the whole point was performance, but no one's turning to these things for performance anymore, right? 

NOW they're relegated to groovy-vintage nostalgia which is near unobtanium, OR ewaste. 

Hey, these are great learning tools. And, hey, in a world where "Right To Repair" is being fought in courts, maybe we could benefit from a few folks' seeing the benefits of once-standardized parts...

We don't /need/ top-of-the-line performance anymore, from specialized parts with one-off manufacturers we're now subserviant to.

I bet there's even some plausibility ARM devices could be "Reduced" a bit like this.

So, now, say we've got a Reduced Instruction/Register Set (RIRS?) that maps almost universally across all these devices... Then, aside from Op-Codes and memory-layouts, RIRS code written for a z80 could be simply converted to run on a 6800 or 8088.

Maybe that's silly if you're talking about trying to load a 3C905 DOS driver on a Kaypro, but it's not silly at all if you're talking about trying to get folk to connect whatever weird-old processor is sitting in their bin to Hyperterminal as the beginnings of a homebrew computer. Maybe load BASIC on a DVD-ROM drive's undocumented "Mediatek" processor...? Or even on an old phone with a broken screen?

I dunno... Maybe I'm the only one with an old modem that realized its processor is the same as the full-fledged computer it was connected to, and wonders what-all it could be made to do.

...U8B, the Unified 8-bit BIOS could plausibly make all 8bit CPUs (and 8086s?) capable of at least running a terminal, BASIC, maybe an OS...? At least a simple game? Well, how would it be accessed? Addresses 000 through 0ff? What about systems with interrupts there? Addresses at the 32KB boundary? (Don't forget some systems expect ROM at 0xffff, others at 0x0000)...

 NOP at boot: EAEA would be the 6502's jump-address... hmmm...

Friggin Paper Tape, DUH.

....

Oh, then I got back to homebrew transistors... It keeps coming up. Thoughts on what happens to the electrons that are deflected by the grid in a triode... If I understand, it basically equates to the cathode is shooting off electrons no matter what, right? So the cathode current remains pretty much constant, then the Anode current is what varies... And then the "amplification" is purely between the gate and the anode, but has little if anything to do with the actual current used in doing-so...