The extensions of Sega Genesis ROMs

[happy-ma]

Summary

Recently I have updated Bizhawk from 2.4.2 to 2.11. With the newest version, SMD files cannot be loaded. It is unbelievable that they can be loaded if their extensions are changed to other supported types such as MD, GEN, BIN, etc.
The above problem does not exist in 2.4.2. I wonder whether it is a bug or it will work if some configurations are changed.
All of my Genesis ROMs are named as *.smd. I do not really want to rename them with another extension.

Output

There was no response after *.smd was loaded. The window of emulator was black!

Host env.

• BizHawk 2.11; Win10 Home; Intel/NVIDIA
• BizHawk 2.4.2; Win10 Home; Intel/NVIDIA

[CasualPokePlayer]

Looking at the code, .smd is still accepted as a file type for Genesis games.

The window of emulator was black!

What happens if you enable Display Frame Count in View? Does the frame counter increase? Or is it not showing regardless?

[happy-ma]

Thank you for your reply, CasualPokePlayer!
Although I have not read the codes, I believe that .smd must be an accepted type.
I enabled Display Frame Count. The counter increased at the top left corner after I had opened several ROMs with SMD extension or others.

You'd better try to do the following steps by yourself, I'm afraid.

• download 2.11
• open a (genesis).smd
• open the same Rom with other accepted extension or unaccepted one (you have to compress it into a ZIP file if the extension is not an accepted one)
  If your SMD file works, I shall check whether there are other problems...

[CasualPokePlayer]

I would suspect the issue is just that your ".smd" files are not actually .smd files but rather renamed .md files.

.smd files are not normal ROMs, they're the result of some ancient copier which arranges the ROM in an interleaved format. BizHawk handles this by de-interleaving an .smd before sending it to the core.

That de-interleaving should not occur for actual .md ROMs, as that proceeds to break them. So your .smd files that are actually renamed .md files proceed to break with this handling.

I would suspect 2.4.2 just had this handling broken (i.e. didn't de-interleave .smd files like it was supposed to) so in theory .smd files were just broken in those versions, while later versions "fixed" it, which proceeds to break these .smd files that are not actually .smd files but instead renamed .md files.