Menu
What's new
By:
Filters

Game Boy

aprentice

aprentice

Moderator
bcrew1375 said:
I haven't even concerned myself with the priorities yet. I'm still trying to crack out bugs -_-. Ive tried tracing several games. Everytime I get close to pinpointing a problem, it seems to split off into hundreds of other problems. I've fixed a few bugs, my emulator is now slightly more compatible. Anyway, I haven't given up. If I can't get a gameboy emulator more compatible than this, I'll never make it with other emulators :p.
Click to expand...

I know how you feel, i'm kinda in the same situation, i managed to creep out a couple major bugs at the expense of long (days) hardcore debugging, my gameboy mono compat is about 95% now, but my gameboy color emulation suffers some some unknown bugs, so i estimate gameboy color compat to be about between 40-50%, im sure its just one or two bugs causing all the damage. I'm having trouble with timing, i redid my timing exactly as specified in the gameboy documents, but it appears to still be off. Bad timing = sprites not visible in a few select games (i current overcome that by disabling the sprite disabling code but that can't possibly be good even though I havent seen any bad effects from this yet) :p

Btw, if you notice any glitches in some games, it may be because of lack of sprite (or tile in gbc) priorities, after adding the priorities, all these "glitches" disppeared :p

I'm glad you havent given up bccrew, persistance is always rewarded, im sure with time you'll figure out whats wrong, it's just a matter of time.

Also, does mario land 2 have any anti-emulator code or something, this game is impossible to get working! Would be nice if there was a gameboy emu author on the boards to ask, but it seems we are on our own :p
 
Last edited:
B

bcrew1375

New member
Pffh, I haven't even got Mario Land 2 past the title screen :p. I compared my timings to another Gameboy emulator's. Assuming the other's is correct, mine appears to be off a little. When the other emulator's LY was at around 0xCD, mine was around 0xAB.
 
aprentice

aprentice

Moderator
bcrew1375 said:
Pffh, I haven't even got Mario Land 2 past the title screen :p. I compared my timings to another Gameboy emulator's. Assuming the other's is correct, mine appears to be off a little. When the other emulator's LY was at around 0xCD, mine was around 0xAB.
Click to expand...

I can't get it past the title screen either. And i thought LY wraps at 153 or am I wrong?
 
aprentice

aprentice

Moderator
Not what i'm looking for trotter, thanks though :p

After lots of debugging and such (and fixed a few bugs in the process) i've tracked down my gbc incompatability to the HDMA routines, but in what way I dont know. It looks like its copying the data correctly, so the problem could be anything from bad timing in the emulator to me not making the routine use cycle time.

Timing/HDMA info is hard to find and whatever is available seems uninformative. There must be a secret society for gb dev out there, cause some emus emulate stuff theres no docs out there for...
 
B

bcrew1375

New member
aprentice, did you ever have any MBC problems? Remember that distorted screen problem I had as a game was starting, when it showed all the garbage? Well, I've noticed it only seems to happen in games that use an MBC. Unfortunately, it happens with MBC1 and 2(which are the only ones I have emulated at the moment).

Edit: Hmm, seems I have this problem with Donkey Kong, DBZ - Goku Hishouden, and DBZ - Gekitouden. 2 use MBC1, 1 uses MBC2, and all three have battery backup. None of them appear to use Ram banks.
 
Last edited:
rcgamer

rcgamer

the old guy
sorry to interupt this thread but i had to say that you all deserve kudos. it is very inspiring to read all your trials and errors. congrats to the ones who got it done already and i hope the ones that havent got it yet are still trying.

tip of the cap to you all.
 
aprentice

aprentice

Moderator
work in progress of my debugger, hopefully this could help me find out why some games dont work.... I'll probably expand on this debugger later, but the screen shot pretty much shows the framework. A possibly feature could be tracing backwards, but i'd imagine that would take an insane amount of memory :p Also ideas for the future would be detection of "irregularities", like games trying to do impossible things (possibly emulator detection code).

Anyway, ideas, improvements, comments, post em here :p

debugger.gif
 
Last edited:
BGNG

BGNG

New member
That looks rather intuitive. Well done. I myself am basing (albeit for NES) a debugger window mostly off of the no$gmb one, which displays each of the following:

Disassembly
Hex Dump
CPU Memory Map (values of addresses as returned by the LD command)
Register Values
Status Register Flags (as check boxes)
File Header Dump (no$ does this in the disassembly window)

However, I notice you also have some additional displays like interrupts, bank controllers and I/O registers.
__________

Something which no$gmb allows you to do which may be useful in your application, is the way it lets you change the values of the registers and memory. If you can spoof some values at a breakpoint to see if it operates correctly, you could probably use it to debug even the emulator.
 
aprentice

aprentice

Moderator
BGNG said:
Something which no$gmb allows you to do which may be useful in your application, is the way it lets you change the values of the registers and memory. If you can spoof some values at a breakpoint to see if it operates correctly, you could probably use it to debug even the emulator.
Click to expand...

Hmm, that may be a pretty good idea, I'll consider adding it once all current implementations are complete. Hows progress on your nes emulator?
 
BGNG

BGNG

New member
It's in more or less the same spot it was when I posted the source in that "Incredulous Undertaking" thread. What I've done since then is modify the memory framework to accomodate for a variable number of ROM, VROM and Cart RAM banks, as well as updated the iNES header loader. I am also, as I mentioned, constructing a debugger window which will let you change things right down to the instructions in the PRG-ROM, although not change the size of the ROM. I'll have to do some thinking on that.

Outside the emulator realm, I've been compiling a technical document of various sources on the NES, and I've been researching things like the various mappers games use, Game Genie code format, etc. I even found mention that the NMOS 6502 architecture has a bug for Indirect addressing mode, which I have yet to implement in the emulator.

I don't know if this link was posted yet in this thread (I'm too lazy to look), but a comprehensive document covering the Game Boy (Super and Color too) quite thoroughly is the Pan Docs, which has contributions from Martin Korth (author of no$gmb)... Game Genie and GameShark codes are described. You can find that at the below address:

http://work.typo3.work.de/nocash/pandocs.htm
 
aprentice

aprentice

Moderator
Ok, finally came up with the "final" design for the debugger (and pretty much fully functional). It probably won't change much from this, if even. I don't want to spend too much time coding a debugger :p

debuggerv2.gif
 
BGNG

BGNG

New member
It certainly is helpful for display of information, but it doesn't appear to be able to change anything. I recommend putting in at least the ability to change processor registers (including status flags) and RAM values. That will make it very easy for you to pinpoint bugs in both a ROM (if you're developing one) and the emulator.

Other than that, it looks good. The only thing I would change is make the displays use a fixed-width font like Courier New or Fixedsys. The way the hex dump in the disassembler looks, it's as though someone layed them all down on a table and aligned them with the edges of his hands.
 
aprentice

aprentice

Moderator
BGNG said:
It certainly is helpful for display of information, but it doesn't appear to be able to change anything. I recommend putting in at least the ability to change processor registers (including status flags) and RAM values. That will make it very easy for you to pinpoint bugs in both a ROM (if you're developing one) and the emulator.
Click to expand...

Thats what the modify register button is for, it pops up another window that lets you modify the registers, I didn't want to clutter the debugger even more.

Other than that, it looks good. The only thing I would change is make the displays use a fixed-width font like Courier New or Fixedsys. The way the hex dump in the disassembler looks, it's as though someone layed them all down on a table and aligned them with the edges of his hands.
Click to expand...

Thanks for the interesting comparison. I haven't had a chance to port the cpu listbox to a listview control yet (like the box with the gameboy physical memory output), right now its just using a standard listbox which explains the misalignments. However, its still readable, thats all that matters to me right now :p

Thanks for the input.
 
BGNG

BGNG

New member
Ah, yes. I missed that button.

And indeed: it is your project. What do you care if others find it pretty to look at? Though if you plan for people to use it after its release, it may be a good idea to spruce it up a bit. Mainly by making a fixed-width display. The classic example is "iiiii" versus "WWWWW"... Five characters each, one significantly wider than the other. Even if they were aligned in a ListView control, that would still be the case unless every character of the font was the same width.
 
BGNG

BGNG

New member
Now THAT looks very good. There seems to be a bug in the ASCII display of the hex dump, though. All printable characters appear to be followed by a space.
 
You must log in or register to reply here.

Top