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.
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.
The problem is that the proposed programming model is even more of a mess than the 816. In 816 native mode, switching register widths just involves a REP/SEP instruction. But with the proposed 832, handling byte and word data would sometimes require a multi-instruction sequence involving XFE. That's pretty painful, especially in interrupt handlers where the 816 already suffers long delays trying to preserve and restore state with the M/X modes.
With the 816, you can sometimes avoid switching with sequences like AND #$00FF. But with the 832, that could involve AND #$000000FF, which is more expensive, especially with the data bus still being 8 bit. It would have been better to repurpose the WDM opcode for a prefix or another switching instruction.
On top of that, the 65832 datasheet is dated March 1990. For comparison, the 80486 was launched in 1989, the 68040 in 1990, and the ARM6 in 1992. This design already looked clunky compared to the 68008, much less what its contemporaries would have been.
> 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 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.
The IIGS uses a 65816, the same 16-bit CPU that's used in the SNES. Since the MiSTer already has excellent SNES support, I don't think there's anything to be done as far as modeling the CPU for the IIGS.
This is a "fantasy" 32-bit extension of the 65816 that WDC specced out but never built. It wouldn't help with getting the IIGS on MiSTer.
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.
The problem is that the proposed programming model is even more of a mess than the 816. In 816 native mode, switching register widths just involves a REP/SEP instruction. But with the proposed 832, handling byte and word data would sometimes require a multi-instruction sequence involving XFE. That's pretty painful, especially in interrupt handlers where the 816 already suffers long delays trying to preserve and restore state with the M/X modes.
With the 816, you can sometimes avoid switching with sequences like AND #$00FF. But with the 832, that could involve AND #$000000FF, which is more expensive, especially with the data bus still being 8 bit. It would have been better to repurpose the WDM opcode for a prefix or another switching instruction.
On top of that, the 65832 datasheet is dated March 1990. For comparison, the 80486 was launched in 1989, the 68040 in 1990, and the ARM6 in 1992. This design already looked clunky compared to the 68008, much less what its contemporaries would have been.
> 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
Agree. I have an Apollo core in my A500. Beautiful piece of engineering.
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?
The IIGS uses a 65816, the same 16-bit CPU that's used in the SNES. Since the MiSTer already has excellent SNES support, I don't think there's anything to be done as far as modeling the CPU for the IIGS.
This is a "fantasy" 32-bit extension of the 65816 that WDC specced out but never built. It wouldn't help with getting the IIGS on MiSTer.
What clock rate does this FPGA version run?
It depends on the FPGA hardware used but the 65832 specification tells of speed between 8 and 10 MHz.