SCC don´t work in SCC Games.

Mars2000you, you're right. Is Nemesis 1 not 2.
Was my mistake, sorry.

How do you mean it’s not real hardware? I got a real Snatcher Sound Cartridge right here on my desk… It’s got a real mapper in it which switches either an SCC or SCC+ into banks 3 / 4. The only difference with any other Konami ROM is that the internal memory is volatile in stead of persistent, and that the memory is writable under certain conditions. Similarly I also got a MegaFlashROM SCC+ SD, persistent but writable under certain conditions. EEPROMs are also writable under certain conditions, does openMSX not support those?

(By this I mean to illustrate that there is no clear distinction between plain ROM, EEPROM, FlashROM and “volatile ROM”. If you look at the term Read-Only Memory, this memory can not be written to under normal conditions, so for the intents and purposes of the software running on it, it is a ROM cartridge. And it has a unique mapper so it warrants introducing a separate mapper type for.)

As said, I don’t think it is really a matter of real or fake hardware, but just a matter of how the emulator allows the contents of the memory to be initialised. OpenMSX has a feature to allow a ROM chip’s memory contents to be specified on the command line, I’d like it to also allow initialising Snatcher SCC+ memory chip in the same manner.

I gave the “take out and plug in” example to illustrate that I can load software on to the Snatcher SCC+ on one MSX, and then play it on another, to illustrate that this memory content is persistent for a while and can be transferred physically and plugged in to another MSX. So, as the cartridge is pre-loaded with software, this would be equivalent to specifying the software on the command line.

Anyway I’m just argueing for this feature cause it would be very useful for me in development. Being able to immediately load the software cuts my iteration time by a significant factor. I only support SCC in stead of SCC+ right now because that is the only chip I can develop for conveniently, even though on a real MSX I would run it on an SCC+ cartridge.

I think you're trying to play the SCC version of Nemesis, launched on Konami Game Collections. There are several roms of this game and only one works right, the other doesn't sound with SCC. The other games appeared in Konami Compilations with SCC sound like Knightmare or Twin Bee has the same problem: only one rom is correct, all the rest doesn't works right.

To avoid this problem you can use the original Konami Compilations DSK images (launched on disk) and have SCC inserted in slot 1.

I think that is too narrow a definition of what a ROM file is. A ROM file is really just a piece of software, which is expected to run in a read-only memory environment. What you do on the openMSX command line is say “I have this software and I want to run it with this mapper” (or infer it from the hash). I don’t think there is or should be a rule that a ROM file can only contain software that was ever physically distributed on a ROM chip.

Would it really be any different from how ROM files are loaded now? Just add a new command line option to specify a KonamiSCCPlus mapper type, I would say.

As said, I use it for development, and generating a disk image which loads into a SCC+ would quadruple the loading time and thus be very impractical. Btw, those “ROM hacks”, I assume they aren’t cooked up by anyone, but just straight copies from the ROM files on the Konami Game Collections discs that get loaded into the Sound Cartridge? (I assume that’s how the Game Collections work…)

@Manuel Let me phrase it differently: Is this a matter of principle, or would you say, accept patches that add support for this if one were so inclined to write one?