If you're wondering what a 32-bit descendant of the 6502 might have looked like, especially one that incorporated the "radical simplicity" ideas of RISC alongside the radical simplicity of the original 6502, there's already an era-appropriate design you can study: the original 32-bit ARM.

In an 2014 interview¹ with the Computer History Museum, Bill Mensch said:

> We think of ARM as our prodigal son. Got to do what they got to do, and it's not something I want to do, but I'm proud of them. They started with my technology, and I wish them well.

¹: https://archive.computerhistory.org/resources/access/text/20...

So this actually makes more sense to me than the '816. Here's why:

The 816 has a 24-bit address bus. But its registers are limited to 16-bits. So there's no way to represent a "full" address in a register. Aka a pointer can't be held in a register.

Unfortunately this core, staying true to the 816, still has a 16-bit program counter and the awkward banked address scheme of the 816. I assume it has the same restriction of limiting stack and direct-page to the 00-bank, too?

The 816 really felt to me like Mensch just kind of bolted a little circuitry on the side of the 502. It doesn't have the simplistic elegance of the 6502.

A "better" 32-bit 65xx I think would be just to widen all registers (including program counter) out to 32-bits and leave it at that, forgetting about binary compatibility. A big linear memory.

> with just the 65C816, the register modes (8 or 16) bit can be a challenge to work with. When working on the PANCAKE-ROM project, I got bit by mixing up what mode the CPU was in while writing some memory locations. The memory manipulation was assumed to be in 16 bit mode, but it was 8 bit. The 65C832 makes this even more rough.

I've done a little 65816 coding and I quickly learned that it was best to standardize on register sizes throughout most of the code and for routine calls, only switching to optimize things. 8-bit A and 16-bit X and Y made the most sense by far for small-scale asm code. It let you work in 8 bits when dealing with registers and using common 8-bit variables, while being able to loop over larger data structures with X and Y as memory addresses and counters, and also manipulate 16-bit values to some degree (copying, incrementing/decrementing).

Other common CPUs of the time instead either had different registers names for different sizes (80x86), or coded the size in the instruction (68000). This avoided the mode bits and issues with code written for different modes (which even affected instruction length of the 65816 when using immediate data).

The W65C816 is a 16 bit version of the 6502 CPU.

The 32 bit version, called the W65C832, only exists as a datasheet This is a FPGA version.

"builds with the regular opensource FPGA tools: yosys, nextpnr-ice40, icepack, and iceFUNprog. I recently added support for the Tang Nano 20k board (should work with the 9k model too)"

I love these retro cores which extend "what might have been" from the past into the future. Another impressive example is the Apollo FPGA core which over the past decade has faithfully built on the Motorola 68000 series to extend beyond the last chip (68060) adding a variety of modern CPU affordances like 64-bit, instruction fusing/bonding, super scalar, out of order execution for CPU/FPU, dynamic branch prediction, etc. There's an add-in accelerator board that replaces the CPU in an Amiga and the team is working on now adding Atari ST emulation/acceleration to the core.

http://www.apollo-core.com/index.htm?page=features

This 10MHz cousin of the 65C816 is much less fun than the 100MHz 6502!

https://www.e-basteln.de/computing/65f02/65f02/

I would love to see a IIGS MiSTer core. Could this work be ported somehow?

What clock rate does this FPGA version run?