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?

> 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!

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.

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.

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).

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).

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

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.

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.