I wish it was as simple as removing samples
The 3 toaplan games mentioned (fireshark, tekipaki, vimana) were written to the mcu chip with the protection bit set, that means you can program the chip and the chip can execute the program, but you can't read out the data externally for an anti-copy/bootlegging measure. The chip itself is a beefed up z80(really z180) with ram & rom. Recently the chip was decapped (caps0ff.blogspot.com) and the protection bit was erased so the program code could be read out. It took under an hour to get all 3 games up and running with the new soundcpu code, because the drivers themselves were very similar to other toaplan drivers of the era.
On the other hand, Mario uses discrete / analog circuitry to generate its sounds. Mame has discrete and now netlist emulation, which allows for emulation of such analog circuitry. Even the simplest discrete and netlist stuff won't run on my mighty 3ghz p4 computer, so emulating it on the more compact devices such as the rpi is probably out of the question. On top of that, it would probably take a week and a half to graft such code into fbalpha for mario.. On the bright side, if you want to, you can sample mame or a real circuit board and add more samples to the game that are missing, using one of the first versions of mame as a guideline for the memory addresses where the samples are triggered.
The first versions of mame played the game fine with all the samples, but they were recorded so badly (hiss+static) they were removed over the years, then finally replaced with netlist or discrete. but thats a good starting point if you wanted to do such a thing.
best regards,
- dink
