[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emulator Project Question



> ==> It is my goal to translate 6502 instructions / opcodes into 80x86
> instructions / opcodes without using functions nor emulation BEFORE
written
> C++ is programmed to point 80x86 memory location before emulation can be
> executed.  It is how speed and preformance can increase!  Please state
your
> opinion what you think!

Ah - so what you're attempting to build is in fact an 6502->x86 translator.
One question, I guess, is whether you're doing this at runtime (ie
"just-in-time") in order to speed up emulation, or in advance, basically
translating a program in total then running it.

A couple of issues:

Translation generally works best if the source instruction set is very clear
about intent - Java JITs work because the Java bytecodes are very well
defined, are produced in recognizable patterns by compilers and generally
have few side effects. The 6502 with the memory-mapped hardware, as has been
mentioned, makes this very tough.

Having said that, translation in advance _is_ possible by mapping every 6502
instruction to an x86 functional equivalent code fragment, though that may
involve several instructions in order to get all of the flags correctly
handled.  Of course, then the inter-branch distances will be wrong, so
they'll have to change too.

>I can cause 80x86 instruction to load 'A' and store it into 80x86 memory
>location -- $007D:0100.  Written C++ is programmed to read $007D-0100 then
>calls some functions to load the screen resolution that will appear in the
>screen.  It will look like emulated 6502 memory location -- $500.  Does it
>make sense?

The trouble is, it's never quite that simple.  Screen memory is generally
not accessed with absolute addressing modes.

For instance, actual code would likely do something more like:

LDA #$00
STA SCRNBASELO
LDA #$04
STA SCRNBASEHI
...
LDX CURSORWITHINLINE
LDA #$AA
STA (SCRNBASELO),X

Now the problem is that you don't know that the #$04 has anything to do with
the screen base address as used by the indexed indirect intruction.  In
fact, the code may do multiple things with that 4 - a common technique in
tight memory situations, the most common being something like a BNE or BPL
that counts on the 4 not being a zero or negative.  Also that 4 could have
been created any number of ways other than an immediate load into the
accumulator, ie:

LDA VIDEOPAGE ; 0 or 1
CLC
ADC #$01 ; now 1 or 2
ASL
ASL ; now 4 or 8
STA SCRNBASEHI

Another example, tough to translate: the very common 6502-type jump table,
wherein we see the 6502 quirkiness about loading the return address-1 on the
stack in a JSR/RTS:

TABLE DW SUB1-1
 DW SUB2-2
...

LDA INDEX
ASL
TAX
LDA TABLE+1,X
PHA
LDA TABLE,X
PHA
RTS

The translator really has no idea that the table contains addresses, and
won't know the intent until the RTS instruction.

Advanced translators usually are taught common patterns of instructions
rather than individual ones, so simply looking up a 6502 instruction and
replacing it with a similar x86 instruction is not likely to work well.

Good luck with your project!