Post subject: Aerial Assault (W) for Game Gear will not load
Joined: 5/4/2018
Posts: 18
For some reason, the other two Game Gear games that I have on my computer work just fine. It's just that Aerial Assault (W) won't load. Don't know if anybody else has this problem. As soon as I load it, I get nothing. No sound, no Sega screen at the beginning...nothing. Nothing happens. And I'm getting the checkmark in the lower-left corner, so I know it's a good dump. Anybody else able to recreate this? EDIT: Oddly enough, Aerial Assault (J) (Rev 1) works perfectly okay.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
I'll look into it.
Joined: 5/4/2018
Posts: 18
Alyosha wrote:
I'll look into it.
Thanks. Will you need the SHA1 and MD5 from the dump status report for the specific ROM I used, by any chance?
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
PrinceWatercress wrote:
Alyosha wrote:
I'll look into it.
Thanks. Will you need the SHA1 and MD5 from the dump status report for the specific ROM I used, by any chance?
Shouldn't be necessary, I just haven't gotten around to it yet, maybe in a few days.
Joined: 5/4/2018
Posts: 18
Alyosha wrote:
PrinceWatercress wrote:
Alyosha wrote:
I'll look into it.
Thanks. Will you need the SHA1 and MD5 from the dump status report for the specific ROM I used, by any chance?
Shouldn't be necessary, I just haven't gotten around to it yet, maybe in a few days.
Alright. Let me know if you do. Thank you.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
So this game is turning on the ‘ROM write enable’ flag and then doing some antics with rom writes. Will take more time then I thought to sort out.
Joined: 5/4/2018
Posts: 18
Alyosha wrote:
So this game is turning on the ‘ROM write enable’ flag and then doing some antics with rom writes. Will take more time then I thought to sort out.
Yikes! No wonder it wasn't working. Good luck with getting that fixed. Once again, thank you.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
Ok, I was wrong about that. The game does set the 'ROM write enable' flag, but the root cause of the problem is that it doesn't set the stack pointer before starting to execute code. A 'CALL' instruction then overwrites the ROM bank. This happens since I initialize the stack pointer to zero, then it gets decremented to 0xFFFF (ROM bank register.) I tried looking for documentation about where the stack pointer gets intiialized to, but I don't see it actually specified anywehere. 0x0 and 0xFFFF both crash the game, so it can't be those. It's possible that's it's just some unspecified value. If this were the case, this game would function by pure chance on real hardware. The game does need to be able to return to the proper address after the call, so the stack pointer does have to be in writable memory. This is very strange. My guess is that during development, they didn't realize the mistake they made since they left the ROM write anbel flag set, meaning the stack pointer could start anywhere and still be in writable memory on their dev boards, thus masking the problem. Or it really is initialized to something internally and I just can't find what. The documentation does specify that the only register actually set is PC (to zero) so who knows what actually happens. Anyway, I added a game specific hack to make the game run by putting the stack pointer in RAM initially. I don't particularly like it, but it does work now.
Joined: 5/4/2018
Posts: 18
Alyosha wrote:
Ok, I was wrong about that. The game does set the 'ROM write enable' flag, but the root cause of the problem is that it doesn't set the stack pointer before starting to execute code. A 'CALL' instruction then overwrites the ROM bank. This happens since I initialize the stack pointer to zero, then it gets decremented to 0xFFFF (ROM bank register.) I tried looking for documentation about where the stack pointer gets intiialized to, but I don't see it actually specified anywehere. 0x0 and 0xFFFF both crash the game, so it can't be those. It's possible that's it's just some unspecified value. If this were the case, this game would function by pure chance on real hardware. The game does need to be able to return to the proper address after the call, so the stack pointer does have to be in writable memory. This is very strange. My guess is that during development, they didn't realize the mistake they made since they left the ROM write anbel flag set, meaning the stack pointer could start anywhere and still be in writable memory on their dev boards, thus masking the problem. Or it really is initialized to something internally and I just can't find what. The documentation does specify that the only register actually set is PC (to zero) so who knows what actually happens. Anyway, I added a game specific hack to make the game run by putting the stack pointer in RAM initially. I don't particularly like it, but it does work now.
So it's the game doing this, and not the emulator? Well, this is interesting... Edit: Forgot it was the game the whole time. Whoops.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
http://z80.info/interrup.htm This page says that SP = AF = 0xFFFF at reset. Implementing this does indeed make the game work. So I guess I can remove that hack afterall, problem solved!
Joined: 5/4/2018
Posts: 18
Alyosha wrote:
http://z80.info/interrup.htm This page says that SP = AF = 0xFFFF at reset. Implementing this does indeed make the game work. So I guess I can remove that hack afterall, problem solved!
Great! Thanks!