Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in 
CSDb User Forums


Forums > C64 Coding > 6502 VM running on a 6502
2021-08-03 12:47
Krill

Registered: Apr 2002
Posts: 2023
6502 VM running on a 6502

I wonder what the slowdown for a highly-optimised 6502 VM running on a 6502 (or 6510) would be.

Considering Ultimate64 with its 48 MHz turbo mode, might it be generally possible to execute one guest cycle in 48 host cycles or fewer? =)

Guts feeling says yes, but i haven't yet dabbled with some actual code (on paper or otherwise).

I'm not much considering I/O (chip access, including interrupts) yet, thinking about the basic load/store/branch/arith instructions mostly, at this point.

Or maybe such a thing exists already, originally intended for SuperCPU or so? =)
 
... 5 posts hidden. Click here to view all posts....
 
2021-08-03 17:36
tlr

Registered: Sep 2003
Posts: 1480
Quoting Krill
Quoting tlr
If you aren't bothered by I/O, single stepping using an NMI timer to break after a single instruction is a common way. Typically used for single stepping purposes in monitors.
I was thinking more in the direction of a pedestrian fetch-sanitise-dispatch approach, as there must be some kind of sandboxing. VM core could restrict itself to not use X or Y registers, in order to minimise context-switch overhead.

With the timer approach you could do that too but let opcodes that are safe just run, e.g LDA #<imm> and so on. Just peek at what's about to run.
2021-08-03 17:47
Krill

Registered: Apr 2002
Posts: 2023
Quoting tlr
With the timer approach you could do that too but let opcodes that are safe just run, e.g LDA #<imm> and so on. Just peek at what's about to run.
Sure, but if the opcode needs to be analysed anyways, the two unconditional interrupt context switches are unnecessary for most of the cases.
Besides, is the periphery including CIAs and their timers sped up in turbo mode as well? I'd guess not, and then having an interrupt for each 1 MHz cycle is out of the question anyways.
2021-08-03 18:07
tlr

Registered: Sep 2003
Posts: 1480
Quoting Krill
Quoting tlr
With the timer approach you could do that too but let opcodes that are safe just run, e.g LDA #<imm> and so on. Just peek at what's about to run.
Sure, but if the opcode needs to be analysed anyways, the two unconditional interrupt context switches are unnecessary for most of the cases.

You could opt for scanning the code forward until an unsafe op is found. Then either use interrupt to break there or place an RTS there. The latter might interfere with self modifying stuff though.
Haven't done any research on how long safe op sequences you'll get but there should be some at least. The scanning should be reasonably fast.
Quoting Krill
Besides, is the periphery including CIAs and their timers sped up in turbo mode as well? I'd guess not, and then having an interrupt for each 1 MHz cycle is out of the question anyways.

Probably not, because that'd break things like running the screen editor.

Isn't the Ultimate64 open source like the 1541U2?
2021-08-03 20:04
Hoogo

Registered: Jun 2002
Posts: 94
Did something like that in '91 to create memory maps of used or addressed locations, also just for simple emulation without caring for IRQs and other hardware stuff. For that purpose, speed was somewhere between 1/17 and 1/65 with all the bitmapping to store the found results.

I don't remember the details, I think it was a table of 256 bytes to handle the special cases, and the general cases to handle commands of 1-3 bytes, their addressing modes, and restoring all registers. I'm pretty sure that this can be done faster.
2021-08-03 22:05
Groepaz

Registered: Dec 2001
Posts:
Quote:
Isn't the Ultimate64 open source

only the application software, not the core itself
2021-08-03 22:21
Krill

Registered: Apr 2002
Posts: 2023
Quoting tlr
You could opt for scanning the code forward until an unsafe op is found.
Scanning doesn't work so well with the requirement to execute an instruction in exactly the same time it would take on the original 1 MHz system, though. And it's rather likely that there are runs of many unsafe instructions, so nothing gained. In this regard, it's closer to an emulator than some JIT/dynamic recompilation kind of VM.

Quoting tlr
Isn't the Ultimate64 open source like the 1541U2?
What Groepaz said, but what are you insinuating? :)
Some answers to these questions could be found by testing, but i have no plans whatsoever to add/fix/change anything on the firmware. Just figured that U64 would be the best platform currently for something i'd like to see used. =)
2021-08-03 22:30
tlr

Registered: Sep 2003
Posts: 1480
Quoting Krill
Quoting tlr
Isn't the Ultimate64 open source like the 1541U2?
What Groepaz said, but what are you insinuating? :)
Some answers to these questions could be found by testing, but i have no plans whatsoever to add/fix/change anything on the firmware. Just figured that U64 would be the best platform currently for something i'd like to see used. =)

I'm implying implementing the hypervisor/sandboxing in the FPGA fabric instead of running it in 6502 assembly. This is probably more straight forward with no tricks required to keep timing. But with no source, not really feasible.

Doing it in 6502 asm sound like a fun project though. :)
2021-08-03 22:38
Krill

Registered: Apr 2002
Posts: 2023
Quoting tlr
Doing it in 6502 asm sound like a fun project though. :)
Yeah, but the limitations are obvious. Being able to run any original C-64 software would be a side-goal. :)
And with virtualisation in hardware, one could also have neat things like shifting processing slices between hypervisor and guest at (the hypervisor's) will, or having an overlay menu/monitor/editor running in the hypervisor.
2021-08-03 22:49
Oswald

Registered: Apr 2002
Posts: 4728
hmm and no one interested why ? I am :)
2021-08-14 01:03
Krill

Registered: Apr 2002
Posts: 2023
Quoting Oswald
hmm and no one interested why ? I am :)
Ok, time to revive this thread. =D

What i was getting at was some kind of "Byte Battle"-like setup, which in turn is a... vintage computing... variant of "Shader Showdown", but with some Lua-based fantasy console thing.

I think that something like that running on an U64 would be close enough to the original machine in order to defy the "fantasy console" label while still allowing for producing code able to run on the stock machine, in a very time-constrained live-coding show, but with a neat editor/compiler thingy running the code as it's typed.

(Note that whatever language/compiler setup on top of the VM is an open question, could be some beefed-up BASIC, could be some macro-enhanced 6502 assembly, or Turbo Rascal, maybe even Lua itself, whatever.)
Previous - 1 | 2 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Paladin/G★P
Stinsen/G★P
TheRyk/MYD
Mibri/ATL^MSL^PRX
hedning/G★P
macx
tNG/FairLight
Alakran_64
Krill/Plush
Edhellon/Resource
Mythus/Delysid
CreaMD/React
Core/VPN
Mr. SID
Rebok
Guests online: 74
Top Demos
1 Edge of Disgrace  (9.6)
2 Coma Light 13  (9.6)
3 Bromance  (9.6)
4 Uncensored  (9.6)
5 Memento Mori  (9.5)
6 Comaland 100%  (9.5)
7 Lunatico  (9.5)
8 Unboxed  (9.5)
9 Wonderland XII  (9.5)
10 Christmas Megademo  (9.5)
Top onefile Demos
1 Copper Booze  (9.7)
2 Daah, Those Acid Pil..  (9.5)
3 Dawnfall V1.1  (9.5)
4 Cityscape 2730  (9.5)
5 To Norah  (9.5)
6 Lovecats  (9.4)
7 Elite Code Mechanics  (9.4)
8 Barry Boomer - Trapp..  (9.4)
9 Quadrants  (9.4)
10 For Your Sprites Only  (9.4)
Top Groups
1 Booze Design  (9.4)
2 Oxyron  (9.3)
3 Censor Design  (9.3)
4 Crest  (9.3)
5 Triad  (9.3)
Top Graphicians
1 Mirage  (9.8)
2 Archmage  (9.7)
3 Mikael  (9.7)
4 Razorback  (9.7)
5 JonEgg  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2021
Page generated in: 0.056 sec.