Game Boy
- Thread starter -//zAe\\-
- Start date
aprentice
Moderator
decided to release my gameboy emus source so people could learn off it and maybe even help me track down bugs or hell even fix sound 
i havent touched it in ages so theres some incomplete features but emulation wise its 99.9% complete, minus sound and 1 priority mode that ive never seen a game use yet..
contructive opinions on source welcome
i havent touched it in ages so theres some incomplete features but emulation wise its 99.9% complete, minus sound and 1 priority mode that ive never seen a game use yet..
contructive opinions on source welcome
As this thread seems a bit too quiet, I'll post about my emulator
A few years ago, I coded a little (and VERY incomplete) cpu core, that didn't even run the simplest PD roms. Not to mention that it was totally lacking any LCD emulation.
As I always wanted to get some commercial roms to work, and as a break from bigger (and more complex) projects, I decided to give it another go 3 weeks ago. As all the code was done for MS-Dos, first I had to do a proper GUI. After getting a tile viewer and a dissasembler in the app, I started trying to get the Distortion rom to run. I noticed my cpu core was rather bad written, as it had about 6 years, so I rewrote about the 90% of it, and started emulating the display and all the rest.
It took me two full days without any sleep (aren't holydays nice?) to get it working properly, but it had some rather ugly timing and cpu bugs. The next week, I got the few other PD roms that were in my HD to work, and after a lot of debugging, got all them running nicely. Then, commercial games were the next target.
So I've spent the other 2 weeks fixing all the cpu/timing bugs that I could find, implementing mbc1 and mbc2, a memory and dissasembler dumper, and getting the dissasembler to a more usable state.
So, right now, I've about a 95% compatibility with the "Rom Only" games, and a less (maybe 70-80%, or less, I really hate testing hundreds of roms) for the mbcs, but I'm getting there.
As for speed, I get about 390-410 fps for the more cpu demanding games, running in a p4 2ghz with small cache (notebook computer), but I plan to get it to run faster when I spend some time profiling, as for now I've only applied common sense. The current bottleneck seems to be in the cpu core, as some early and hacky tests showed.
Nothing else, already wrote a lot, just two screenshots
Bye!
A few years ago, I coded a little (and VERY incomplete) cpu core, that didn't even run the simplest PD roms. Not to mention that it was totally lacking any LCD emulation.
As I always wanted to get some commercial roms to work, and as a break from bigger (and more complex) projects, I decided to give it another go 3 weeks ago. As all the code was done for MS-Dos, first I had to do a proper GUI. After getting a tile viewer and a dissasembler in the app, I started trying to get the Distortion rom to run. I noticed my cpu core was rather bad written, as it had about 6 years, so I rewrote about the 90% of it, and started emulating the display and all the rest.
It took me two full days without any sleep (aren't holydays nice?) to get it working properly, but it had some rather ugly timing and cpu bugs. The next week, I got the few other PD roms that were in my HD to work, and after a lot of debugging, got all them running nicely. Then, commercial games were the next target.
So I've spent the other 2 weeks fixing all the cpu/timing bugs that I could find, implementing mbc1 and mbc2, a memory and dissasembler dumper, and getting the dissasembler to a more usable state.
So, right now, I've about a 95% compatibility with the "Rom Only" games, and a less (maybe 70-80%, or less, I really hate testing hundreds of roms) for the mbcs, but I'm getting there.
As for speed, I get about 390-410 fps for the more cpu demanding games, running in a p4 2ghz with small cache (notebook computer
), but I plan to get it to run faster when I spend some time profiling, as for now I've only applied common sense. The current bottleneck seems to be in the cpu core, as some early and hacky tests showed.Nothing else, already wrote a lot, just two screenshots
Bye!
ShizZy
Emulator Developer
Nice job, really great to see others working on gb emus. Mine isn't dead, but I've been focusing all my programming time (what little I have) on some bigger more interesting projects.
Need to clean mine up a bit more, add some more options, and fix some very slight bugs and I think it'll be release ready.
Need to clean mine up a bit more, add some more options, and fix some very slight bugs and I think it'll be release ready.
Garstyciuks
New member
Ok, I have just started making my 1337 GB emulator. I am using gb.pdf posted somewhere around 2-4 page of this thread for information about GB. I have got a question about the load instruction at page 65. Here is the description of it:
LD nn,n; nn = B, C, D, E, H, L, BC, DE, HL, SP
load nn into n
n = 8bit immediate value
cycles = 8
LD B,n 06
LD C,n 0E
LD D,n 16
LD E,n 1E
LD H,n 26
LD L,n 2E
How should I get the value of n? Is it in pc+1 (the byte after this instruction)? And shouldn't it be put n into nn, not opposite? Since all the other load instructions put the second parameter into first one.
LD nn,n; nn = B, C, D, E, H, L, BC, DE, HL, SP
load nn into n
n = 8bit immediate value
cycles = 8
LD B,n 06
LD C,n 0E
LD D,n 16
LD E,n 1E
LD H,n 26
LD L,n 2E
How should I get the value of n? Is it in pc+1 (the byte after this instruction)? And shouldn't it be put n into nn, not opposite? Since all the other load instructions put the second parameter into first one.
Last edited:
Garstyciuks
New member
Another question: How to emulate ADC A,n instruction? Its description is Add n + carry flag to A. As I understand this, it should add n to A and if carry flag is 1, add 1 to A?
For the intructions like:
LD R, N (where R is a 8 bit register, and N is a 8 bit value)
The value is actually something alike to rom[pc+1].
For the ADC R, N it is like you told, so:
R += N+carry
Where carry is a boolean value, so either 1 or 0. I'll elaborate more if you need to, but right now I'm very tired
LD R, N (where R is a 8 bit register, and N is a 8 bit value)
The value is actually something alike to rom[pc+1].
For the ADC R, N it is like you told, so:
R += N+carry
Where carry is a boolean value, so either 1 or 0. I'll elaborate more if you need to, but right now I'm very tired
Garstyciuks
New member
I am a bit confused about how to properly calculate the flags. Right now I use this to calculate the flags:
Is this correct? How should I calculate the carry (borrow) flags for SUB instruction?
Code:
//ADD A,n
case 0x87:
F = 0;
if ((A&0x0F)+A>0x0F) F|= HALF_FLAG;
if ((u16)(A + A)>0xFF) F |= CARR_FLAG;
if (A+A==0) F|= ZERO_FLAG;
A += A;
cycles+=4;
pc++;
break;
HyperHacker
Raving Lunatic
I'm not sure how correct this is, but this is what I use for subtraction. (It's probably slow being in its own function; I haven't optimized much yet. Hopefully you can guess what the other functions do based on their names.)
Notice I use a single regF to hold the flag status, like the real GB does. This makes it easier to correctly emulate AF being pushed/popped. (Very important to note that a GB game can access the unused bits of F by pushing it, then popping it into another register. I've yet to try this on the real hardware though.)
Code:
void Sub8(BYTE* reg1, BYTE* reg2, BOOL Carry)
{
ClearFlag(regF,FLAG_N);
if((*reg1) || (*reg2)) //If either is nonzero
{
int x = (int)(*reg1); //(*reg1) means value pointed to by reg1
x -= (int)(*reg2);
if(Carry) x -= (int)CheckFlag(regF,FLAG_C);
SetFlagTo(regF,FLAG_N,(((*reg1) & 0xF) - ((*reg2) & 0xF)) < 0); //Todo: should this be FLAG_C? (Probably not - using N fixes things)
(*reg1) = (BYTE)x & 0xFF;
SetFlagTo(regF,FLAG_Z,(*reg1) == 0); //Set Z flag if reg1 is 0, else clear it.
SetFlagTo(regF,FLAG_H,((*reg1) & 0xF) == 0xF); //Set H flag if reg1 & 0xF is 0xF, else clear it.
}
else //If both are zero, we only need to do this.
{
SetFlag(regF,FLAG_Z);
ClearFlag(regF,FLAG_H | FLAG_C);
}
}Notice I use a single regF to hold the flag status, like the real GB does. This makes it easier to correctly emulate AF being pushed/popped. (Very important to note that a GB game can access the unused bits of F by pushing it, then popping it into another register. I've yet to try this on the real hardware though.)
Last edited:
Garstyciuks
New member
SetFlagTo(regF,FLAG_H,((*reg1) & 0xF) == 0xF); //Set H flag if reg1 & 0xF is 0xF, else clear it.
When 00001000 is substracted from 00010011, the result would be 00001011 and it wouldn't generate half borrow flag? Maybe it should be if it is smaller or equal to 0x0F, not only equal.
When 00001000 is substracted from 00010011, the result would be 00001011 and it wouldn't generate half borrow flag? Maybe it should be if it is smaller or equal to 0x0F, not only equal.
HyperHacker
Raving Lunatic
You may be on to something there. I'll make a note in the code, but it's not in a compilable state at the moment.
refraction
PCSX2 Coder
holy crap dude, hex posting ;p
seriously, i think you need to delete a few lol
seriously, i think you need to delete a few lol
Garstyciuks
New member
This site is sometimes lagging really much, so he probably got a little angry that he can't post, so he clicked the post button a few times Does anyone know a site containing information about various types of flags?
Does anyone know a site containing information about various types of flags?
refraction
PCSX2 Coder
all i can remmeber is
zero = when the result is zero (i think)
half carry = when bit 4 is carried over to bit 5
carry = when bit 8 is carried over to bit 9 / overflows (been so long since i touched GB i cant remember if its 8 or 16 bit registers)
zero = when the result is zero (i think)
half carry = when bit 4 is carried over to bit 5
carry = when bit 8 is carried over to bit 9 / overflows (been so long since i touched GB i cant remember if its 8 or 16 bit registers
)
Garstyciuks
New member
How to actually find if bit 4 was carried to bit 5?
refraction
PCSX2 Coder
Garstyciuks said:
dunno, never really figured it
i guess its something to do with if the original byte was less than 0xf and the result is higher, or something.
Garstyciuks
New member
I guess something like ((A&0x0F)+(B&0x0F)>0x0F) would determine the half carry flag. A and B are 8bit values. What is the simplest rom with some kind of video output? I would like to test what I have made
I edited the half carry formula to a correct one, probably I was too sleepy when I was posting...
I edited the half carry formula to a correct one, probably I was too sleepy when I was posting...
Last edited: