Game Boy

[bcrew1375]

Ah, the problem I originally thought was caused by the MBCs actually seems to be caused by games that are SGB/CGB capable. I'm guessing they're incorrectly detecting an SGB/CGB instead of an original GB. Now I just need to figure out how to fix it :/.

 

[BGNG]

To detect Super Game Boy, the values of SGB Flag and Old Licensee Code must be set in the cartridge header. In detail, that would mean that the value of $0146 is $03 and the value of $014B is $33.

To detect Game Boy Color, use the value of the CGB Flag in the cartridge header. If the value of $0143 is $80, then the game should be compatible with both normal and color Game Boy models. If it is $C0, then it should only work with Game Boy Color.

Additionally, some games check the value of the Accumulator directly after startup. If the value is $01, then the hardware is either Super Game Boy or normal Game Boy. If it is $FF, then the hardware is either Super Game Boy 2 or Game Boy Pocket. If it is $11, then it is either Game Boy Color or Game Boy Advance.

Lastly, you can detect if the game is on a Game Boy Advance by checking bit 0 of the B register directly after startup. If it is cleared, it is a Game Boy Color. If it is set, it is a Game Boy Advance.
__________

Note: The Super Game Boy 2 was little more than a Super Game Boy with a link cable port in it. Some games do detect this, however, like Tetris DX, which will display a different border for Super Game Boy and Super Game Boy 2.

EDIT:
Here is a list of examples for games which detect seperate combinations of hardware configurations:

Normal only: Tetris
Normal or Super: Pokémon
Normal, Super or Color: Game & Watch Gallery 2, Game & Watch Gallery 3
Normal, Super, Color or Super2: Tetris DX
Color only: Super Mario Bros. DX
Advance: The Legend of Zelda: Oracle of Ages, The Legend of Zelda: Oracle of Seasons

 

[bcrew1375]

Well, what I'm saying is I think the games are incorrectly detecting they are on a Super Gameboy, and so are trying to use its features. I'm only emulating an original Gameboy. To my knowledge, the startup register values for the original Gameboy are:

AF = 0x01B0
BC = 0x0013
DE = 0x00D8
HL = 0x014D

 

[BGNG]

The program code for the games detect which Game Boy they are on using the bytes I mentioned above. If for some reason they are indeed improperly detecting a different Game Boy, then something in your emulator is giving them different values for the above than it should.

EDIT:
Whoop. Looks like a new page. Consider "Above" as "In my last post"

 

[aprentice]

bccrew: those values are correct, the games shouldn't be detecting a super gameboy with those values, how have you come to this conclusion?

Is your stack pointer pointing at 0xFFFE ?
And note the gameboy starts in vblank mode, scanline 144, don't know if that will help. Do you have any more info on the problem so I can help you track it down?

edit: Also, do you talk like that in real life as well bgng? It sounds quite funny

 

[bcrew1375]

Um, BGNG, those bytes are part of the ROM. They're not variable. How could the game use information in its own ROM to determine the system type? I believe the Gameboy uses that information to determine how to run the game.

aprentice, I am assuming this is the problem because other games use the same things as some of the SGB games, but only the SGB games have the distortion problem when the game loads. I have the problem with Donkey Kong, both DBZ games, and Tetris Attack. All of these games have SGB support and I have the same problem with all of them. Other games that use the same hardware, but do not have SGB support, do not have this problem.

 

[aprentice]

Um, BGNG, those bytes are part of the ROM. They're not variable. How could the game use information in its own ROM to determine the system type? I believe the Gameboy uses that information to determine how to run the game.

aprentice, I am assuming this is the problem because other games use the same things as some of the SGB games, but only the SGB games have the distortion problem when the game loads. I have the problem with Donkey Kong, both DBZ games, and Tetris Attack. All of these games have SGB support and I have the same problem with all of them. Other games that use the same hardware, but do not have SGB support, do not have this problem.

What do you have at memory location 0xFF26? its IO register NR52 (sound register) and it should have the value 0xF1 for gameboy and 0xF0 for sgb on cpu initialization. That could be a way the rom detects if you have a super gameboy or not. I have no issues with these games, so your problem must be here..

 

[bcrew1375]

It was indeed set to 0xF0. Unfortunately, it seems to have no effect on the games .

 

[BGNG]

Ah, yes. I forgot how to post hardware detection of Super Game Boy. My appologies.

Super Game Boy programs write to the Joypad register at $FF00 in order to communicate with the Super Game Boy. For a non-Super Game Boy system, anything written to this register should be ignored.

Sending command $11 through this register (which requires a special SGB protocol which I will not document here) will pass a MLT_REQ command to the Super Game Boy, which is used for multiple joypads plugged into the SNES, which can be 1, 2 or 4. If this command is successful, then data can be read from each of those joypads. If it is not successful, then the hardware is not a Super Game Boy.

So simply ignore any data that is written to register $FF00 and it is therefore impossible for a ROM to detect that it is being used in a Super Game Boy.
__________

Simply checking the Accumulator will resolve Color/Advance Game Boy presence.

 

[bcrew1375]

You have to allow writes to 0xFF00, even for an original Gameboy. The Gameboy can only get the status of 4 keys at a time. You have to write to 0xFF00 to tell it which keys to get. I also saw something about writing a 3 to 0xFF00 and reading it back to get the Gameboy type. This doesn't seem to make much sense.

 

[aprentice]

So simply ignore any data that is written to register $FF00 and it is therefore impossible for a ROM to detect that it is being used in a Super Game Boy.

Thats great advice if you don't want your emulator to ever have joypad support

 

[BGNG]

Right, right. I said what I didn't mean. I MEANT to say to ignore any SGB functions to be written to the register.

 

[HyperHacker]

Alright, so I finally decided to start working on an emulator of my own. I've got the basic CPU emulation done, all opcodes except DAA and that sub-set 0xCB, working good so far. I'm not sure how I should go about doing interrupts, though. I'm starting with VBlank/LCDC status. I'm not sure exactly how to determine how many cycles to go before changing the LCDC mode.

Also, does anyone know what the values of the CPU and I/O registers are right when it boots up, before the bootROM is executed?

BTW, aprentice, your debugger would look a lot better if you used spaces instead of zeros for 1 and 2-byte opcodes, like this:
0150 00 .. .. NOP
0151 E0 D3 .. LDH ($FFD3),A
0153 CD 34 12 CALL $1234
except I've used periods instead of spaces because repeated spaces won't show up.

 

[aprentice]

BTW, aprentice, your debugger would look a lot better if you used spaces instead of zeros for 1 and 2-byte opcodes, like this:
0150 00 .. .. NOP
0151 E0 D3 .. LDH ($FFD3),A
0153 CD 34 12 CALL $1234
except I've used periods instead of spaces because repeated spaces won't show up.

I disagree, I think it would look messy and more hard to follow if it looked like that

Also in your sig "There are 11 types of people in the world: Those who can count in Binary and those who can't." i'm guessing you're the people who can't count in binary cause "11" = 3

 

[bcrew1375]

LOL, stop messing with him aprentice . Anyway, for the Gameboy, this will be your best friend: http://work.typo3.work.de/nocash/pandocs.htm. For the startup values, goto Power Up Sequence. It should also have the timings for the Stat Flag. Also, I'd have to disagree on the debugger as well. I think it looks fine the way it is.

 

[HyperHacker]

Heh, I thought that doc was just the same as the text file I had, but apparently not. Thanks!

Also in your sig "There are 11 types of people in the world: Those who can count in Binary and those who can't." i'm guessing you're the people who can't count in binary cause "11" = 3

That's the idea. It combines a few old jokes.

 

[bcrew1375]

Well, I think I already said it, but a big mistake I made when writing my graphics code was to draw the screen all at once, instead of scanline by scanline. *Waits for everyone to point and laugh* :blush:. So, now I'm kinda stumped as to how I should draw the background. I've got the window and sprites down fine, I just can't find a decent way to draw the background. BTW, aprentice, did you ever get my PM :whistling?

 

[aprentice]

Well, I think I already said it, but a big mistake I made when writing my graphics code was to draw the screen all at once, instead of scanline by scanline. *Waits for everyone to point and laugh* :blush:. So, now I'm kinda stumped as to how I should draw the background. I've got the window and sprites down fine, I just can't find a decent way to draw the background. BTW, aprentice, did you ever get my PM :whistling?

Yeah, I started writing out a reply and then had to leave for a few hours, when I got back someone closed the window already and I completely forgot about it until now :blush: Replying to that pmsg now..

 

[HyperHacker]

Bleh, how are you guys handling video exactly? I've just been doing SetPixel() in a loop whenever the game modifies a tile (to draw that tile on the buffer), and drawing the screen using BitBlt (copy from the tile buffer)... Of course it's ridiculously slow. Variable-size screen is a big problem especially, since the only way I know how to do it is with StretchBlt() which is so slow it's a joke.

 

[aprentice]

Bleh, how are you guys handling video exactly? I've just been doing SetPixel() in a loop whenever the game modifies a tile (to draw that tile on the buffer), and drawing the screen using BitBlt (copy from the tile buffer)... Of course it's ridiculously slow. Variable-size screen is a big problem especially, since the only way I know how to do it is with StretchBlt() which is so slow it's a joke.

I have no clue what you are talking about, did you mean to post this in the chip8 forum?