Re: 65C02 emulation

[Bruce Tomlin <bruce#fanboy.net@127.0.0.1>]

In article <0001HW.C190DC7500048FA8F04075B0@news.nw.centurytel.net>,
 Charlie Springer <RAM@regnirps.com> wrote:

> On Mon, 27 Nov 2006 16:17:00 -0800, Mark McDougall wrote
> (in article <456b7f96$0$24736$5a62ac22@per-qv1-newsreader-01.iinet.net.au>):
> 
> > What you're perhaps forgetting is that 'various emulators' do a lot more
> > than simply emulate the 6502 processor - they emulate the rest of the
> > apple hardware (including every memory access) and also render graphics
> > on the PC display. No doubt you could run a 6502 emulation on a 3.4GHz
> > wintel box at some blazing speed too...
> 
> Hi Mark. I really am looking for numbers on straight 65C02 emulation, not 
> Apple IIe emulation. I just need a benchmark to measure my own work against. 

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.

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.

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.

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