codeslinger.co.

uk
H o mB e a s Zi u c k sM o e g a D r M i a v e s /t G e re n S e y s Cs i ht s ie Bpm l 8 o Gamebo y g

codeslinger.co.uk
Gamebo y - Getting Started.

Type definitions:
Like all machines the gamebo y uses data types o f different sizes, mainly bytes (8 bits) and wo rds (16 bits). The z8 0 -like instructio n set also uses signed bytes and signed wo rds. So to make understanding o f the co de easier I have typedef'd these to give the fo llo wing:

Gameboy Emulation:
Getting Started The Hardware Memory Control and Map ROM and RAM Banking The Timers Interupts LCD DMA Transfer Graphic Emulation Joypad Emulation Opcode Examples PDFmyURL.com

typedef typedef typedef typedef

unsigned char BYTE ; char SIGNED_BYTE ; unsigned short WORD ; signed short SIGNED_WORD ;

I highly reco mmend yo u do the same as it makes understanding what value range a variable can sto re easier to understand and to track do wn any o verflo w erro rs.

Loading In The Game:

The maximum size o f a gamebo y ro m is 0 x20 0 0 0 0 bytes so if we have an array o f this size then this is where we can sto re the game. This array will represent the gamebo y cartride. As yo u will read in the sectio n called "Memo ry Co ntro l and Map" the internal gamebo y memo ry o nly sto res the first 0 x8 0 0 0 bytes o f the cartride in memo ry and the rest is left in the cartridge (the emulato r will have to swap data in

bytes o f the cartride in memo ry and the rest is left in the cartridge (the emulato r will have to swap data in and o ut the cartride to memo ry as needed) Declaratio n o f cartridge memo ry:

Finished Product

BYTE m_CartridgeMemory[0x200000] ;

Lo ading a game into cartridge memo y: memset(m_CartridgeMemory,0,sizeof(m_CartridgeMemory)) ; FILE *in; in = fopen( "Tetris.gb", "rb" ); fread(m_CartridgeMemory, 1, 0x200000, in); fclose(in);

The Emulation Loop:

Unlike the chip8 the gamebo y timing is well do cumented and it is crucial that the speed o f the gamebo y is emulated co rrectly. The gamebo y do cument that I'm ho sting gives the timing in clo ck cycles fo r each o pco de. So if we kno w ho w many clo ck cycles each instructio n takes o n the o riginal gamebo y hardware we can add this to a running co unter to keep track o f timing. One o f the main benefits in keeping a track o f ho w lo ng each instructio n takes is we can synchro nize this with the graphic emulatio n and the gamebo y clo ck timers to emulate these at the same rate as the cpu. I use SDL fo r my graphic emulatio n and this co mes with functio nality to limit the frame rate o f the emulato r. I have cho sen to limit the frame rate to 6 0 frames per seco nd, the reaso n fo r this is the gamebo y refreshes the screen 6 0 times a seco nd. Acco rding to game pan do cs site the amo unt o f clo ck cycles the gamebo y can exectue every seco nd is 419 430 4 which means that if each frame we update the emulato r 6 0 times a seco nd the each frame will execute 6 9 9 0 5(419 430 4/6 0 ) clo ck cycles. This will ensure the emulato r is run at the co rrect speed.

void Emulator::Update( ) { const int MAXCYCLES = 69905 ; int cyclesThisUpdate = 0 ;

PDFmyURL.com

while (cyclesThisUpdate < MAXCYCLES) { int cycles = ExecuteNextOpcode( ) ; cyclesThisUpdate+=cycles ; UpdateTimers(cycles) ; UpdateGraphics(cycles) ; DoInterupts( ) ; } RenderScreen( ) ; }

So if the abo ve functio n is called 6 0 times a seco nd then RenderScreen is also called 6 0 times a seco nd which is the same as the gamebo y. The while lo o p ensures that the co rrect amo unt o f instructio ns is being executed this frame (assuming o f co urse that the functio n ExecuteNextOpco de is returning the co rrect clo ck cycles the next o pco de to o k to execute). Also the timers and graphics are being passed ho w many clo ck cycles the o pco de to o k so they can update at the same rate as the cpu. After every instructio n the interupts need to be checked and if needed then pro cessed.

Copyright 2008 codeslinger.co.uk

PDFmyURL.com