The md5 feature of mra files seems to be largely unused. Still, a way to tell users that their setup is wrong is needed. The current md5 implementation has these problems:
The md5 calculation seems to be done on the individual files and not on the file sent. If you use interleave sections, then the md5 calculation that MiSTer does is different from the byte stream that MiSTer sends. This is obvious when using tools that generate a .rom file from an MRA (like mra, orca or jtframe). The md5 for the .rom file does not match the MiSTer calculation.
When there is a mismatch between the md5 that MiSTer calculates and the one in the mra, MiSTer won't try to start the game leaving the user with a blank screen.
I suggest these changes to improve the user experience:
Calculate the md5 value on the data sent to the device, or on the data assembled before applying patches. This is useful because it catches changes in the mra files themselves, not just in the underlying ROM files.
In many cases, a wrong md5 may not prevent the game from booting, so MiSTer should try to boot the core regardless of the md5 comparison.
Leave the md5 mismatch OSD message on for a longer time, regardless of the ini setting. This is particularly useful if the game won't boot so the user knows what's going on
They are simple enough changes to make. However, there are enough MRA files using the MD5 feature as it currently stands that it would need to be a new element attribute.
The md5 feature of mra files seems to be largely unused. Still, a way to tell users that their setup is wrong is needed. The current md5 implementation has these problems:
I suggest these changes to improve the user experience: