Six Five Risk FiveI have been looking at this lately as part of my browsing.
I searched the board, however, the search function here omitted V from RISC-V after many uses of "" etc.
I did find a thread on C compilers for 65816, and while a freestanding implementation of C is intended for the Oxide OS;
I did not want to derail that thread, so I copied several peoples responses and cut them down to the relevant bits.
I would propose, if I understand this correctly, a RISC-V implementation with a 'user extension', that is
operationally compatible with the 6502, 65816 and ideally, the never released 65832, or versions for each thereof.
I would restrict any other extensions to RISC-V at this level as a package much like the existing nomenclature.
So, you could use the RISC-V to natively run 65xx code, or you would have a 65xx 'core', with a RISC-V extension coprocessor, with all of its features, I/O and codebase available to you. On my end, this is in line with the 65xx core, and every other chip in the system is a coprocessor mentality.
Pragmatically, this would bridge 65xx code and hardware to the modern era, and vice-versa, allowing plugin modules to replace failing chips and hold new RISC-V operations for watchdogs, maintenance and reporting that could run fairly undisturbed alongside the native 65xx legacy code. Educational use is fairly straightforward and allows learning one or the other first.
Im not certain how viable this is, though it is certainly feasible. Plenty of v65xx cores are out there already. pairing one to a RISC-V under the user extension clause is straightforward.
I just thought Id start the conversation.
For one, I think there are a couple of configurations here, one is to limit the RISC-V extensions and use the 65xx Status and Stack etc.
So, starting from the 65xx, adding in the Base (Integer 32), M (32 Multiply and Divide) and F (single floating point) and D gives the 65xx a bit more oomph, and adding the A and Z__ modules would create a more multiprocessing friendly wrapper around the 65xx
This would basically be 65RISC-V+G
other variations might exist with various extensions to 65xx
I would like to limit this discussion to only RISC- V and the existing 65xx Cores/Architectures and avoid any conflagration or confounding statements with other hypothetical 65xx chips or models. For out purposes, the 32-bit 65832, and if someone has a list of the 32bit 65xx core projects out there, we could look at those too.
This is not a discussion of a 'best 65xx chip'; it is a discussion of a 65xx extension module for the RISC-V platform for bridge technology, legacy hardware and code support and education to keep the 65xx ASM language and codebase alive.
BigEd wrote:
There are a few (somewhat) relevant threads on this forum and over on anycpu, which I just wanted to signpost - it might or might not be helpful to the way you'd like to proceed!
The 65816 as the basis for a virtual 16 bit CPU ("65V16")Announce: Acheron VM "Virtual 16-bit CPU for 6502 computers"
rj16 - a homebrew 16-bit cpu "there's a LCC machine description file, so it has a C compiler"
Building compiler and porting an OS to a new CPU "four months of building a home-built CPU of a home-built RISC ISA, building a home-built C toolchain, and porting Xv6, a Unix-like OS, to that CPU"
xr16 - a tiny RISC, with CPU design tutorial and SoC design by Jan Gray, CPU specifically constructed for ease of writing a C compiler
Big list of CPUs suitable for bootstrapping includes a link to the stage0 project with the Knight architecture
thank you, this is a great list of resources to get started.
sark02 wrote:
Technology companies around the world are building their own RISC-V cores for their own products, building and selling RISC-V IP for others, supporting open source software, compilers, languages. Companies like AMD and NVIDIA aren't doing this because they've bought into hype. RISC-V cores are uplifing from smaller cores, and/or replacing more expensively licensed cores, while providing 32-bit/64-bit ISAs with first-class compiler support, and first-class open source OS support.
...
That said, this is a somewhat "stuck in the past" site, and we all have a soft spot for the 6502...
a still widely used design in one form or another.
Id like to point out again that the ST Micro ST7 (and later the ST8) are remarkably similar to the 6502
https://en.wikipedia.org/wiki/ST6_and_ST7drogon wrote:
BCPL is a high level "algol-like" language that was designed round about 1966. ... ... The editor is written in BCPL, the compiler in BCPL and my operating system - it's a single-user multi-tasking OS written in ... BCPL.
The bytecode VM/interpreter - it's written in 65816 assembly language. It's some 16,000 bytes of hand-written '816 assembly language, supported by macros.
The bytecode VM requires a machine operating system to provide it with boring stuff like IO, serial, disk, etc. and this is written in about 10KB of hand-written (mostly) 65C02 code, supported by macros.
This exists today. I don't need to write it - I've written it. It work, and runs. It runs OK, but as it's a 32-bit VM running on a 16 bit CPU with an 8-bit memory interface it's not going to win awards for speed.
Today there are NO C compilers that I can take and use directly on a "retro-new" 65C816 system.
There are C compilers that were developed in the past and ran on such systems - Aztec C on the Apple II, there is a C compiler for the Apple IIgs and a variant of TinyC for the BBC Micro, but to my knowledge there is no other C compiler that I can run directly on a 65xx system - or not one I could get the source code for to adapt for my own system. Someone please prove me wrong!
...
And I am looking at moving to RISC-V in the same way DEC moved to VAX, Apple moved to the 68K and Acorn moved to ARM - because - bigger, better, faster. Actually, I want sustainability too.
RISC-V is not new. It can trace its origins back to the early 1980s in Berkley and one of the first commercial applications was the Sun Sparc processor. (Which I also wrote a lot of code for - another "joy" CPU to code for).
To get to grips with modern RISC-V, I wrote an emulator for it - in BCPL. It runs at approximately 2000 RV instructions/second - not bad for 32-bit VM interpreted on a 16-bit CPU with an 8-bit memory interface at 16Mhz. It runs well enough to bootstrap my entire BCPL operating system inside itself. I'll do a video of that one day. It's turtles all the way down, as they say.
......
Maybe also have a look at the history of the early Prime minicomputers - they were originally 16-bit and lacked byte addressing. It was a long time before they got a C compiler and eventually Unix, but like many, too little too late by then.
And don't worry about BCPL being 32-bit. It can be 16,32 or 64 but the ability to do multi-byte arithmetic is what enables us to handle larger data values than the underlying hardware supports. BBC Basic has 32-bit integers on the 8-bit 6502, so dealing with 32-bit values on the 16 bit '816 is trivial.
-Gordon
you are a dedicated genius to have done such a thing.
Oxide intends to have a freestanding C implementation if possible. What you have done is proof of concept of a lot of things.
that you have used the 65xx and "dabbled" in the RISC-V to such extent infers you could offer a lot of insight on a 65xx extension to RISC-V. While this might not be 'the chip you would run to', I think you might see the merits of such a device, either from exposing a lot of the RISC-V I/O and functions to the 65xx chip, or the other way, of running old code for the 65xx on a modern CPU.
_______________________________________________________________________________________________
I personally will be working with 65xx physical chips for awhile, I did however want to start this discussion and get this out there as at least a placeholder.
RISC-V+65xx