Archived

This topic is now archived and is closed to further replies.

Matthew123

GB emulator

Recommended Posts

I am attemping to write a gameboy emulator, but I''m not sure how to go about coding it. I''ve searched and found plenty of spec sheets but no tutorials. Can anyone recommend some guidelines or know of some tutorials. Thanks

Share this post


Link to post
Share on other sites
I''d suggest if you don''t know how to go about coding it, learn to be a better programmer than trying to go about doing something that is out of your league. I know this is harsh, but there is a reason why people don''t write up tutorials on how to go about programming emulators.

Well, here is a much simplified explanation on coding a GBA emulator.

Take the spec sheet that you have. Learn all the registers, op codes, etc, and have a program which can disassemble the game.

Once you have a GBA disassembler, translate those instructions to whatever language you want.

Next, write your own BIOS handler to execute all the instructions requiring the BIOS calls (graphics, sound, etc).

That''s pretty much all there is too it.

Share this post


Link to post
Share on other sites
Ok Nytegard, perhaps you could tell me what I should learn to become a better programmer. Then this wouldn't be out of my league. I'm not looking for step by step tutorials, more like guidelines to get me started in the right direction. By the way
I want to write a emulator for the gameboy classic/color not the game boy advance. Seems to me it might be quite abit harder to write a emulator for the 32 bit RISC processor in the GBA compared to the 8 bit Z80 in the gameboy classic/color. Thanks for your advice anyway.

[edited by - Matthew123 on January 16, 2004 1:08:03 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Write a Chip8 emulator first (way easier, should take you an afternoon), using the guide on www.goldroad.co.uk.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
The GB/GBC cpu isn''t really a Z80, but a very similar cpu based on it. it lacks some features (such as the shadow regs), but has some new instructions.

Share this post


Link to post
Share on other sites
I'm pretty sure that I wrote a post on developing emulators way back, but it's been lost in the annals of time it appears.

For 8 and 16 bit systems the process is relatively simple, just requiring a lot of repititive work defining opcodes, making sure the timings are correct, etc. But you don't have to handle any advanced CPU features as well, and the DMA is usually quite limited so it's a good tradeoff.

The GB has a few major subsystems that will end up being components of your emulator:

1. CPU - the heart of the system, usually emulated with a state machine based representation, storing the registers is usually trivial, just stick them in a struct or array.

A typical execution loop would look something like this:

op = getmem8(instructionpointer++);
switch(op) {
case INC:
int regtarget = getmem8(insructionpointer++);
regs[regtarget]++;
break;
case ...
}

The CPU also controls most of the data flow through the system. You can see the getmem8() instruction up there which is essentially the interface between the CPU and the memory subsystem, which leads us to...

2. Memory subsystem - Memory was usually represented as a flat address space, and when you write to a certain address you modify some hardware registers (not CPU registers) that control various GB subsystems.

So your getmem and setmem functions have to handle these registers, which will look something like this:

void setmem8(u32 address,u8 data) {
if (address >= 0xf000 && address <= 0xffff) {
membank[address-0xf000] = data;
} else if (address >= 0x3cf0 && address <= 0x3fff) {
u32 reg = address - 0x3cf0;
if (reg == 0xa) {
// Video mode register, so set
// the emulator state to handle that register
}
}
}

Where here the range 0xf000-0xffff is defined as the system ram (in my toy example) and 0x3cf0-0x3fff is the hardware register area.

Essentially you have to map the GB memory space into something that your program can understand. Now the interesting parts of the GB are it's video and sound subsystems, but I won't cover those in too much detail as that's something that's relatively self explanatory.

3. Video - As with most older console systems, the GB uses a 8x8 tile based map storage system, with 1-bit tiles on GB and 4-bit (I think... been a while) on the GBC. Essentially the user sets up a 16x16 tile map which ends up being a 128x128 pixel map that the user actually sees. One nifty part about the way things are done is the scanline rendering concept. Essentially the system draws from top to bottom in a left to right fashion, stopping at the end of each scanline for a little rest. This allows all those neat mode7 style tricks to occur when the users modify scaling/translation values on the horizontal blank (which is what it's called).

But that's a bit more detail that I meant to go into. Essentially the GB executes a certain amount of cycles per vertical blank (the pause at the bottom of the screen), and you should try to make this as close to hardware as possible as games *will* depend on the timing to get their effects correct.

4. Sound - One of the most intersting parts of a GB emulator, the sound is generated as 4 different types of waveforms. Two triagle wave generators, one square wave and one 32 sample wavebank generator. If you've taken a DSP class you'll be far too familiar with these . But this is usually a last step, for now just handle writes and reads from the registers with grace, it'll be easy to tack it on at a later stage.

Now all you need to do is glue all this stuff together and you'll be good to go! Good luck, writing emulators is both challenging and extremely rewarding. When you get your first program to boot up life will be good.

[Edit: gah, smiley overload]

[edited by - premandrake on January 23, 2004 2:45:16 AM]

Share this post


Link to post
Share on other sites