The idea
For quite some time I've been obsessed with something I'd call a "modern retro computer" (and I'm sure many of you are too).  The "retro" in this name mostly refers to the low complexity of a system, meaning something that can be built and programmed from scratch by an individual – as in the old, good days. The "modern" means that there is zero focus on backward compatibility with the 8-bit machines from the past. That gives freedom in terms of choosing the hardware, and - most importantly - the right instruction set for the project. Although we all love our 65xx, and it's still being produced, it's not necessarily "modern", hence I think building such a system on RISC-V (32-bit) would make much more sense. The key reasons, in my opinion:

• modern, elegant ISA, that is quite good for manually implementing in ASM
• LLVM support - for writing software in almost any language

Problems
Unfortunately, most home built machines lack software. Usually there is some Monitor (WozMon), some form of Basic, and - if the creator is ambitious enough - a port of Pong or Tetris. Plus a plethora of started and never-finished tiny OSes/kernels.  I dare to hope that RISC-V and LLVM support would massively increase the chance of having more software being produced or ported to such a platform. 

The major problem with existing RISC-V boards is that they offer overwhelmingly too much for a hobbyist - far beyond any notion of building anything from scratch. (It was interestingly pointed out, and discussed with Gordon in the What's the most human-friendly instruction set? thread.)  

And finally – there is a "conversion problem", that is both: sentiment and experience driven. "Oh, I've spent the last 20 years building my 6502 SBC and invested so much energy and time in it. I have no more energy left for switching to something new..."

Proposal / vision 
Based on the above I started thinking about the FPGA-built RISC-V core and board, that would be (some of you will laugh, I know)...  pin-compatible with 65xx. What does it mean? Well - you stick such a processor board in the 65xx socket on your current home-built machine and voila - you have a working computer and - of course - no working software    That's perhaps an extreme example, but in general it exposes the following features:

• unlike most of RISC-V boards, we offer just a CPU, rather than a complete microcontroller with too many features 
• a sane number of pins defines a platform for creating home-built computers on prototype-boards, and all the fun related to it. The pinout compatibility with 65816 is just a feature/idea, not necessarily a requirement. But the low'ish number, breadboard-friendly pins is a must. 

So, as you see, I am not thinking about any closed platform (like, i.e. Commander X16), with defined architecture and components. I am thinking about making RISC-V available for electronics, DYI, ASM, OS enthusiasts as an alternative to the "old stuff". Some "reference" platform/software may emerge from such an idea - and I believe it would be great to have something like that - but it's not a goal per se. 

Dream
If you read so far, and you find some sense in the idea, let me propose something, that could be a very nice challenge. I'm quite new to this Forum, but I've learned already that it's full of extremely knowledgeable and talented people, and I think I've seen here almost all possible and the most complicated and crazy projects. With one exception (but maybe I missed something) - a collective project There is, obviously, a collective support - almost every question here is answered and those seeking help will certainly receive it. But how about actually doing something together and delivering it (means avoiding a risk of sinking in endless discussions)? I think that would be something and a great use of the energy and knowledge here! Hence - if you like what I've proposed here - I propose to do it together.... 

Some technicalities
I wanted to avoid any solutionalization - my goal is to share with you the idea rather than any particular recipe, but here are some thoughts (TBD):

• Risc-V 32 bit, on FPGA, no internal clock, no ROM/RAM/IO devices,
• 8-bit data bus (means 4 cycles per instruction) for hardware simplicity
• 24-bit address bus (perhaps 16+8, so 65816 style) should be sufficient (who needs more than 16MB RAM in a homebuilt machine?)
• assumption the system will run in tens of MHz max, subject to the external clock and timings of circuitry 

References
I've learned here that any idea that comes to my mind has been already discussed at this Forum, or even built, so of course I looked for something similar. The only similar thing I found was 65RISC-V, proposed by Springfield last year. Although, in his proposal, he thought about RISC-V ISA extension, that would support 65xx ISA. Anyway, the idea of utilizing RISC-V as a friendly platform, was recalled here a number of times, that proves to me it may make sense to go this direction.

So, time for your thoughts....

I wonder if making a CPU board for rc2014 would be a good way to go. There's an existing active community, and the backplane already has various retro-style peripherals. Initially a z80 design, there are other CPUs now including 6502.

Another idea: like the Pi Pico, make it simple enough a CPU and memory system to be cycle-countable. That rules out caches, and most fast-CPU tricks. However, you can have small local RAM in the FPGA, for fast code or data access. Manually placing hot data and code is the sort of thing that's needed in a retro system.

I should add, I’ve nothing against a board which is 816 pin compatible. Still the chance of onboard fast ram or even cache if you prefer a bit of non determinism. You’ll need one or the other in any case I think to make up for the 32 bit instructions

If you do a RV32I core i would heavily recommend including at the very least the Compressed Instructions extension.
As it adds a few 16-bit versions of existing full sized 32-bit instructions, which helps with instruction throughput as you then only need to fetch half as many bytes.
The Multiplication and Division extension would be a nice to have. and the Atomic Instructions extension is pretty much required if you want to allow people to write multitasking systems.
So "RV32IMAC" would be the golden spot (IMO), giving compilers like GCC/LLVM plenty features to generate decent code with, and allowing assembly users to write stuff themselves without being either overwhelmed by extra extensions or limited in usability by having too few.

on another note, how do you plan on doing interrupts? the Unprivileged RISC-V spec doesn't specify any standard system for interrupts. only the Privileged spec has interrupts built-in.
so you basically have 2 choices (or 3 i guess if you don't bother with interrupts at all).
1. Implement the whole Unprivileged spec and then include the bare minimum of the Privileged spec to have functional interrupts (no User/Supervisor mode, etc)
2. Do something custom.

for the RISC-V CPU i made in Logisim, i went with option 2 as it was much simpler.
i used one of the unused opcodes to implement an RTI instruction and added a hidden register. whenever an interrupt occoured the currentl instruction finished and the PC was saved to the hidden register, then the PC was set to some hardwired value and interrupts were disabled. only after the CPU executes an RTI (which just copies the value from the hidden register to the PC) will interrupts re-enable themselves.
it's kinda ugly but it works and was easy to implement, you could go a bit further and add some extra instructions to read out the hidden register and manually enable/disable interrupts. which allows for nested interrupts.

.

overall i'm excited to see what you'll be making!

Shades of the ARM Thumb instructions because the 32-bit ISA is considered to be too bloated for some applications...

I've never used the 16-bit extension, but as BillG mentioned above - feels a little bit like ARM Thumb. Not sure how it works in case of 16-bit extension, but Thumb is mostly for compilers and optimizers rather than humans. What's your experience?
Agree that Mul/Div extension should be there. And thanks for pointing to Atomic instructions extension - very valid thing.


As you can see in the main post - it's more a concept at this stage, rather than clear vision, so the answer is - I have no clue (yet), and your comments and experience are great here. So far I dealt only with unprivileged RV. Interesting that in your experience it was easier to go with a custom solution than taking the absolute minimum from the Privileged.


Thanks. I truly hope for replacing "you" in your comment with "6502.org community". Realistic?

I've done a little ARM coding, and a little Thumb coding, and I feel Thumb is a bit more difficult - because it's a limited subset rather than a full orthogonal set, so you have know more, or think more. Also, there are fewer registers readily available.

So, other than the code density causing a performance problem (because of the limited bus width) I'd be inclined to suggest omitting the compressed instruction option. A small local fast RAM - which ARM also offers on their small cores - can have full bandwidth, whereas anything off-FPGA will be slower.

As a RISC-V enthusiast I'm sitting quietly in hope ...

Thinking also of micro progression in ye old days too - late 70s/early 80s - Both Acorn and Apple developed '816 systems - the Acorn communicator and the Apple IIgs. Were they popular? In the UK not really. The communicator was aimed at businesses and the IIgs was just stupidly expensive. I've no idea what it retailed for in the US though - I suspect more than the Apple //e...

(Quietly ignoring SNES a good few years later but that was also a 6502 -> 816 progression)

Apple went forward with the 68000. (As did Commodore and Atari) and Acorn invented what we now know as ARM.

RISC was out there from the early 80s though - Berkley RISC and MIPS - great if you were at UCB or Stanford in the US but little known outside academia elsewhere (that I'm aware of). Sun took the Berkley RISC idea and developed Sparc - something very much not aimed at the hobbyist (and interestingly Suns progression was from 68000 to RISC)

So my own personal progression ought to be either '816 or ARM - after all, I started with an Apple II (6502), then a BBC Micro (6502) and Acorn Archimedes (ARM) systems.

And now I've tried the '816 and decided to not take it any further.

So that might leave ARM, but for many reasons I have decided I don't want anything to do with ARM for now, so RISC-V it is.

(Although it could be MIPS)

Mostly as my own thing - a little retro style operating system and utilities is now more or less hardware agnostic. Just like Unix became once the C compiler became portable.

The issue I have now is finding a suitable SoC....

And there is the crux of it all ... how these RISC systems come packaged. Broadly speaking (in the RISC-V world) they're tiny 32-bit microcontrollers with a few 10s of KB of RAM or external DDR memory buses for GB of RAM, multi-core, 64-bit designed for Linux. Nothing vaguely hobbyist friendly has an external memory interface.

The ESP32-C3 and ESP32-C6 are the exceptions with 400KB and 512KB of RAM built-in respectively (Minus 32K for cache) - that might be a good fit for my thing - bearing in-mind in my existing 512KB '816 system about 32K is more or less dedicated to the VM and underlying support OS and the rest of Bank 0 being "fast" RAM for stacks and global variables in the BCPL world, so I'd effectively get 32KB of that back as that code would be in ROM (Flash) in the ESP SoCs.

I do have an FPGA solution with 1MB of RAM and on-board video capability - but making that work is a near vertical learning curve for me - for now. It does have enough external GPIO to be pin compatible with a 6502 but a 2nd layer adapter board would be required.

Back to the subject in-hand...

I think there is probably leverage in having a SoC that can emulate a 6502/816 bus for hardware and external memory access (e.g. existing video RAM?), but at the same time having (say) 1MB of fast internal, 32-bit wide RAM too. (and flash) That may allow the best of both worlds. Just write the software and go..

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

It'd certainly be nice to see something done with RISC-V besides "yet another platform to run *nix on, but X% more Stallman-approved."

I could swear I've seen RISC-V used as a microcontroller core, too.

yea RISC-V is slowly invading the MCU market. i still think the CH32Vx is one of the best 32-bit MCU families right now.

they're like STM32s but run at 5V, are much cheaper (especially the 103 for having a USB host controller on-board), and use a RISC-V core instead of ARM.

RISC-V is going to be less expensive because you are not paying royalty on ARM IP.

https://arstechnica.com/gadgets/2023/03 ... -licenses/

A quick look at AliExpress:
For US$4.15 :https://www.aliexpress.us/item/3256806730357594.html
specs:https://www.cnx-software.com/2022/12/29/bouffalo-lab-bl616-bl618-risc-v-mcu-wifi-6-bluetooth-5-2-zigbee/

BL616 is a RISCV SOC with:
MCU core – 32-bit RISC-V CPU (RV32IMAFCP) @ up to 320 MHz with FPU and DSP, 32KB instruction cache & 16KB data cache
VPU – MJPEG video encoder
Memory – 480KB SRAM, 4KB HBN RAM, embedded 4 or 8MB pSRAM (optional)
Storage – 128KB ROM, 4Kb eFuse, embedded 2, 4, or 8MB flash (optional), XIP QSPI flash support, SD card interface
Wired networking – 10/100M Ethernet
Wireless
2.4 GHz RF transceiver
Wi-Fi 6 (IEEE 802.11 b/g/n/ax) 1T1R up to 229.4 Mbps
Bluetooth 5.x dual-mode (classic + LE)
Zigbee / IEEE 802.15.4
WiFi features
STA, SoftAP, STA+SoftAP, and sniffer modes
Security – WPS, WEP, WPA, WPA2, WPA3
LDPC, STBC, Beamforming, DL/UL OFDMA, MU-MIMO, TWT (Target Wake Time), SR(Spatial Reuse), DCM (Dual Carrier Modulation), ER (Extended Range)
IEEE 802.11e QoS WMM (Wi-Fi MultiMedia), IEEE 802.11w PMF (Protected Management Frames)
Display I/F – QSPI and DBI interfaces for LCD display
Camera – DVP interface
Audio Codec
1x ADC (MIC, SNR > 92dB)
1x DAC (Speaker, SNR > 95dB)
Sampling rates – 8, 12, 16, 22.05, 24, 32, 44.1, 48KHz
Peripherals
USB – USB 2.0 HS OTG up to 480Mpbs
SDIO 2.0 slave
2x UART (Support 5V IO)
2x I2C with host mode support
SPI master/slave
I2S master/slave
1x PWM (4-channel)
12~16-bit general-purpose ADC
10-bit general-purpose DAC
RTC timer
2x 32-bit general-purpose timers
4x DMA channels
General analog comparators (ACOMP)
GPIO – Up to 19x for BL616, up to 35x for BL618
Security
Secure boot; Secure debug
XIP QSPI On-The-Fly AES Decryption (OTFAD)
Support sensitive SW isolation (TrustZone)
AES-CBC/CCM/GCM/XTS modes
MD5, SHA-1/224/256/384/512
TRNG (True Random Number Generator)
PKA (Public Key Accelerator) for RSA/ECC
Clock
Support XTAL 24/26/32/38.4/40MHz
Support XTAL 32.768KHz
Internal RC 32KHz & 32MHz oscillator
Internal System & Audio PLL
Debugging – JTAG development support
Power Modes (Ultra-low Power modes)
Off ; Hibernate (<1uA)
Power Down Sleep (flexible)
Package Type
40-pin QFN (BL616)
56-pin QFN (BL618)