Re: 65C02 emulation

[Charlie Springer <RAM@regnirps.com>]

On Thu, 30 Nov 2006 15:02:35 -0800, Bruce Tomlin wrote
(in article <bruce#fanboy.net-AC4EFA.17023530112006@news.newsreader.com>):

> It all depends on how you write the emulator and what kind of I/O you 
> need.  If you write it in assembly language, keep the 6502 registers in 
> ARM registers, and use a 256-entry table of two or four code longwords 
> each (you should be able to make a table that most instruction handlers 
> will fit in, and the rest can jump out), it could be a lot faster than 
> something written in plain C using switch statements.  I'm a little 
> rusty on what ARM can do, but the last instruction in each handler would 
> need to be an indexed jump with post-increment.  This general setup is 
> how I've heard Apple did their 68000 emulator on the PowerPC, only with 
> a 65536-entry jump table.

That is about it. I give myself space for 16 instructions in the table. Since 
a barrel shift can be added to nay ARM instruction with no time penalty 
(shifting is free), just read and shift the 6502 instruction (offset if 
needed ) and load it to the program counter.

> But it's the I/O support that'll slow you down.  It's one thing to have 
> an array of 65536 bytes for RAM and use it like an array, but once you 
> have to partition it with an I/O area, you constantly have to check 
> whether an address is memory or I/O.  Ditto for RAM vs ROM when writing 
> to memory.  And then there's video memory, which is both RAM and I/O at 
> the same time.  I suppose it would help to have a 65536-byte array of 
> what each address does, but there's still some performance loss between 
> a useful emulator and a "deep thought" emulator.

This is certainly true, and I have considered an ARM with a good hardware 
memory manager to unburden the processor. With an "ARM in a slot" approach I 
might even pass floppy and video I/O to the mother board processor (as well 
as adding SVGA output to the ARM board).

> In the case of Apple's 68K emulator, this was not necessary because it 
> used the same address space as the real machine.  I suppose if you 
> hooked up an ARM with both RAM and real (not emulated) I/O mapped 
> properly into the 6502's address space (maybe using the MMU), then you 
> also wouldn't need to differentiate between RAM vs I/O.  You would also 
> have to take the ARM's 32-bit data bus into consideration.

Part of the ARM legacy as a design replacement for the 6502 in the BBC 
computer is that all data instructions have byte addressing versions and a 
status register that looks very '6502'.

> I would guess the absolute minimum would be about 2-6 ARM instructions 
> per 6502 instruction.

That is the range I get depending on the instruction. There is a two or three 
cycle overhead to read an instruction or continue interpretation and a bunch 
of 6502 instructions that can be done in one or two cycles. So when you look 
at a mix of 6502 instructions with a minimum of 2 cycles and a max of 7 (?) 
you get close to a cycle to cycle match.

Dang. I have to finish this!

-- Charlie Springer