6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Wed Nov 13, 2024 6:49 am

All times are UTC




Post new topic Reply to topic  [ 12 posts ] 
Author Message
 Post subject: 65RISC-V
PostPosted: Mon May 01, 2023 7:31 pm 
Offline

Joined: Sun Mar 19, 2023 2:04 pm
Posts: 137
Location: about an hour outside of Springfield
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.

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_ST7

drogon 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


Last edited by wayfarer on Thu May 04, 2023 7:09 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject: Re: 65RISC-V
PostPosted: Wed May 03, 2023 6:35 pm 
Offline
User avatar

Joined: Fri Aug 03, 2018 8:52 am
Posts: 746
Location: Germany
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


Top
 Profile  
Reply with quote  
 Post subject: Re: 65RISC-V
PostPosted: Wed May 03, 2023 7:36 pm 
Offline

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 962
Location: Potsdam, DE
Sounds awfully transputerish, no?


Top
 Profile  
Reply with quote  
 Post subject: Re: 65RISC-V
PostPosted: Wed May 03, 2023 7:39 pm 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1485
Location: Scotland
barnacle wrote:
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/


Top
 Profile  
Reply with quote  
 Post subject: Re: 65RISC-V
PostPosted: Wed May 03, 2023 7:50 pm 
Offline

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 962
Location: Potsdam, DE
You're right. It's late... :mrgreen:

Neil


Top
 Profile  
Reply with quote  
 Post subject: Re: 65RISC-V
PostPosted: Thu May 04, 2023 7:03 pm 
Offline

Joined: Sun Mar 19, 2023 2:04 pm
Posts: 137
Location: about an hour outside of Springfield
Proxy wrote:
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.


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.

Quote:
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


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.


Top
 Profile  
Reply with quote  
 Post subject: Re: 65RISC-V
PostPosted: Thu May 04, 2023 7:08 pm 
Offline

Joined: Sun Mar 19, 2023 2:04 pm
Posts: 137
Location: about an hour outside of Springfield
barnacle wrote:
Sounds awfully transputerish, no?


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.


Top
 Profile  
Reply with quote  
 Post subject: Re: 65RISC-V
PostPosted: Fri May 05, 2023 6:42 am 
Offline

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 962
Location: Potsdam, DE
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


Top
 Profile  
Reply with quote  
 Post subject: Re: 65RISC-V
PostPosted: Fri May 05, 2023 7:42 am 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1485
Location: Scotland
barnacle wrote:
(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/


Top
 Profile  
Reply with quote  
 Post subject: Re: 65RISC-V
PostPosted: Fri May 05, 2023 8:27 am 
Offline

Joined: Thu Mar 03, 2011 5:56 pm
Posts: 284
drogon wrote:
barnacle wrote:
(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


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

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


Top
 Profile  
Reply with quote  
 Post subject: Re: 65RISC-V
PostPosted: Fri May 05, 2023 4:57 pm 
Offline

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 962
Location: Potsdam, DE
Two interesting projects, thanks. One of these days I'm going to have to investigate programmable logic...

Neil


Top
 Profile  
Reply with quote  
 Post subject: Re: 65RISC-V
PostPosted: Sun May 07, 2023 2:28 am 
Offline

Joined: Mon Sep 17, 2018 2:39 am
Posts: 138
Hi!

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

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

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!


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 28 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: