Write uncompressed data for states and nvram

[eadmaster]

Followup

This should help sharing the nvram files with MAME and other emulators.

[coyonut]

It would also make it easier to use those files in programs that read score files. Many games save those scores in the nvram (fs) or saveram file.

[barbudreadmon]

I remember looking further into this, iirc it turned out that even if the data was uncompressed, in many systems there would still be inconsistencies between MAME and FBNeo nvrams, which defeat the purpose of uncompressing them tbh.

[coyonut]

I was thinking of taking advantage of what the hi2txt program does with those Mame nvram and if it were possible to do it with FBNeo and its fs or nv. Do you see any possibility? Would those differences make it impossible to use it uncompressed? It would be great to be able to get the valid data to work as well as it does with .hi (also from FBNeo) or Mame nvram files. In the end the data of scores inside those nvram should be the same in Mame and FBNeo, shouldn't it be?

[barbudreadmon]

Do you see any possibility?

None that wouldn't definitely break compatibility with older nvrams, which is a deal breaker.

[coyonut]

yes, it seems logical to maintain backwards compatibilities. maybe as an alternative save format or so that hi2txt can read and understand fs files. Thanks for answering barbudreadmon ;)

[barbudreadmon]

I've an idea to remove headers and uncompress data without breaking backward compatibility, so i'll try to implement it to lessen the discrepancies and ease the parsing of those nvrams, but the compatibility with MAME nvrams for all emulated systems won't be guaranteed.

[coyonut]

Great barbudreadmon. I hope you get it. Any progress will be welcome, even if it's a handful of more supported games. Thanks!

[barbudreadmon]

Libretro port should be fine with https://github.com/libretro/FBNeo/commit/44fabff39fea401297246fe8ad9f0c9aec2658fb

@dinkc64 @tmaul @0xe1f Maybe it should be backported to other ports ? Compiling the src/burner/nvram.cpp file i added a while ago is also required.

[dinkc64]

Not against the idea, I just don't want to do it until I understand the system better.

[iq132]

What about an option to load/save mame nvram (if supported)?

On Tue, Jul 5, 2022, 9:30 AM dinkc64 @.***> wrote:

Not against the idea, I just don't want to do it until I understand the system better.

— Reply to this email directly, view it on GitHub https://github.com/finalburnneo/FBNeo/issues/759#issuecomment-1175063902, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJC6HJFNRWX4GKB63HOOXDVSQ2IZANCNFSM43AWZKIA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[barbudreadmon]

Not against the idea, I just don't want to do it until I understand the system better.

Nothing fancy :

• when loading i try the newer unheadered/uncompressed format first (using BurnNvramLoad), then fallback to the headered/compressed format (using BurnStateLoad)
• when saving i always use the newer unheadered/uncompressed format (using BurnNvramSave)

That way, nvrams get automatically converted to the unheadered/uncompressed format when loading a game.

What about an option to load/save mame nvram (if supported)?

Not against the idea, the unheadered/uncompressed format is way bigger (my 500B neogeo nvram became a 65KB nvram) so it feels like wasting disk space tbh.

[dinkc64]

I'm just worried about the bugs that will come with those changes.... I make more bugs when I actually write code :P

btw there probably is no change in disk usage either way (cluster size)

best regards,

• dink