F3 sound

The issues with F3 sound were intriguing.
These games all use essentially the same sound program, with minor variations, which appears to be a generic MIDI player.

The hardware is capable of driving a large amount of ROM data - more than the ES5505 is capable of, so the ROMs are banked, in 4 or 8 banks depending on the player version. The ROMs are actually half the amount of banks, because every ROM contains two banks (apart a couple of exception games that use smaller ROMs).

At the beginning of each bank, the ROMs contain a standard header that the program reads on startup to see what samples are available. Therefore, the order how the ROMs are loaded isn't strict - if you swap two of them, the program will still know which one is which and play the correct samples anyway.

However, there's a catch. Most of the games have one ROM containing standard samples (the same in all the games that have them) and those samples are stored differently from the others (there is no header), so the program cannot recognize them. The program just expects those standard samples to always be stored in the last bank.

Discovering this was important to fix sound in a few games - for examples Space Invaders DX, which was missing music.

However, it still wasn't enough to fix all the problems. For some reason, ROMs loaded in bank #4 were not recognized properly, so they were ignored by the program. After some studying of the ROM detection function, I finally found the not-so-obvious cause.

Usually, 68000 programs have ROM starting from address 000000, because that's where the reset vector is located. This program, however, for some reason works differently, and ROM is located higher in memory while RAM is at 000000.
The 68000 also has a special instruction to move data in its address registers, called MOVEA. It is different from MOVE because a MOVE.W will just affect the bottom 16 bits of the destination register, while MOVEA.W will sign extend the result to 32 bits. Therefore,
MOVEA.W #$7FFF,A0
will put #$00007FFF in A0, while
MoveA.W #$8000,A0
will put #$FFFF8000 in A0.

What was happening with the program was that the data read from the ROMs went to a buffer starting at around #$006000, and continuing onwards until it crossed the magic #$008000 boundary. When it did, the program would begin writing data at #$FF8000, but read it back from #$008000. This is what is called a "mirror address" - different addresses that map to the same chip on the board. The FF8000-FFFFFF area was mapped in the driver, but not as a mirror of 000000-00FFFF. Once that was fixed, the program started properly recognizing all of its ROMs.

I have checked all the games, looking at the ROMs to make sure they were in the order expected by the game, and playing them to look for obvious problems, and I couldn't find any, so now all of the F3 games should be sounding pretty good.

In the process, I also discovered that Quiz Theater was missing sound because of a bad ROM. I was able to partially repair it because most of the damage was in a portion which is common to other games, however there are still some parts missing so some sounds willnot play as they should. Ring Rage and Riding Fight still have no sound, however in this case I believe it's an emulation issue. Both of these games use a very old version of the sound program, possibly the earliest revision, so it might behave a little differently from the later ones.