Garstyciuks
New member
I can't find those two anywhere, could you upload it here? (I guess they are freeware, aren't they?)
Game Boy
- Thread starter -//zAe\\-
- Start date
hap
New member
They're PD, see attachment. Visit http://www.pdroms.de/ for more..
I'm not gonna tell you how/where to get it, and you're not allowed to ask, but if you want to do proper testing, I suggest to get the GoodGBx romset.
I'm not gonna tell you how/where to get it, and you're not allowed to ask, but if you want to do proper testing, I suggest to get the GoodGBx romset.
Falcon4ever
Plugin coder / Betatester
perhaps we should close this topic and create a newone. The first post should include all important hints and links to usefull documents.
Garstyciuks
New member
Yeah, that would be good.
so where should i ask my questions now?
I'm against changing the first post in this thread...
i think this thread is too big.
important informations for writing an emulator are:
1. where to get the docs (of course)
2. where to get demos
(demos for starting with the emu, demos for gfx and demos for testing)
3. informations which are not covered in the docs (e.g. big endian/little
endian)
question:
how do you think of
I'm against changing the first post in this thread...
i think this thread is too big.
important informations for writing an emulator are:
1. where to get the docs (of course)
2. where to get demos
(demos for starting with the emu, demos for gfx and demos for testing)
3. informations which are not covered in the docs (e.g. big endian/little
endian)
question:
how do you think of
Code:
char regs[8]; //buffer for registers
char *A = &(regs[1]), *F = &(regs[0]);
char *B = &(regs[3]), *C = &(regs[2]);
char *D = &(regs[5]), *E = &(regs[4]);
char *H = &(regs[7]), *L = &(regs[6]);
short *AF = (short*) &(regs[0]);
short *BC = (short*) &(regs[2]);
short *DE = (short*) &(regs[4]);
short *HL = (short*) &(regs[0]);Garstyciuks
New member
For all the registers you could use a C++ (or is it C?) union. My one looks like this:
I don't know if hi and lo order is right, but that is easy to change
Code:
union reg_t
{
u16 r16;
struct r8_t
{
//u8 h;
//u8 l;
u8 l;
u8 h;
}r8;
};I don't know if hi and lo order is right, but that is easy to change
albertwesker
New member
a few months back, before i decided to write Mega, i had considered doing a gb emu. in an effort to make searching this thread for info better, i went through and copied the posts and wrote a script to parse the data and arrange it as html.
i've posted that doc on my server for anyone who wants it. it's outdated probably by a few months now, and the last few posts are being held in place with 'pre' tag, but if it's of any use to anyone, take it now. I'll leave it up for a few days.
http://www.infourmation.com/misc/emutalkgb.html
also, i only kept posts that seemed relevent. for example, statements like 'good job on your emu!!!111!!' or 'my emu now supports the new l337 scroller demo', were discarded. =]
i've posted that doc on my server for anyone who wants it. it's outdated probably by a few months now, and the last few posts are being held in place with 'pre' tag, but if it's of any use to anyone, take it now. I'll leave it up for a few days.
http://www.infourmation.com/misc/emutalkgb.html
also, i only kept posts that seemed relevent. for example, statements like 'good job on your emu!!!111!!' or 'my emu now supports the new l337 scroller demo', were discarded. =]
Garstyciuks
New member
I have commented te other variant of it. When I was trying to run something on my emulator, it didn't work quite well, so I tried the other order and didn't change backShizZy said:
hap
New member
- timing's good
- controls are responsive
- nice icon
Double Dragon, I played until the forest level boss.. and died
- pressing left+right makes the main char do a cool moonwalk (the GB has a d-pad, so left+right or up+down should not be possible)
- some sprite priority errors (easily visible at baddies/throwable objects)
- one sound channel missing, the bassline... probably the waveram channel ?
Super Mario Land, I played until world 2-1
- some sprite priority errors (eg when jumping near a moving platform)
- one sound channel missing, probably same as in DD
- score and #of coins are messed up (in hex)
- top statusbar scanline sometimes glitches when scrolling
Attachment is a short remix of the 1st level boss music of Double Dragon I've made for fun
- controls are responsive
- nice icon
Double Dragon, I played until the forest level boss.. and died
- pressing left+right makes the main char do a cool moonwalk (the GB has a d-pad, so left+right or up+down should not be possible)
- some sprite priority errors (easily visible at baddies/throwable objects)
- one sound channel missing, the bassline... probably the waveram channel ?
Super Mario Land, I played until world 2-1
- some sprite priority errors (eg when jumping near a moving platform)
- one sound channel missing, probably same as in DD
- score and #of coins are messed up (in hex)
- top statusbar scanline sometimes glitches when scrolling
Attachment is a short remix of the 1st level boss music of Double Dragon I've made for fun
Last edited:
i think, i never need to do a byte swap in my code, because
A points to regs[0]
F points to regs[1]
(yea, it was wrong in my code...)
i heard that A is hi byte in AF. if i write 0xAABB to AF for example, my c++ compiler would write 0xAA to regs[0] (A) and 0xBB to regs[1] (F), exactly what i need.
so my conclusion is that byte swapping is only needed, if i write 16 bit values into memory, and if i understood everything right, i only must take care of instruction $08, LD (nn), SP
is this correct?
A points to regs[0]
F points to regs[1]
(yea, it was wrong in my code...)
i heard that A is hi byte in AF. if i write 0xAABB to AF for example, my c++ compiler would write 0xAA to regs[0] (A) and 0xBB to regs[1] (F), exactly what i need.
so my conclusion is that byte swapping is only needed, if i write 16 bit values into memory, and if i understood everything right, i only must take care of instruction $08, LD (nn), SP
is this correct?
I don't like this CPU...
being a lazy programmer my first target in writing a program is keeping the code in general as possible.
when i started the gb emu, the first thing i did, was to create a big table with all opcodes. an array of a struct, which defines the things i need to know later like, cycles for this operation, ptr to the function which emulates the respective instruction, parameters, and the type of their parameter.
"type of parameter" was an enumeration. if the param was a register, the type was "Ptr8", if the operand was placed immediately after opcode, type was called "PcVal8", if the parameter was an address kept in a reg, the type was "AddrPtr16", ...
later i had to realize, that this concept won't work. i realized, that flags are affected differently adding 8 bit values or 16 bit values.
so the function ptrs changed into:
ADD8 and ADD16 and ADDSP...
i became slowly angry, because my "clean" code structure was ruined more or less.
now i know it was just the beginning, there are exceptions over exceptions, which don't fit in my code structure, and every time i handle those "exceptions" the code gets a bit harder to read.
I never had those problems with emulating the 6502 in my nes emu...
the current problem is:
LD (nn), SP
LD (nn), A
the first parameter is "AddrPc16" in both cases... i'm very happy i realized, that in the first case a 16 bit value is written to (nn) and in the 2nd a 8bit value
the "general" way is to say "if source is 16 bit, destination has to be 16 bit, too", but this would need one of those ugly ifs
the easier way is to say "this is an exception, which appears once in the whole opcode list, change the function for emulating this (e.g. LDSP)"
now, i'm really interested, how you solved those problems... or better: do you ever have had such problems?
being a lazy programmer my first target in writing a program is keeping the code in general as possible.
when i started the gb emu, the first thing i did, was to create a big table with all opcodes. an array of a struct, which defines the things i need to know later like, cycles for this operation, ptr to the function which emulates the respective instruction, parameters, and the type of their parameter.
"type of parameter" was an enumeration. if the param was a register, the type was "Ptr8", if the operand was placed immediately after opcode, type was called "PcVal8", if the parameter was an address kept in a reg, the type was "AddrPtr16", ...
later i had to realize, that this concept won't work. i realized, that flags are affected differently adding 8 bit values or 16 bit values.
so the function ptrs changed into:
ADD8 and ADD16 and ADDSP...
i became slowly angry, because my "clean" code structure was ruined more or less.
now i know it was just the beginning, there are exceptions over exceptions, which don't fit in my code structure, and every time i handle those "exceptions" the code gets a bit harder to read.
I never had those problems with emulating the 6502 in my nes emu...
the current problem is:
LD (nn), SP
LD (nn), A
the first parameter is "AddrPc16" in both cases... i'm very happy i realized, that in the first case a 16 bit value is written to (nn) and in the 2nd a 8bit value
the "general" way is to say "if source is 16 bit, destination has to be 16 bit, too", but this would need one of those ugly ifs
the easier way is to say "this is an exception, which appears once in the whole opcode list, change the function for emulating this (e.g. LDSP)"
now, i'm really interested, how you solved those problems... or better: do you ever have had such problems?
The Gameboy does have alot of annoying little bugs or design flaws that are annoying to take care of. The P1 controller register for instance. P1 has 8-bits, Gameboy controls have 8 buttons. Yet, the P1 register only allows you to read 4 buttons at a time by turning on/off 2 switches. Anyone seeing something wrong with this? Unless there was some kind of hardware limitation, there was no excuse for this.
As far as clean code, I did the best I could, but I had to make alot of compromises you just mentioned.
As far as clean code, I did the best I could, but I had to make alot of compromises you just mentioned.
zenogais
New member
I was actually able to keep my GameBoy emu relatively clean by picking up on certain patterns in the opcodes. Granted there's no 100% clean way to do this, but it did work quite nicely. When I get on my other comp I'll post some sources so you can see what I'm talking about.
