Game Boy
- Thread starter -//zAe\\-
- Start date
Thanks!
One more question, is the bootrom supposed to limit its writes to VRAM to modes 0 1 and 2? when i run the bootrom (and stop writes to VRAM at mode 3) it displayes corrupt graphics due to writes at mode 3...
or does it limit its writes but in a complicated, tricky way that does not work in my emulator due to the emulator's terrible timing?
One more question, is the bootrom supposed to limit its writes to VRAM to modes 0 1 and 2? when i run the bootrom (and stop writes to VRAM at mode 3) it displayes corrupt graphics due to writes at mode 3...
or does it limit its writes but in a complicated, tricky way that does not work in my emulator due to the emulator's terrible timing?
ShizZy
Emulator Developer
No, I don't think it limits VRAM. At least I don't in my emulator. It's very very simple, though your emulater needs to be somewhat working for it to work. I'm sure yours will, if mine does 
It gets executed the same as any other rom. You write it over the first 256 bytes, set your program counter to 0, and execute as normal. You don't need to set the other regs, the bootrom does it, but I do anyways.
Also, some things about the bootrom. There are demos that don't work with it (SPRITE and SPACE from what I just gave you). I think this is because the documents aren't the exact values, and these demos rely on the documented values to run. IE- were never meant to run on the real hardware. Also, I converted the entire bootrom to an array if anyone wants to use it, instead of cluttering by loading the bootrom file each time:
Regards
Edit: If it's working, but displaying garbage or looks really glitchy, it's probably a bug in your shifts and rotates. That initially happened to me, before I fixed it.
It gets executed the same as any other rom. You write it over the first 256 bytes, set your program counter to 0, and execute as normal. You don't need to set the other regs, the bootrom does it, but I do anyways.Also, some things about the bootrom. There are demos that don't work with it (SPRITE and SPACE from what I just gave you). I think this is because the documents aren't the exact values, and these demos rely on the documented values to run. IE- were never meant to run on the real hardware. Also, I converted the entire bootrom to an array if anyone wants to use it, instead of cluttering by loading the bootrom file each time:
Code:
const unsigned char boot_rom[0x100]=
{
0x31,0xFE,0xFF,0xAF,0x21,0xFF,0x9F,0x32,0xCB,0x7C,0x20,0xFB,0x21,0x26,0xFF,0x0E,
0x11,0x3E,0x80,0x32,0xE2,0x0C,0x3E,0xF3,0xE2,0x32,0x3E,0x77,0x77,0x3E,0xFC,0xE0,
0x47,0x11,0x04,0x01,0x21,0x10,0x80,0x1A,0xCD,0x95,0x00,0xCD,0x96,0x00,0x13,0x7B,
0xFE,0x34,0x20,0xF3,0x11,0xD8,0x00,0x06,0x08,0x1A,0x13,0x22,0x23,0x05,0x20,0xF9,
0x3E,0x19,0xEA,0x10,0x99,0x21,0x2F,0x99,0x0E,0x0C,0x3D,0x28,0x08,0x32,0x0D,0x20,
0xF9,0x2E,0x0F,0x18,0xF3,0x67,0x3E,0x64,0x57,0xE0,0x42,0x3E,0x91,0xE0,0x40,0x04,
0x1E,0x02,0x0E,0x0C,0xF0,0x44,0xFE,0x90,0x20,0xFA,0x0D,0x20,0xF7,0x1D,0x20,0xF2,
0x0E,0x13,0x24,0x7C,0x1E,0x83,0xFE,0x62,0x28,0x06,0x1E,0xC1,0xFE,0x64,0x20,0x06,
0x7B,0xE2,0x0C,0x3E,0x87,0xE2,0xF0,0x42,0x90,0xE0,0x42,0x15,0x20,0xD2,0x05,0x20,
0x4F,0x16,0x20,0x18,0xCB,0x4F,0x06,0x04,0xC5,0xCB,0x11,0x17,0xC1,0xCB,0x11,0x17,
0x05,0x20,0xF5,0x22,0x23,0x22,0x23,0xC9,0xCE,0xED,0x66,0x66,0xCC,0x0D,0x00,0x0B,
0x03,0x73,0x00,0x83,0x00,0x0C,0x00,0x0D,0x00,0x08,0x11,0x1F,0x88,0x89,0x00,0x0E,
0xDC,0xCC,0x6E,0xE6,0xDD,0xDD,0xD9,0x99,0xBB,0xBB,0x67,0x63,0x6E,0x0E,0xEC,0xCC,
0xDD,0xDC,0x99,0x9F,0xBB,0xB9,0x33,0x3E,0x3C,0x42,0xB9,0xA5,0xB9,0xA5,0x42,0x3C,
0x21,0x04,0x01,0x11,0xA8,0x00,0x1A,0x13,0xBE,0x20,0xFE,0x23,0x7D,0xFE,0x34,0x20,
0xF5,0x06,0x19,0x78,0x86,0x23,0x05,0x20,0xFB,0x86,0x20,0xFE,0x3E,0x01,0xE0,0x50
};Regards
Edit: If it's working, but displaying garbage or looks really glitchy, it's probably a bug in your shifts and rotates. That initially happened to me, before I fixed it.
Last edited:
actually it works 100% fine if I enable writes to VRAM during mode3, but since the docs pretty much said that VRAM access is forbidden during mode3, allowing access is kinda cheating...
im pretty sure it's a problem with my timing : i bet if the timing was correct, nothing would be written to VRAM during mode3. I think..
also, sprite and space seem to work fine as long as you stop the bootrom from 'crashing' on a wrong header checksum.
im pretty sure it's a problem with my timing : i bet if the timing was correct, nothing would be written to VRAM during mode3. I think..
also, sprite and space seem to work fine as long as you stop the bootrom from 'crashing' on a wrong header checksum.
Last edited:
truth2: Nothing should be written during mode 3, but I haven't disabled it either. I'm pretty sure it's just a hardware limitation. There should be no problem with allowing writes during that time. Though, are you sure that in denying writes during mode 3 you are not somehow denying writes in the other modes as well?
ShizZie: I just got home from work. I'll take a look at your code and see what I can find. Oh, also you don't need that hack for BLEM. Just try pressing the Start button.
ShizZie: I just got home from work. I'll take a look at your code and see what I can find. Oh, also you don't need that hack for BLEM. Just try pressing the Start button
.
Last edited:
ShizZy
Emulator Developer
bcrew: haha thanks Didn't think to try that. Let me know if you find anything.
http://www.aep-emu.de/ <- popped up fast there, why don't they put up one of the emus here that work
Didn't think to try that. Let me know if you find anything.http://www.aep-emu.de/ <- popped up fast there, why don't they put up one of the emus here that work
Last edited:
XTale
New member
Shall I remove it again?ShizZie said:http://www.aep-emu.de/ <- popped up fast there, why don't they put up one of the emus here that work
truth2: The bootrom does not work with mode 3 writes disabled. Shizzie, I've looked through your code and found numerous things that seem to have problems, but changes don't seem to effect games in the least. I have a feeling there is a major problem with your MBC code. I'll see what else I can find.
sethmcdoogle said:
Hmm.. Yeah, I guess you could see it that way. Again, no offense to anyone.
bcrew : well isn't that a problem? after all the docs clearly say that writes to vram during mode3 are ignored...
OOPS... I didn't realise that the bootrom enables video by itself, that means that using the bootrom, $ff40 must be set to 0 on powerup...
Last edited:
ShizZy
Emulator Developer
Thanks for taking a look. My MBC1 code is really simple, just a few lines. I'm sure that there is probably more to it. But still a lot of regular roms do not work. Did you look and see if any demos ran better with your fixes? I'm going to work on it some more tonight. Where did you find errors? I need some ideas of where to look for things.
I don't agree with that, and not because the statement was directed at me. I think it's great that emu coverage has gotten so extensive that even small projects such as mine own find a little place in the emu scene
Plus, it gives me motivation to work on it more, learn more, and maybe someday make something that people really do like.
Last edited:
Good news! I may have found one of your emulator's largest problems! You are not counting cycles when the CPU is not turned on. If you don't do this, you won't have anything to generate interrupts or IO ports and your emu will get stuck at halts and stops. Simply add an else line in the EmulateCPU function that counts cycles if the CPU is not on(10 is probably a good value) and be amazed . I was able to get Metroid 2 ingame with this one simple change. Unfortunately, it is very glitchy and Samus falls through the ground :/.
Edit: You should also be able to get Donkey Kong in game(though it will glitch and reset) by changing the way you write to the P1 register. You are simply writing the entire byte of data into memory. AND the data with 0x30, AND the P1 register with 0xCF, then Inclusive OR the data with the P1 register. That will make sure only bits 4 and 5 are written(This is the same problem Dark Stalker and myself were having with Donkey Kong. There's probably a much simpler way to do it, but this is how I did it.)
Edit 2: One other thing. Do you realize you lack support for window drawing?
. I was able to get Metroid 2 ingame with this one simple change. Unfortunately, it is very glitchy and Samus falls through the ground :/.Edit: You should also be able to get Donkey Kong in game(though it will glitch and reset) by changing the way you write to the P1 register. You are simply writing the entire byte of data into memory. AND the data with 0x30, AND the P1 register with 0xCF, then Inclusive OR the data with the P1 register. That will make sure only bits 4 and 5 are written(This is the same problem Dark Stalker and myself were having with Donkey Kong. There's probably a much simpler way to do it, but this is how I did it
.)Edit 2: One other thing. Do you realize you lack support for window drawing?
Last edited:
ShizZy
Emulator Developer
bcrew you are a god amoung mortals Thank you!
About the window drawing: yes, I do realize that. But I don't understand the concept of scrolling yet, so I couldn't finish my own drawing code (though it worked on some demos), so I didn't bother with the window until I fully grasped it. (Hence why the scanline function is a port of yours) Though I did figure out sprites on my own, rather easily. Weird
But yes, thank you, I will sift through it some more.
Thank you!About the window drawing: yes, I do realize that. But I don't understand the concept of scrolling yet, so I couldn't finish my own drawing code (though it worked on some demos), so I didn't bother with the window until I fully grasped it. (Hence why the scanline function is a port of yours) Though I did figure out sprites on my own, rather easily. Weird
But yes, thank you, I will sift through it some more.
ShizZy
Emulator Developer
I'm not emulating OBP, hence color inversions (I think) My sprite code isn't complete anyways. But once again bcrew, fantastic! This is the one game I've strived to get running since the beginning Needs work, I know Mario boots too, minus a crash after the title screen. I'm really proud of my rotates and shifts, they used to kill me... now I have a good understanding of them and I think they're mostly bug free.
EDIT: Added OBP, seems to work well, fixed my problem... was much easier than I thought, or I would have added it earlier. Still that bg tile junk around the houses and stuff though. Mario1 also goes in game, but same problem with metroid - player falls through the floor. Mario2 goes to the title screen
Needs work, I know Mario boots too, minus a crash after the title screen. I'm really proud of my rotates and shifts, they used to kill me... now I have a good understanding of them and I think they're mostly bug free.EDIT: Added OBP, seems to work well, fixed my problem... was much easier than I thought, or I would have added it earlier. Still that bg tile junk around the houses and stuff though. Mario1 also goes in game, but same problem with metroid - player falls through the floor. Mario2 goes to the title screen
Last edited:
Glad I could help . I've noticed you haven't emulated any of the STAT interrupts aside from the LYC. If bits 3, 4, or 5 are on, you call an interrupt when the STAT mode hits 0, 1, or 2, respectively. That might account for some problems.
Edit: Nevermind that. I just noticed them. Hmm, I'm not sure what it would affect, but you should only be requesting one V-Blank per screen. You have "if (mem.IOR_LY>=144)", it should be "if (mem.IOR_LY==144)"
. I've noticed you haven't emulated any of the STAT interrupts aside from the LYC. If bits 3, 4, or 5 are on, you call an interrupt when the STAT mode hits 0, 1, or 2, respectively. That might account for some problems.Edit: Nevermind that. I just noticed them
. Hmm, I'm not sure what it would affect, but you should only be requesting one V-Blank per screen. You have "if (mem.IOR_LY>=144)", it should be "if (mem.IOR_LY==144)"
Last edited:
ShizZy
Emulator Developer
Awesome thanks! In the past 20min, I just emulated the Cartridge RAM/Battery Pack, so now all saving and loading works Really easy too, just got to save out the 0x2000 bytes from 0xA000 to 0xBfff, then load them again over memory at startup
Edit: About the VBlank thing, it doesn't make a difference, because once LY == 144, it gets set, and then that branch of the switch never gets hit again until VBlank is entirelly over.
Really easy too, just got to save out the 0x2000 bytes from 0xA000 to 0xBfff, then load them again over memory at startup Edit: About the VBlank thing, it doesn't make a difference, because once LY == 144, it gets set, and then that branch of the switch never gets hit again until VBlank is entirelly over.
Last edited: