About ROM checksums when loading replays from other machines

Scribe (37)

30-03-2022, 11:05

First of all kudos to the OpenMSX developers, replaying files from other machines works perfect (technically) - when done right - and allows very easy reproduction and diagnostic of freezes and other weird bugs.

Now about the "when done right" thing:
The OMR-file (replay-file) stores SHA1-checksums of ROMs that were inserted in the session, but it seems that these checksum are not tested when loading the replay. It loads any ROM on the listed path any starts the replay (of the recorded input).
Having the checksum in the file, I would expect to see an error or at least a warning when attempting to load a ROM file that differs from the one that was used when recording. Possibly provide an override switch in the "reverse loadreplay" command line like "-ignore_checksum" to force running the replay at own risk, rather than vice-versa.

I'm planning to use this feature to replay bug reports from recorded sessions from beta testers. Having such a warning before the playback would definitely help to recognize such inconsistencies, rather than wondering why different things are happening in the replay vs on the reporter's machine, just to find out that a different version of the ROM file was used. Of course, I could check the SHA1 checksum of the ROM with that in the file manually as well, but then, so could the Emulator ;-P

Can someone from the OpenMSX team confirm whether this was intentionally designed that way or if this is a bug (or just never was a use case).

By wouter_

Hero (535)

30-03-2022, 11:30

Hi mi-chi,
It's been years since I last looked at that code, so I don't remember all the details. But the intention was that it works like you described: either refuse to load or give a warning.
I'll try to look into this later this evening.

By wouter_

Hero (535)

30-03-2022, 18:28

Hi again,

I did some tests, and I do get warnings like this:
warning: The content of the rom /home/wouter/.openMSX/share/systemroms/nms8250-main.rom has changed since the time this savestate was created. This might result in emulation problems.

This warnings appears both:
* In the main openMSX window (in an orange message box, fades out after ~5 seconds).
* And in the terminal from which openMSX was started, or in the "Status Info" tab if openMSX was started from Catapult.

I'm using a recent development snapshot of openMSX, but I doubt this behavior changed recently. In other words, I would expect that the openMSX-17 release (and older) behave in the same way.

More in detail, this is how I tested:
* Create a (dummy) replay file.
* Rename the '.omr' file to '.xml.gz'
* Open this file in a text editor (many editors can directly edit .gz files, but you might need to manually decompress before and re-compress after your edits).
* Search for a tag named 'resolvedSha1' and change the sha1-value into some valid but non-existing value. This should be equivalent to trying to load a ROM file which is missing on the host machine.
* Load this modified replay file in openMSX (it's allowed but not required to rename '.xml.gz' back to '.omr').
This generates the above warning for me.

@mi-chi:
It's strange that you don't see these warnings. Can you explain in more detail what exactly you did? Maybe you can share the replay file and specify which ROM files were expected but missing on your system?

By mi-chi

Scribe (37)

31-03-2022, 01:05

Thanks wouter for your quick reply. That's interesting. I'm using openMSX 17, and already figured the compressed OMR file, as I needed to change the paths to the ROM file from the other system to match my dev system.

Did some more tests, and using a 16 KB ROM file and repeating the simple test you describe, changing the checksum manually, in fact shows the warning message.

I figured out what happens on my system, and why I don't see the message:
My ROM size is 272 KB (256 KB + 16), and when loading the replay, I see the overlay message "The size of this ROM image is larger than 256kB, which is not supported on real Konami mapper chips!", slowly fading out, but not the warning as in the 16 KB ROM.
It seems like if two warnings are stacking, only the first is shown (in that case, the size warning), and the second will never be shown (the checksum error).

That won't be that easy to fix, and this is indeed a rare case that probably isn't worth the effort addressing that. Will require concatenating all warnings into the one overlay message or queue and show them sequentially. I can live with it, as I know now what to check first :-D
Edit: Just recognized that you mentioned looking at the Status Info tab in Catapult, and in fact, it's shown there! Didn't know that this tab existed until now So there's nothing to fix here. Again, the problem was in front of the monitor, not behint it

Thanks again for looking at that so quickly!

By wouter_

Hero (535)

31-03-2022, 10:15

Fixing the "stacked warnings" problem may still be a good idea. I'll think about it.
Thanks for reporting!

By Manuel

Ascended (19685)

03-04-2022, 10:15

We fixed that problem Old messages shift down when new ones are shown. Thanks for trying openMSX and reporting this issue!