I've always had an idea for creating a homebrew microcomputer kit with the intent to help teach children about how computers work at a much deeper level than, say, the Raspberry Pi. Kids could get the kit, sit down with soldering equipment (and parental guidance), and assemble the computer from parts, learning about how the computer works as they go along. The end result would be a solid understanding of the computer, the satisfaction of having something they made themselves, and have a computer that can do useful things while continuing to teach software and hardware concepts.

And good grief is the choice for microprocessors kinda shitty!

So now I'm going to explain my wish list for an ideal processor and explain the problems with the majority of the current market.

The Wish List

Here is what I think the ideal CPU for this project should have:

1. Actually be in production. This is kinda obvious, but if you're relying on used/surplus/recycled parts, it's harder to ensure consistent quality. And if the supplies dry up, you're toast!
2. Have good documentation. I should be able to easily get a data sheet or reference manual that explains all the pins and their functions, as well as have timing diagrams, so the actual hardware can be, you know, designed. There should also be good documentation on the instruction set used, so the initial software can be developed, as well as provide users with this information so that they can write their own "bare metal" software. You know, like the bedroom programmers of old!
3. Have a good ISA. This ties into the above about documenting the instruction set, but if the instruction set itself is confusing or obtuse, it won't be fun to write software for it! This also includes the development environment, like compilers.
4. Have a straightforward bus. By that, I mean that I should be able to address areas of memory that can be off the CPU itself and access them, for things like user-made software and external peripheral access.
5. Not be too expensive. Don't wanna bankrupt people, after all. Ideally under US$30.
6. Be solderable by a human. So, no Ball Gate Array packaging. I know I've joked on this account about how anything can be hand soldered, but I do not expect a child to dead-bug solder fine magnet wire to individual solder balls on a chip. SOIC and QFP packages are the absolute limit, since they can be soldered with a fairly simple technique by hand. (Apply flux to pads. Tack down two opposing corners with solder. Drag solder with a chisel tip to solder all the pins to the pads. Clean up with rubbing alcohol.) However, larger through-hole components are far simpler for children to handle, and as they are the target audience, DIP packages are preferable whenever possible.
7. Doesn't try to do TOO much extra. Part of the concept is to explain the various components of a computer and how they all tie together. If the microprocessor is a SoC that can do nearly everything, we end up having a single magical chip that... really doesn't help explain things all that much.
8. Not an FPGA. Again, trying to avoid the single magical chip issue.

What's available

Zilog Z80

Yep, the chip that got me to write this chost. From the late 1970s, the Z80 was used in a lot of microcomputer systems, notably the ZX Spectrum, MSX standard, and TRS-80. It was also used in computers that ran CP/M, which powered a lot of businesses before IBM wanted to take the market with their 5150 and a CP/M-like OS. While Zilog's later attempts to create more powerful successors flopped, they kept cranking out the Z80, and it was loved for being a cheap and easy to use part when you didn't need a very fancy microcontroller or CPU. It is beloved by hobbyists, and is the core of the RC2014 standard, which actually manages to do what I wanted from a homebrew computer kit!¹ But then, Littelfuse (who owns Zilog) EOL'd the majority of the Z80 family. This is going to actually kill the people that make RC2014 kits. Yes there are projects that will hopefully fill in the gap being left, but the non-FPGA options don't currently exist as of the time of this writing.

Zilog eZ80

This is basically what Zilog is now offering. It is an enhanced version of the Z80 that has a 24-bit address bus and a bunch of built-in peripherals as it is only provided as a microcontroller. This is currently being used on the Agon microcomputers. However, it is in a 100-pin LQFP format, which has some really fine pins and hits the limit on human solderability. If soldering was easier and Zilog didn't discontinue the non-microcontroller versions, this would be perfect.

WDC 65C02S

Oh hey look, it's the long-time rival to the Z80, the 6502! And it too has still been in production! And... it's actually outlived the Z80?! Wow! This is the same CPU architecture that powered the other famous microcomputers, notably the Apple II, Atari's 8-bit computers (400, 800, etc), and Commodore's 8-bit computers (PET, VIC-20, C64). This architecture was also used in the NES/Famicom. It is a DIP format part that is fairly inexpensive. However, you might find some people grumble about this incarnation not being "the same" as the older 6502s? Yeah I don't fully understand it either. However, making something with this CPU and being able to stand out from all the other 6502-based projects will be rather challenging. But, there's also the issue with WDC itself: it's pretty much one person, Bill Mensch. If he kicks the bucket, what will happen to WDC? Also, will WDC suffer the same wafer supply issue that ended the Z80? If we lose the 6502, we are fucked.

WDC 65C816S

Calling it now, I am going to be bitten by a certain animorpho for this section.² This is the 16-bit enhanced version of the 6502, it's also in DIP format and it's also still in production, but the bus is a complete clusterfuck that I do not want to touch with a ten-foot pole. Okay, so, the 65816 uses the exact same package as a the 6502. It is NOT pin-compatible; there used to be a 65802 that was, but that was a short-lived product. When this chip starts, it starts in 6502 mode, in which it's... a 6502. A really fast 6502, but a 6502 nonetheless. You modify a register to put it into 65816 mode, giving it a 24-bit address bus and a bunch of awesome new opcodes. But wait! If the package is the same as the 6502, which only had a 16-bit address bus, where's the other 8 pins? THEY MULTIPLEXED THEM WITH THE FREAKING DATA PINS. Oh dear lord, multiplexed pins are the WORST. This means you need extra circuitry and parts to de-multiplex the data lines into the missing address lines, which increases cost and complexity. It also limits speed, because now you need to do everything in less than a clock cycle, and that demultiplexing does add latency to the mix. So while the 65816 is capable of outperforming the 68000 at identical clock speeds, you can't run the 65816 very fast because of the tighter memory and I/O timings. The Apple IIGS used the 65816, but it was clocked in the kilohertz. Some people say it was because Apple didn't want to cannibalize their Macintosh line; I think it was due to making the bus more stable for compatability with older Apple II peripherals. Anyway, EVIL

WDC 65C265S

And this part here completely solves that issue! This is a 65816 with a full, non-multiplexed 24-bit address bus. It is also a SoC-type microcontroller with a bunch of built-in peripherals, but you still need external ROM and RAM to do things with it. However, it is in a 100-pin LQFP format, so like the eZ80 it's at the limit of human solderability. Also, there are some issues with the documentation. Namely, page 63 shows (at the time of this writing) a schematic for setting up the needed external clock crystals, but labels both crystals as X1. That's... one hell of a typo. There are also a bunch of other confusing aspects of this document (I'm still horribly confused about how chip select and the memory map works!) that make things a bit tougher to work with. And uh... is there any actual compiler for the 65816 that isn't SNES-specific?

PIC, AVR, and the like

I'm grouping these all together because they all share the same common fatal flaw: They use a Harvard architecture. The stuff I've listed so far uses a Von-Neumann architecture, in which there is just one memory bus for code and data. This allows for general computing; the user can put machine instructions into RAM, and then the processor can execute the code from RAM. However, with a Harvard architecture, code and data are on separate buses. RAM can be written to and read from, but you cannot execute code from here. The code to execute is stored on a different bus, in ROM, inside the chip itself. You cannot alter this region while it is executing code; it has to be put into a special programming mode to alter any data here if the chip will even allow it. (e.g. it's not mask ROM, or it's not one-shot PROM, or the protect bits aren't set.) As a result, there is no way to make the processor execute anything that hasn't already been put into the ROM prior to using it, and since the RAM is also on the chip, there is no incentive to provide any sort of an external bus. Now, this isn't to say that it is impossible to use such a chip for general computing, but enabling it is a complex hack that makes you ask "but why, though?" In short, you can use the GPIO pins to have an SPI bus connection to some serial RAM and some sort of external storage, then in ROM have an interpreter or an emulator that performs actions based on the contents of RAM. People have managed to make BASIC-based machines with the AVR doing this. But then you lose the ability to run code "bare metal" so it's harder to teach the concepts of how computers function at a lower level. And emulating a CPU will incur a performance penalty while also making you ask "but I could also just emulate it on my desktop PC/laptop/phone so why bother with this kit?" and that's no good.

Atmel SAM9260

The first of the ARM-based offerings we'll be looking at. It is a 180 MHz ARM926EJ-S ARM Thumb Processor, with a handful of useful peripherals baked into the chip. It is a 208-pin PQFP format, which is crazy hard to solder, but Atmel seems to not like having it as an option and would rather you use the BGA version, as a bunch of pins have been cut from the non-BGA version because "lol, lmao." It has a 26-pin address bus and a 32-pin data bus, which seems like it would be a bit too much to handle. Furthermore, the internal bus of the chip is a bit... confusing. My head is still spinning from reading the docs. It's only US$12 and you could probably run a cut-down Linux on it or something.

NXP i.MX23

You guys killed the 68000 for this. This is another ARM926EJ-S CPU, but running at a faster 454MHz. It has a 13-bit external address bus and a 16-bit external data bus, but somehow can handle 64MB of memory? It also needs to take DDR memory, which is nnnnnot what I would expect. It also has a ton of extra peripherals baked in, though most of them are kneecapped or removed from the 128-pin LQFP format version, because they want you to get the BGA version instead. It's also more expensive than Atmel's part at US$17. Furthermore, getting that documentation link was a pain in the ass, as I had to dig deep into NXP's website to even find this product and then navigate through multiple redirection PDFs.

Renesas RZ/A1H and RZ/A1L

Great googly moogly! These things are really powerful! These things use an ARM Cortex A9 CPU and come with a bewildering amount of built-in peripherals. There's audio and graphical functions in here, too! But that puts them into the "does TOO much extra" category, as 95% of the computer can be done with just this one chip. They both can handle a 384M address space. The A1H is a 256-pin LQFP format, and costs a whopping US$35. The A1L has less features, is 208-pin LQFP format, and costs just under US$20. They also have absolutely titanic manuals, over 2000 pages each!

Nuvoton NUC980

Yet another ARM926EJ-S based part, this one at 300MHz with a 128-pin LQFP format. Yet again, lots of built-in stuff. There's a 20-bit address bus and a 16-bit data bus, but it has 128MB of built-in DDR memory, which firmly puts it into the magical chip category. In case you can't tell, I'm getting tired of these ARM processors, they're absolute overkill. Why can't someone just stick a Cortex-M0+ core into a DIP format, expose the address and data bus, and call it a day? Am I just making too much sense here?

Lumissil Microsystems T31ZX

Oh finally, a different architecture! This one is MIPS32... hey remember when Wave Computing bought up MIPS, promised to open source the ISA, released it for a super short period, then immediately closed it back up before murdering it in favor of RISC-V? Shame nobody seems to have bothered with archiving the open source release. If you have it, please mirror it somewhere and post a link in the comments! *IT HAS BEEN SAVED! Massive thanks to @JillCrungus for uploading all the stuff to archive.org for all to enjoy! *Anyway, where was I? Oh yeah, the T31ZX. Apparently Lumissil refuses to acknoledge its existence and getting a data sheet was a pain in the ass. (So thank you for mirroring it, Mouser! You saved me!) I'm not a huge fan of the package (QFN??), it's got a lot of stuff built-in (which makes sense since this was originally made for image and video processing), and I don't think it has a proper external bus.

Texas Instruments NS486SXF

...I'm sorry, what? Texas Instruments is making Intel 486 CPUs? And it's a current, active product?? Wuh? BWUH??? I'm er, uh... well, if you want to make a PC compatible, this seems like the chip for you! Also it's US$48 and it's the goddamned x86 architecture so PASS.

...and that's it? Yeesh. Seems like the only viable option left is the 65C02S. Guess Futurama was right after all. Unless someone working for a chip maker is reading this and actually tries making that Cortex-M0+ in DIP idea...

I miss the 68000 ;_;

1. Okay I do have one gripe about RC2014. The backplane connector wasn't really well thought-out and it should have been a keyed connection. The current design is too easy to put in a board backwards and cause actual damage to the boards and backplane! And there doesn't seem to be any consistency on which side the components are mounted in relation to being installed on the backplane when it comes to third-party modules, which is... not very good. I know cost was one of the reasons, but you could have required pulling out one of the pins on the connector before soldering it to the module, and then shoving a pin into the backplane connector to key it.

2. At least you're not the type that infects when biting. Or I hope so!