Saving issues for games with 64Kbit SRAM (Goomba Color & EZ Flash)

Shinrai · 2017-12-21 6:31:24 pm

I've been running some tests with Goomba Color on the EZ Flash Reform (Client 2.04), and I've run into some issues when it comes to saving games that use only 64Kbit SRAM (Kirby's Dreamland 2, Super Mario Land 2, Wario Land: Super Mario Land 3). I'll try to explain this as best as I can.

64Kbit games can be saved without having to go into the menu (L+R), when I reboot the system, a message indicating that the .sav file is being backed up is displayed.
32KB games (Pokemon Yellow, Wario Land 3) can't be saved without having to go into the menu and pressing exit. If you reboot the system without going into the menu, the game's SRAM isn't backed up and no message is displayed when booting up the flash cartridge.

However, the issue with 64Kbit games is that they delete themselves upon booting and saving another 64Kbit rom. For example, when playing through the first level in Kirby's Dreamland 2, I can shut the system off without going into the menu. The save file is still there upon reboot. The system is rebooted again, the message says that the game's SRAM was once again backed up. I load Super Mario Land 2, beat the first level, shut off the system without going into the menu, and the SRAM backs up upon reboot (the message is displayed). This is where the issue lies. Now I try to load Kirby's Dreamland 2 once again, and my save file is completely gone!

Is there any reason for this? Why do 64Kbit games backup without going into the menu and why not 32KB games? And why does loading up another 64Kbit game delete the previous save? If this can't be fixed, is there a way to force a 32KB type save on 64Kbit games so that I don't accidentally delete another save (meaning, I don't want the save to backup without having to exit to the menu).

Last edited by Shinrai (2017-12-21 6:43:20 pm)

Dwedit · 2017-12-22 6:36:46 am

I'll explain how the saving system works... (all units are bytes)

PocketNES and Goomba Color divide the 64K of SRAM into a 56K block for storing files ("storage"), and an 8K block at the end ("end SRAM") for storing the active game's 8K SRAM save.
When you load a game that uses an 8K save, that game is set as the owner of the end SRAM. When the game writes to emulated SRAM, it also writes to the end SRAM as well. So it is able to allow powering off at any time. The next time you run the emulator, it will save the end SRAM into storage, knowing what game owns the SRAM.

If you enter the menu with L+R, it will commit the game's SRAM into storage, set the end SRAM owner as nobody, and blank out end SRAM. This is done to make the emulator's save smaller when compressed. Then when you resume the game, it sets the SRAM owner back to the current game again, and reloads the end SRAM so you can keep playing and turn off at any time. You shouldn't notice this detail happening at all.

Games that use 32K size saves cannot use the end SRAM because 32K is too big. So they commit the game's SRAM to storage whenever you open the L+R menu.

So far, so good. The only time there are problems is if the flash cartridge doesn't provide a full 64KB save file for the emulator, and load that entire 64K save before starting the emulator. The first 32K could be a valid save file, then the second 32K could be anything. It could be proper data from the last time you ran the emulator, it could be blank, it could be data from another game, etc. If the last 32K is junk, the end SRAM is owned by a game, and you powered off and started up again, the emulator will store that junk as the save file for the game.

So you need to figure out how to tell the flash software that the emulator wants 64K saves, and that the save file must be at least 64K in size. There are so many flash cartridges out there, and I don't have any of them, so I don't have any firsthand experience there. The only three I use are the GBA Movie Player, M3 (microSD), and the Flash2Advance 32MB with Pogoshell.

morbid27 · 2017-12-29 12:36:40 pm

Hey there Shinrai - Alot of people are noticing these issues with the new Ez Flash IV client firmware (2.0) etc. The problem lies that it is telling the emulator to use the more common 8kb's space, i believe, and not the full 64kb's space it should when it auto-patches the emulator.

You should read this thread for a better explanation and possible think to going back to (1.X) firmware if you use these emu's alot
There is also mention of a better client to use if you are on lower firmware.

Scroll through the thread and read.

https://gbatemp.net/threads/pocketnes-g … ed.439715/

Edit:

As the successor of EZ-FLASH IV, Reform works similar with EZ-FLASH IV and uses the new EZ4Kernel V2

Im not to sure about using lower firmware on Reform????
Anyone Know??

Last edited by morbid27 (2018-01-02 9:46:20 am)

Dwedit · 2017-12-30 8:17:19 am

Thanks, I never know what to tell people who ask those kind of flash cart questions.

morbid27 · 2018-01-02 9:55:40 am

morbid27 wrote:

Edit:
As the successor of EZ-FLASH IV, Reform works similar with EZ-FLASH IV and uses the new EZ4Kernel V2
Im not to sure about using lower firmware on Reform????
Anyone Know??

They should seriously update the firmware to use a list in the settings KEYSET.CFG that can exclude certiain games from being autopatched because this seems to break all these emu's to using a wrong save size (I mean on that link a they were already patched now the firmware keeps switching the save size to the old 8kb's really annoying. Same issue with using the official client back in the day of 1.X firmware without autopatching.

https://gbatemp.net/threads/pocketnes-g … ed.439715/

Last edited by morbid27 (2018-01-02 9:59:09 am)

Shinrai · 2018-01-13 8:26:15 pm

morbid27 wrote:

The problem lies that it is telling the emulator to use the more common 8kb's space, i believe, and not the full 64kb's space it should when it auto-patches the emulator.

Makes me wonder if you're able to switch some values around in the actual patch file to make it save the full 64KB instead of the 8KB. But I can't imagine that it is that easy unfortunately. I'll have to figure out some way to make this work because I really want to playthrough Super Mario Land 2 (and a whole bunch of other games that use the smaller SRAM size).

morbid27 wrote:

They should seriously update the firmware to use a list in the settings KEYSET.CFG that can exclude certiain games from being autopatched

That would be a dream come true. Hopefully someone on the EZFlash team notices that this is an issue. But I'm not too hopeful for it. In the meantime, I'll keep on looking at those patch files. Hopefully I can figure out how they work, and just switch it to think that it uses a 64KB save. (If I figure that out, I might just make a tool to convert the patch files into different save formats. Who knows...)

Last edited by Shinrai (2018-01-13 8:27:57 pm)

Shinrai · 2018-01-13 8:47:42 pm

Looks like someone was able to change a patch file to force 64KB saving with the SMSAdvance emulator.

https://gbatemp.net/threads/ez-flash-iv … 77/page-10

Maybe it's possible to do the same with the Goomba Color's patch file? I'll look more into it and try to make a working patch.

Dwedit · 2018-01-14 6:23:42 am

So far I see that EZ4 is messing with bytes in the "Reserved Area" of the GBA header.

Shinrai · 2018-01-14 8:26:22 am

I think I have it figured out. I was messing around with some values in the Mother 3 patch (A game that I know saves games with the full 64KB), and I copied the header from that patch file to one of the Goomba Color patches. It worked! It now saves the full 64KB instead of the 8KB and the saving problems are gone.

I don't exactly know how I can post any files, but here are the hex values that you have to replace at the top of the patch file.

000: F1 43 02 00 07 00 02 02 FE 43 02 00
00C: 0C 00 02 02 8F 44 02 00 1B 00 02 02
018: 35 45 02 00 08 00 02 02 78 45 02 00
024: 17 00 02 02 95 45 02 00 18 00 02 02
030: BC 45 02 00 0A 00 02 02 22 46 02 00
03C: 1C 00 02 02 49 6C 33 00 1A 00 02 02

I don't know if all of these values matter, just haven't taken the time to figure out what values determine whether it uses 64KB saves or not.

Last edited by Shinrai (2018-01-14 8:27:23 am)

Shinrai · 2018-01-14 8:52:56 am

Oops, apparently that header has GSS patching enabled. That breaks some games. I looked at another game that used 64KB saving, copied the patch header from that, and copied it to all of my Goomba Color patches.

This one should work a lot better.

000: 27 06 05 00 07 00 00 00 34 06 05 00
00C: 0C 00 00 00 C5 06 05 00 1B 00 00 00
018: 6B 07 05 00 08 00 00 00 AE 07 05 00
024: 17 00 00 00 CB 07 05 00 18 00 00 00
030: F2 07 05 00 0A 00 00 00 58 08 05 00
03C: 1C 00 00 00 8A B3 0D 00 1A 00 00 00

Dwedit · 2018-01-14 10:52:13 am

I still don't understand how .pat files exactly work, what they actually change when it loads up the rom.

Shinrai · 2018-01-14 1:32:12 pm

Me neither, I'm pretty sure it has something to do with how the ROM is saved. Since the EZFlash uses SRAM to save everything and then backs it up the micro SD card once it powers on again. I guess different kinds of GBA games used Flash, EEPROM, and sometimes even FRAM save storage. The patch file just changes some things around to allow the game to save to SRAM.

That's my guess anyways...

Here's the full (64KB) patch file in case anyone needs it. It'll be on my Google Drive for the time being. It's been working on every game so far, but if there are any issues, let me know.
https://drive.google.com/file/d/1g0oWTK … sp=sharing

Dwedit · 2018-01-14 2:09:40 pm

So you have the equipment, right?

What happens if you make this change to the header of the Goomba Color ROM?

0xB0: 30 31 96 00 80 00 00 00 9C 01 10 00 00 56 00 00

This changes the "Reserved area" to be 9C 01 10, which is used by EZ4 patched roms?

Shinrai · 2018-01-15 6:14:13 pm

I tried it out, but I don't notice anything different happening? I don't know the GBA headers that well, but if you explain a couple things, I'm sure I can run a couple of tests to see exactly what that patch file is doing.

Dwedit · 2018-01-16 12:40:46 pm

I was looking at some old Goomba Color version that someone had applied an EZ4 patch to, and that was one of the changes made. I don't know what it does, and just wanted to know if it affected 64K saving.

Micha1982 · 2018-03-29 9:47:57 am

Hello there,
first at all its nice to see there is still activity for such a great piece of hardware. I do not know anything about programming, bits and bytes and what is going exactly with saving here, but I own a EZFlash IV since a few months and have a lot of problems with Goomba Color (2014) and PocketSNES.

At first I used an older firmware with EZClient and never recognized these things, in the last weeks I used my GBA a bit more often, installed the latest 2.05-firmware and now facing these problems :(

At first it seems as if saving is fine, I made a .gba with Goomba including SuperMario 1+2 for example. I played Super Mario 1 several times and loaded my Savegame several times without problems (all with 2.05) - but after some time the game does not start anymore...when I try to play it now I cant start it anymore, only a few lines on startup.

This is very frustrating as I lost my savegames now - and the reason why I cant start to play long lasting games like Zelda - its just too risky to loose everything in the middle of the game.

Same behaviour of PocketNES, after a while I cant start Zelda 1 anymore...there iy a very annoying bug somewhere.

Having problems also inside the menu, much things do not work as they should - Pal-setting for example is lost every time I start the game, always starts with Ntsc...or a wrong color-palette.

It would be awesome if someone here could update these emulators/fixing these problems...all in all its a great system, but its just frustrating to not being able to play NES or Gameboy-games at all just because its too risky to loose the savegames all the time and if all the effort already went inside these emulators were for nothing cause they´re unusable.

Hopefully someone can fix this...many thanks already.

kuwanger · 2018-04-06 10:53:53 pm

It's a known issue and ( ezflash.sosuke.com/viewtopic.php?f=12&t=12660 ) there's pre-patched emulators that were designed for the earlier (v1.x) EZ4 kernel that should still work on the later (v2.x) one. You might have to use KEYSET.CFG to disable patching using the 4 letter Title IDs of GMBC, PNES, etc (0xac-0xaf in each emulator) at the bottom.

@Dwedit - The EZ4 (pre-v2.0 kernel) abuses the reserve area to store some information used for patching. 0xb5-0xb7 inclusive is the 4-bit shifted address of the key processing routine for handling resetting back to the EZ4 menu. 0xba is the size of SRAM * 4096 (since all games are patched for SRAM). I think 0xb9 is meant to indicate the original type of memory or something. I've no idea what 0xb8 actually does but I recall having issues when I left it as 0. Useless trivia of what little I understand.

Dwedit · 2018-04-07 1:03:55 pm

Thanks Kuwanger!

kuwanger · 2018-04-09 11:31:32 am

Turns out my answers were only partly correct. They released the EZ3 code which the EZ4 code is based heavily on. So, here's some better description of their patching:

github.com/ez-flash/ez3manage/blob/11cbad3f7b05ee89e91fccd756d6bd520306af56/new_ezmanagedlg.cpp#L3067

They also included their blowfish key, so I was able to trivially decrypt their xcode. So, yea, that's kind of nice. :)

Dwedit's Board

Announcement

#1 2017-12-21 6:31:24 pm

Saving issues for games with 64Kbit SRAM (Goomba Color & EZ Flash)

#2 2017-12-22 6:36:46 am

Re: Saving issues for games with 64Kbit SRAM (Goomba Color & EZ Flash)

#3 2017-12-29 12:36:40 pm

Re: Saving issues for games with 64Kbit SRAM (Goomba Color & EZ Flash)

#4 2017-12-30 8:17:19 am

Re: Saving issues for games with 64Kbit SRAM (Goomba Color & EZ Flash)

#5 2018-01-02 9:55:40 am

Re: Saving issues for games with 64Kbit SRAM (Goomba Color & EZ Flash)

#6 2018-01-13 8:26:15 pm

Re: Saving issues for games with 64Kbit SRAM (Goomba Color & EZ Flash)

#7 2018-01-13 8:47:42 pm

Re: Saving issues for games with 64Kbit SRAM (Goomba Color & EZ Flash)

#8 2018-01-14 6:23:42 am

Re: Saving issues for games with 64Kbit SRAM (Goomba Color & EZ Flash)

#9 2018-01-14 8:26:22 am

Re: Saving issues for games with 64Kbit SRAM (Goomba Color & EZ Flash)

#10 2018-01-14 8:52:56 am

Re: Saving issues for games with 64Kbit SRAM (Goomba Color & EZ Flash)

#11 2018-01-14 10:52:13 am

Re: Saving issues for games with 64Kbit SRAM (Goomba Color & EZ Flash)

#12 2018-01-14 1:32:12 pm

Re: Saving issues for games with 64Kbit SRAM (Goomba Color & EZ Flash)

#13 2018-01-14 2:09:40 pm

Re: Saving issues for games with 64Kbit SRAM (Goomba Color & EZ Flash)

#14 2018-01-15 6:14:13 pm

Re: Saving issues for games with 64Kbit SRAM (Goomba Color & EZ Flash)

#15 2018-01-16 12:40:46 pm

Re: Saving issues for games with 64Kbit SRAM (Goomba Color & EZ Flash)

#16 2018-03-29 9:47:57 am

Re: Saving issues for games with 64Kbit SRAM (Goomba Color & EZ Flash)

#17 2018-04-06 10:53:53 pm

Re: Saving issues for games with 64Kbit SRAM (Goomba Color & EZ Flash)

#18 2018-04-07 1:03:55 pm

Re: Saving issues for games with 64Kbit SRAM (Goomba Color & EZ Flash)

#19 2018-04-09 11:31:32 am

Re: Saving issues for games with 64Kbit SRAM (Goomba Color & EZ Flash)

Board footer