gameboy to intel x86 static binary translator jim clark david galos
Post on 17-Dec-2015
268 Views
Preview:
TRANSCRIPT
Gameboy to Intel x86 Static Binary Translator
Jim ClarkDavid Galos
The Nintendo Gameboy
• CPU – 8 bit Sharp LR35902 running at 4.19 MHz, custom for Gameboy but similar to Intel 8080 and Zilog Z80
• 8kB VRAM and 8kB working RAM
• Game code stored on changeable cartridges
To run this program on a different architecture………
• Emulation– Each CPU opcode
translated into a function which affects the “registers” in the same way
– CPU registers emulated using data structure in high level language
– Entire area of mapable memory stored in data structure in high level language
• Binary Translation– Each CPU opcode translated
from its original architecture to the targets equivalent
– CPU registers mapped directly from source to target
– Entire area of mapable memory stored in targets
Registers
An emulation approach…….
• Map each register into a variable in the high level language
Our binary translation approach…..
• Map each register from the source architecture into an equivalent in the target
Memory Access0000-3FFF ROM Bank 0
4000-7FFF Switchable ROM bank
8000-9FFF Video RAM
A000-BFFF External RAM
C000-CFFF Working RAM 0
D000-DFFF Working RAM 1
E000-FDFF Same as C000-DDFF
FE00-FE9F Sprite Atribute Table
FEA0-EEFF Not Usable
FF00-FF7F I/O Ports
FF80-FFFE High RAM
FFFF Interrupt Enable Register
An emulation approach…….
• Access memory through functions
Our binary translation approach…..• Setup the .data section in an x86 asm file• Address through labels
CPU Instructions
An emulation approach…….• Translate each opcode into a function
Our binary translation approach…..• Translate each opcode to its equivalent on
the target architectureADD A,E becomes
CP A,B becomes
NOP becomes
addb %cl, %ah
cmpb %bh, %ah
nop
Emulation within binary translation
• Need to account for peripherals• The generated .asm file assembled, then
linked with a high-level C program• Call the “fake_stuff” after each instruction,
then return• Nesecary to emulate the effects of the LCD
controller, button input, DMA etc.
How our translator works
• A program, written in C, generates an x86 asm file from the given Gameboy ROM file
• Object files are generated from this .asm file and the C program containing the “fake stuff”
• These files are linked, resulting in the output of a single Windows .exe file
Generating an x86 asm file
• Input is a Gameboy ROM file, a 32K binary• As this input file is simply a binary there is no
way to distinguish code from data• This was our first hurdle in the project
Code or Data?• Consider the following 3 bytes arbitrarily
pulled from Tetris:
Offset (h) 00 01 02 03 04 05 06 07 08 09 0A 0570 03 AF E0 81 21 E8 B0 EE F0 ED E0
• This could be:– A 1 byte instruction followed by 2 bytes of data– A 2 bye instruction followed by 1 byte of data– A 3 byte instruction– 1 byte of data, a 1 byte instruction, and another
byte of data……………
• If the series of data is interpreted as a 3 byte instruction, 21 corresponds to the instruction LD HL,d16 which loads immediate 16 bit data into register HL. Thus this instruction would load the value 0xB0E8 into register HL
• Another way this could be interpreted is if 21 were a byte of data followed by the 2 byte instruction E8 B0. This is also a valid opcode, and translates into ADD SP,r8.
Offset (h) 00 01 02 03 04 05 06 07 08 09 0A 0570 03 AF E0 81 21 E8 B0 EE F0 ED E0
• Further complicating things, this sequence could be interpreted as 2 bytes of data, 21 and E8, followed by the single byte instruction B0. B0 is a valid opcode as well, and translates into OR B.
• Finally, this may not even be code! It could simply be 3 bytes of data. As you can see, it is very difficult to distinguish code from data as they are intermixed throughout the ROM.
Offset (h) 00 01 02 03 04 05 06 07 08 09 0A 0570 03 AF E0 81 21 E8 B0 EE F0 ED E0
How we solve this problem
• When generating the .data section, treat each byte in the entire file as if it is data
.global _data0574_data0574:
.byte 0x21.global _data0575_data0574:
.byte 0xe8.global _data0576_data0574:
.byte 0xb0
Offset (h) 00 01 02 03 04 05 06 07 08 09 0A 0570 03 AF E0 81 21 E8 B0 EE F0 ED E0
How we solve the problem
• When generating the .code section, assume each byte is a complete instruction, but DON’T skip over the extra bytes we pulled in!
.global _code0574_code0574:
movb $0xb0e8,%dx_code0575:
addl $0x8838, %esiandl $0x0000ffff, %esi
_code0576:orb %bh, %ah
Offset (h) 00 01 02 03 04 05 06 07 08 09 0A 0570 03 AF E0 81 21 E8 B0 EE F0 ED E0
Why this works
• If we are writing to an address, we know it’s data, so we append an offset to _data0000
• If we are jumping to an address, we know it’s code, so we append an offset to _code0000
top related