6502.org

So I've got this device which is an 8MHz 65c02, with fast storage, but only 2kB of RAM. That's not enough to do anything useful. What if I could virtualise a 6502 on top of the 6502 in order to demand-page storage?

It doesn't actually sound too hard. There's no memory manager, of course, so this is going to be an emulator rather than real virtualisation, but there are lots of shortcuts I can take. Register-only operations can be done by copying the instruction and executing it in isolation. Flags etc are all dealt with automatically. Memory operations are harder. I'd need to compute the effective address myself and dereference it in software, in order to load/save the required block of virtual memory. I could speed things up by permanently mapping pages 0 and 1 in my limited storage, which means any zero-page or stack instruction (except (zp),y or (zp,x)) would need simplified handling.

This all sounds pleasantly pointless (if hopelessly slow).

But before I start playing with code, this sounds like exactly the kind of thing that a good debugger would need to do in order to single-step through code (minus the virtual memory stuff, of course). Does anyone know if anything like this already exists? I'm sure there's some super-optimised code somewhere which takes an opcode and spits out the addressing mode, somewhere. (I found this very nice code snippet for finding the length of an instruction, which is very nearly what I'd need: https://csdb.dk/forums/?roomid=11&topicid=162839)

Maybe look at the Apple II Monitor 2 (ie. not Wozmon, but what's in the Apple II with the Integer Basic ROMs).

It can single step and 'run' machine code and does so by copying the instruction (& operand), loading the registers with the saved register values, JMPing to the saved location - which has a JMP back again which then saves the registers, lather, rinse, repeat ...

Although I'm not sure how it handles JMP instructions, but I'm sure the code is in there if you look...

-Gordon

Source is at https://apple2history.org/dl/Apple_II_Redbook.pdf (page 81, which is page 89 of the PDF), but I'm not sure how helpful it would be.

It simulates most instructions by copying them to a buffer and executing them. BRK, JSR, JMP, JMP indirect, RTS, and RTI all have special-case handlers. If the instruction is a branch, its operand is replaced with 4 (the value that happens to be in A after the detection) and there's code at the appropriate point in the buffer to handle a taken branch. So most instructions are going to access the memory they'd normally access.

Without thinking about it much, the best I can think of is to decode the addressing mode, find the effective address yourself, copy that memory to a proxy in zero page, copy the instruction to RAM, set its operand to point to the proxy (and setting any index registers its addressing mode uses to zero), executing it, then copying the proxy back to memory. It's a lot more work than the Apple II is doing, but it doesn't go as far as completely simulating every instruction. It will be slow.

One of the more interesting stupid Friday discussions we've had around here lately! Emulating 6502 on 6502 is a novel challenge!

In case anyone missed hjalfi's post on Sunday, it's pretty clear that the intended platform is the miniature games console (!) mentioned in the post and examined in the linked video here.

-- Jeff

https://github.com/classilla/6o6/

(my work)

It passes Klaus' tests and has sample applications. I used it for my KIM-1 emulator.

That's splendid - I'm sorry to say I'd forgotten it.
Previous thread:
6o6: virtualizing the 6502 on a 6502

(It's not the first thing I've forgotten that was barely a year ago.)

That looks ideal. But I'm not sure I can use it out-of-the-box; the big per-opcode jump table would occupy 512 bytes of my ~1280 bytes of RAM, and I still need to allocate some buffers for virtual memory etc. I'll need to experiment to see if it'll fit. But it'll certainly make a good place to start; thanks very much!

Yes, it can get a bit big, especially with fetch macros (which you really want because otherwise every memory access becomes a jsr to the harness). I have a 16K block allocated to it in the Incredible KIMplement which has all the bells and whistles turned on. However, it's complete and functional, and because memory access is abstracted you can put the guest memory range anywhere you want (since it's your harness that does the work). I'm still pondering ways to reduce the overhead of the memory access harness further, since there isn't much more fat to cut in instruction dispatch or execution.

I once wrote a BASIC interpreter in BASIC....

I once write in PASCAL compiler compiling PASCAL into PASCAL

I did once compile C into Perl. It was just as laughable as you might imagine. C into Java worked rather better (at 30% of native!), but sadly C99 changed the semantics a bit so that you can't do that any more...

Maybe some sort of JIT-style re-compiler could pick out sections of code, reform them, and execute them directly? But probably not in 2k..

Didnt some of the little key ring photo viewers use a 65c02 similar to this? some guy reverse engineered one some time back.

Another thing to look at - this 8080 emulator for the kim 1. It should fit in 2k. Then you could run CPM80!

https://www.pagetable.com/?p=824

it wont be fast, but prob not much slower than emulating a 6502.