The Last Blade becomes unplayable after savegame file gets too big

[marcrobledo]

I've found a bug in NeoPop.
I didn't know where to report it since the project was abandoned a long time ago. But since Mednafen and Libretro have been keeping it alive, I think this is the place.

The bug can be reproduced in The Last Blade (Europe) and its japanese version Bakumatsu Rouman Tokubetsu Hen - Gekka no Kenshi - Tsuki ni Saku Hana, Chiri Yuku Hana (Japan).

Its savegame starts being 256 bytes (plus the 16 byte header).
Everytime the game saves (completing game, buying scrolls in the shop, changing game options, etc), it appends a new 256 bytes savegame to the existing one, probably for backup purposes just in case the latest savegame gets corrupted somehow. The game will always load the latest valid savegame.

The savegame file, then, will grow at every save point. However...
After it reaches 32528 bytes, the game will freeze when trying to save. Something is telling me it's because because the savegame is trying to become bigger than 32768 bytes, which might be NeoPop's limit (seems like The Last Blade might have a bigger Flash ROM?).
By the way, emulator doesn't crash, the game's music still continues but controls are disabled.

Why is it important to fix this? Because after some hours of playing it I've reached a point that after buying half of the Gallery shop, I cannot play the game anymore because it freezes when trying to save.

Fortunately, I've managed to manipulate the savegame and build a new smaller one, truncating the older copies (and it's compatible!). But this is not something everyone can do.

Tested in RetroArch, Mednafen, BizHawk and original NeoPop, all of them have the same issue. I've reported this on Mednafen's forums too.

[leoxxx]

It happen on Samurai Shodown! 2, too.
So back up your save file.

[marcrobledo]

Yeah, I took a look at my other savegame and it seems it does the same in them. But in those cases, I managed to unlocked everything before the savegame grew too big.

Backing up your savegame won't fix it though, since it will break again sooner or later.

The best quick fix is to remove the old copies inside the savegame, so the file gets smaller and you can save again. It can be done with an hex editor.

[leoxxx]

You can delete the save file directly. Next game, it will create a new.
I get the unlocked save file from my friend. Then back up it.

[ghost]

this is probably a bug for flash-type saves. the relevant save portion (at least for Last Blade) is the last portion which is about 256 bytes plus the header, but mine got corrupted after a while...

[stellarporter]

How many games use flash saves? I can't help but wonder if the save ram is just 256 bytes with wraparound. Or it's just an emulation error and missing some (instruction, call, bios, register) write to reset the flash cursor.

[stellarporter]

https://github.com/mamedev/mame/blob/master/src/mame/drivers/ngp.cpp

So cartridges use EEPROM. Game part is read-only. Rest can be rewritten for save data. Last sector is BIOS reserved for validation. Have to do run-time logs later and see how this could be NGP failing here.

[stellarporter]

Problem with Last Blade is that EEPROM bank 31 becomes full. Issues BIOS call VECT_FLASHERS 31 to erase everything and start over. NeoPop doesn't have that emulated. My version has 1 flaw since I don't know how to check rom size yet inside BiosHLE. Should call Mednafen author about this.
(edit: https://forum.fobby.net/index.php?t=msg&th=1738&start=0)

Another important caveat is that your rom should be save cleaned. Example:
no-intro SNK - Neo Geo Pocket Color (20180917-213736): Last Blade, The - Beyond the Destiny (Europe).ngc is dirty.

Rom 1F0000-1F07FF must be wiped with 0xFF to 100% work with save erasing. Otherwise when you reload the game, your last save can get eaten by rom. At least that's what happened to me right after the dreaded flash erase. If you save 8 more times, then you're okay again (no-intro image). I think that when the flash save is loaded, it's supposed to overwrite the rom sectors in memory image.

If you use a cleaned image, you're safe and won't get hit by the save bug.

I don't care to fix this part atm since I think upstream should make a better fix first, and repair the remaining 10% mess. But no-intro has a dirty rom with someone else's save data pre-loaded.

[ghost]

game save still oversizing...
doing "data clear" ingame now uses 528 bytes
still getting save corruption even with a clear rom save area (isnt this suppose to be overwritten anyways when save file is loaded, or cleared if its a new save file?...)

[stellarporter]

game still oversizing...

Tried Last Blade Europe just now. Cleaned rom. No previous flash save. Saved options about 127 times. Close emulator. 0x7F10 size flash file saved.

Opened game. Saved options. Old core hangs. Current core okay. Shutdown. 0x7F10 size flash file saved. With lots of 0xFF everywhere.

Opened game. Saved options. Shutdown. 0x210 size flash file saved. No save corruption noticed.

still getting save corruption even clearing rom's save area (isnt this suppose to be overwritten anyways when save file is loaded, or cleared if its a new save file?...)

That's what I thought but all my options were reset to rom defaults when reaching the 128 limit. Have to test again later.

doing "data clear" ingame now uses 528 bytes

Everytime you issue a data clear, it immediately writes 1 save. If you save options again, it adds 1 more save. On clean flash, that's 2 saves = 0x210 bytes = 528 bytes. Looks normal.

edit: Of course, I naturally could be overlooking something.

edit2: This game intentionally fills the entire block with save data. So it will naturally grow and eventually shrink when it hits the ceiling (VECT_FLASHERS). This is legal behavior on real hardware.

[stellarporter]

@marcrobledo
Any chance you can retest the crash bug?

[marcrobledo]

Sorry, I'm a lil busy lately :-(
I'll try to test it as soon as possible.

[ghost]

upstream fixed this and merged into libretro.

[ghost]

I can't trigger this bug in libretro, so I think it's fixed. Older standalone Mednafen had this bug but was fixed some time ago.