Six Five Risk Five

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



thank you, this is a great list of resources to get started.





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_ST7


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

hmm, a RISC-V extension that can run native 65xx binaries sounds to me like modern x86 CPUs, as they effectively just convert x86 instructions into small sequences of RISC instructions which are then executed by the actual hardware.

so in theory you could use a similar idea here.
have a translation layer that reads in 65xx instructions (and their operands), converts them into a set of RISC-V instructions, and throws those into a circular buffer for the RISC-V core to access. while the RISC-V core is executing instructions, the translation layer will try to keep the buffer filled. if it runs dry the CPU is temporarily stopped until it has some minimum amount of instructions in it again.

this would probably work and allow you to use some high speed pipelined RISC-V core. but i can't imagine that performance would be that great as RISC-V is not optimized to deal with 65xx instructions... but then again, part of the 65xx extension could include custom instructions to directly generate status flags and other things that would be difficult to emulate in software.

the other idea of a RISC-V with a seperate 65xx core as co-processor that it can control and call at will (through custom instructions) to run some piece of code somewhere in memory seems like a good alternative.

also, personally i wouldn't bother with 65832 compatibility, as it's just a 65816 with 32-bit registers and no other redeeming qualities or software that made use of it.

anyways i'd be interested to see how you would design a system around a concept like this

Sounds awfully transputerish, no?

No. I suspect you might be thinking Transmeta, not Transputer...

-Gordon

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

You're right. It's late...

Neil

so this is a notion, one form of 65RISC-V, and not quite what I was after, in one form or another, having a RISC-V extension, that can run 65xx Machine Code, either through a translation layer or hardware emulator is an option, and maybe a form we could take, though not really what Im after. this is like, the 'alternate mode' rather than the Primary Function.



so in RISC-V, you have like, 'Standard Extension' and 'User Extensions'. the Standard ones have all kinds of neat stuff, the base core layer, which is 32 or 64 (or 128!) bit.and a bunch of modules like 'Atomic' that is supposed to help with multiprocessor or multi-core designs. and Math routines for floating point multiplication and division. A chip can use any or few of these Extensions as desired,
User Extensions, are just that, user added circuitry that works with the RISC-V core and such.

So, a "65RISC-V" is a RISC-V chip, with a 65xx virtual core added on as a RISC-V extension, and would then have physical 65xx circuitry like any other vCore.

As RISC-V is 32 bit native, the actual 65832 32 bit wide 65816 type design, actually kinda makes sense. There are other 32 bit 65xx v-cores that could be used. Natively running 6502 or 65816 code on a 'computer' that exists in a SoC design seems like 'old-hat' at this point. 65RISC-V is just doing so with the context of the RISC-V extension space.

I would think you could use the Atomix extension and the 65xx Extension, and create a fairly efficient multiprocessor/multicore 65xx system.

The primary function, would be 65xx code, that is in a v-core, and next to it is the RISC-V instruction and feature set as 'on-die' copricessing to that 65xx core, allowing continued use of 65xx code, with the RISC-V there and used minimally to implement the 65xx core to the programmer <-> outside world, or as much as desired to leverage the RISC-V ISA.

not really this, I guess you could do things that way, Im more thinking:

65xx v-core as a RISC-V extension, and you code for the 65xx, and use the RISC-V extensions through that interface, the RISC-V, is running the 65xx as the 'cpu' and everything it does, is more like a coprocessor or other interface.

the 65xx 'extension', is really a 65xx v-core, and the RISC-V part, facilitates this v-core to interact with everything. to the programmer, its just a 65xx, with RISC-V functions.

Ah that makes sense.

I find myself thinking from time to time about various processor topologies, but so rarely have an actual application to run on them.

I'd like to see a 6502 SoC along the lines of, say, the STM32L07 series: low power, single chip with 64k ram and 64k flash, divisible either in software or at programming time, with all the timers and uarts and suchlike and shed-loads of I/O and a similar programming/debugging interface.

(Actually, I'd probably include a video output of some description, too... but maybe that's just me.)

Neil

Sort of done:

https://www.mike-stirling.com/retro-fpg ... nt-page-1/

-Gordon

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

Also this: https://github.com/dmsc/my6502

--- from a member of 6502.org, I think.

Two interesting projects, thanks. One of these days I'm going to have to investigate programmable logic...

Neil

Hi!


Yes, thanks for bringing it up, if you need advice on how to modify it, just ask.

I planed to port FastBasic to the my6502 computer, but got sidetracked on other projects

Have Fun!