I'm working on a US localization hack of Arkanoid II. The hack is mostly done. It currently uses any combination of North American Vaus and standard controllers to control the Vaus in the 2P game, the two Vauses in the VS game, control the pointer in the menus, and pause the game. Of course, this is only for use on a real NES and I'm using my PowerPak to do this. This part currently works great.
But, the last thing I'm trying to get to work is saving and loading screens created with the level editor. (Again, this is only for the real thing; you can easily save your edited levels on an emulator using savestates. According to the list, Mapper 152 is not supported by PowerPak or Everdrive for save states.) I want to save and load from SRAM instead of from the Famicom Tape drive. In this game, you choose from a menu when you want to save or load one screen's data to the tape drive. The data size is 140 bytes which I hacked to simply load and save to 6000-613F. If I can get this to work, it is very likely I will hack it to save multiple screens.
Unfortunately, Arkanoid II uses Mapper 152, which doesn't normally support battery backed SRAM. Here is what Mapper 152 looks like:
$8000-FFFF: [MPPP CCCC]
M = Mirroring:
0 = 1ScA
1 = 1ScB
P = PRG Reg (16k @ $8000) [$C000 is fixed as the last 16k of the ROM]
C = CHR Reg (8k @ $0000)
Since along with SRAM support it needs to support 1ScA and 1ScB mirroring. I first tried to change the mapper to MMC1, which of course handles WRAM. I made what I thought were all the necessary code changes, but my attempt failed miserably. It does change program banks properly at first, but then completely locks up.
So, why not, I tried using the PowerPak but changed it so that it thought the game has SRAM.
And I thought it worked, but it fails in a way that just doesn't make any sense to me. I'll explain.
Desperate, I tried using NES 2.0:
I am so confused. I really can't comprehend how the game save works even when loading a different game that uses SRAM without even modifying the .sav file but then loses all trace of when I cycle power.
If you want to test this, for yourself the load/save hack is quite short. Make the following changes in a hex editor to a ROM. (Also, use the 16 byte header I have above because the ROMs floating around often have the wrong mapper listed (70)):
Load:
E5EB: EA EA EA
E5F0: EA EA BD 00 60 EA EA EA EA
E601: EA EA BD 00 61 EA EA EA EA
Save:
E624: 4C 20 E6
E635: 9D 00 60
E640: 9D 00 61
But, the last thing I'm trying to get to work is saving and loading screens created with the level editor. (Again, this is only for the real thing; you can easily save your edited levels on an emulator using savestates. According to the list, Mapper 152 is not supported by PowerPak or Everdrive for save states.) I want to save and load from SRAM instead of from the Famicom Tape drive. In this game, you choose from a menu when you want to save or load one screen's data to the tape drive. The data size is 140 bytes which I hacked to simply load and save to 6000-613F. If I can get this to work, it is very likely I will hack it to save multiple screens.
Unfortunately, Arkanoid II uses Mapper 152, which doesn't normally support battery backed SRAM. Here is what Mapper 152 looks like:
$8000-FFFF: [MPPP CCCC]
M = Mirroring:
0 = 1ScA
1 = 1ScB
P = PRG Reg (16k @ $8000) [$C000 is fixed as the last 16k of the ROM]
C = CHR Reg (8k @ $0000)
Since along with SRAM support it needs to support 1ScA and 1ScB mirroring. I first tried to change the mapper to MMC1, which of course handles WRAM. I made what I thought were all the necessary code changes, but my attempt failed miserably. It does change program banks properly at first, but then completely locks up.
So, why not, I tried using the PowerPak but changed it so that it thought the game has SRAM.
Code:
4E 45 53 1A 04 10 8[2] 90 00 00 00 00 00 00 00 00
And I thought it worked, but it fails in a way that just doesn't make any sense to me. I'll explain.
- - Create a .SAV file for Arkanoid II that is filled with DD and place it on PowerPak.
- I start Arkanoid II.
- I EDIT and create a simple screen.
- I SAVE the screen.
- I EDIT and erase the screen.
- I LOAD the screen.
- I view it via EDIT or PLAY and it has successfully restored the screen I saved. (So 6000-61FF is functioning correctly as RAM, nice!)
- I hold down RESET.
- It asks me to verify that I want to save the file. I choose yes.
- I load another game that has battery backed SRAM. I happen to have used StarTropics II.
- I make a change to StarTropics II (I had one game, so create a 2nd/new game).
- I hold down RESET.
- It asks me to verify that I want to save the file. I choose yes.
- I start Arkanoid II.
- I choose EDIT. The screen is blank. (This is correct as I haven't loaded it yet.)
- I choose LOAD.
- I choose EDIT or PLAY. The game has successfully loaded the screen I saved. (So everything works, awesome!... but, I celebrated too early...)
- I hold down RESET and choose not to save the SRAM (or choose to save, it doesn't matter.)
- I start StarTropics II. My new character is shown in the list of games.
- I cycle power to the NES.
- I start Arkanoid II.
- I choose EDIT. The screen is blank. Fine.
- I choose LOAD.
- I choose EDIT - The screen is filled with random garbage!
- I cycle power to the NES.
- I start StarTropics II. My new character is shown in the list of games.
- I view the .sav files on my compact flash card on my PC.
-- The StarTropics .sav file has changed, as you would expect.
-- The Arkanoid II .sav file has not changed...
-- I also tried all of this with another game, Ys.
-- I also tried choosing the save file instead of picking the one it chose for me.
Desperate, I tried using NES 2.0:
Code:
4E 45 53 1A 04 10 82 9[8] 00 00 [75] 00 00 00 00 00
but it seems to work the same.I am so confused. I really can't comprehend how the game save works even when loading a different game that uses SRAM without even modifying the .sav file but then loses all trace of when I cycle power.
- Can anyone tell me what the heck is going on?
Why does it say it is saving, but doesn't save anything?
Why does the latest FCEUX fill 6000-7FFF with whatever byte is currently pointed to by the Program Counter pointer?
If you want to test this, for yourself the load/save hack is quite short. Make the following changes in a hex editor to a ROM. (Also, use the 16 byte header I have above because the ROMs floating around often have the wrong mapper listed (70)):
Load:
E5EB: EA EA EA
E5F0: EA EA BD 00 60 EA EA EA EA
E601: EA EA BD 00 61 EA EA EA EA
Save:
E624: 4C 20 E6
E635: 9D 00 60
E640: 9D 00 61