My take: In the real world code deals with 8-bit byte values all the time. So an 8-bit CPU is sort of the minimum "practical" world architecture for getting things done. So it's interesting from that POV.

Also because of the above, 16/32/64-bit ISAs have to support dealing with bytes, so they end up either including instructions to explicitly deal with them, or constantly having to mask the upper bits of values/registers.

Unfortunately 8-bit CPUs were also almost always tied with 16-bit address buses. Back then when memory was super costly, this was fine. But later on, it became their biggest limitation and all sorts of awkward paging/segmenting stuff was caked on top in order to make them work with memory sizes greater than 64k.

I sometimes wonder how things would have gone if we'd settled on having "bytes" be 12-bits (like the PDP-8) or something instead, with the first gen of address buses being 24 bits. That would have made the first generation of home computers have a lot more longevity.

Hell, I believe the PDP-11 only had 16-bit registers, imagine if we'd just started our journey that way.

One of my "some day", "probably way more effort than I want to spend" projects would be to create a 40-ish-pin DIP module that contains a RV32 core and has a 6502-like pinout so you can build small homebrew computers that use the RV32 ISA. There are a ton of comporomises that would have to be made, but that's part of the fun.

Most of the small RV32 microcontrollers have a low pin count lots of on-board devices, and it's not as straightforward as gluing together a CPU, RAM, ROM, and some IO devices on a breadboard.

Basically, an answer to the questopn "how would a breadboard computer built in 1977 look if the RV32 ISA existed?"

8-bit CPUs have 8 data pins (D0-D7) and anything going in or out of the CPU is doing so 8 bits at a time. This includes all external accesses such as RAM, ROM, and I/O.

But 8-bit CPUs have more than 8 address lines, because 256 bytes total for combined RAM, ROM and I/O space is not useful. That number I think is typically 16 although Signetics 2650 had only 12 (with the instruction set only supporting 12-bit addresses), and the Atari 6507 (6502 derivative) had 13 (instruction set still supporting 16-bit addresses but the upper 3 bits of addresses were basically ignored).

> Is it just a matter of replacing all instructions/chips/buses to be 32 bit/lane?

Depends on the 8-bit CPU really.

- The Z80 lets you combine specific register pairs to work with 16 bits and address memory through them.

- The 6502 does not, but has the whole "zero page" thing where the first 256 bytes of RAM can contain 16-bit data and pointers.

- Both the Z80 and 6502 have a stack pointer register (the 6502's being 8-bit and fixed to point to RAM locations 512-767). But the 2650 had an internal 8-byte stack and stack pointer.

- The 8051 (and the 8048 I think) has lots of instructions for manipulating individual bits in registers and RAM, and also has a division between the memory that opcodes are fetched from versus data. None of the above work like that (the F8 might).

I recall the Signetics 2650 as having 15-bit internal addressing with the 16th bit used for an indirect addressing mode. But yes, not all 15 bits being routed out to pins it had pretty limited memory potential.

The 6502's stack is hardwired to $0100-$01FF (256-511).

And much slower cf zero page. Hence we are told not to use stack as far as we can.

Wow. If anything, working around 8 bit's limitations seems to make 32 bit look simpler in comparison.

I think it's the combination of those cheap CPUs with 80s home computer hardware, where the hardware was designed as "game engine API", e.g. you just needed a handful of instructions to define a sprite and move it around on screen, without any library or driver inbetween. And those systems were hard-realtime. All timing was predictable down to the clock cycle, which allowed to synchronize rendering code with the video beam by cycle-counting.

These are things that are no longer possible on modern computers (but in return we gained a lot of performance by decoupling hardware components).

TFA explains:

* "Graphics and sound weren’t hidden behind ‘APIs’."

* Programs were written in 8 bit assembly

* Generally, the 8 bit CPU was considered a complete package, rather than just one small piece as RV32I is.

Those sound nice to have for didactic purposes. 32 bit could do that, but the RISC-V ecosystem/community seems keener on integration with wider world, rather than keeping a small complete system.

I'll check out some 8 bit ecosystems/communities. Video game space seems active? Or maybe there's a RV32I community for writing retro style games, with some simple graphics support?

I started an FPGA hobby project a few years ago (Before Covid[tm]) that tied a PicoRV32 core to my custom hand-made 80s-style "video chip" VDP type + direct access to SRAM with the hopes of making something like a "Retro-V"; boot straight to a BASIC (or Lua or something) prompt, etc. I had it supporting text generation, and most of the stuff to do simple tiles/sprites, and booting into a little custom "kernel."

I stalled once I started trying to integrate with the SD Card on my dev board. It got un-fun and then I got distracted by the apocalypse.

But I still think it's a neat idea, to tie RISC-V to that kind of "instant on" hobbyist architecture.

EDIT: looks like this "IceStation" project ended up doing mostly what I was intending, and started not long after me, but actually shipped something. Mine was targeting a Xilinx Artix-7 board, tho.

> Or maybe there's a RV32I community for writing retro style games, with some simple graphics support?

Wow, https://github.com/dan-rodrigues/icestation-32 looks cool. Sorry for the comment spam. :)

Cool link, reply more if you find them!