How to edit a type of sound file used with a fruit machine emulator?

Question

I have two files that have the extension .P1 and .P2

These files are ROM sound files from a particular 'real world' fruit machine (also known as a slot machine).

There is some Fruit Machine emulation software (MFME) that reads both the sound ROM files and the game ROM files in order recreate the fruit machine within a PC.

I'm playing around creating my own fruit machine with the editor side of MFME, based on an existing fruit machine, and want to edit the sounds on this machine.

Unfortunately MFME doesn't have the functionality to edit sound files, only to read them.

The sound ROMs are apparently comprise of all the sounds packed one after another with a table at the start pointing to where each sound file is (lots of short beeps, buzzes, pings etc as you would expect from a fruit machine).

Does anyone know what software I would need to edit these files in order to insert my own sounds? I originally thought I would need a disassembler but when I downloaded one it wouldn't open them as they weren't either .exe or .dll files (I tried changing the extension of the file but the disassembler still knew they weren't the correct type of file).

How can I go about reverse engineering these files in order to edit them? Any ideas?

Thanks. :-)

Answer 1

The MFME source code is available to read.

You'll probably want to start with interface.cpp, which has most of the logic for deciding which sound format to load in TForm1::Load(String). There are at least ten or so different formats from the look of it.

You can then take a look at sample.cpp which has the implementation for loading files. LoadJPMSound is of particular interest, but there are other formats to consider.

Here are the key facts for JPM sounds:

• File starts with a 1-byte sample count prefix (so I guess 255 samples max?)
• Next comes a 4-byte magic number (0x5569A55A)
• After that there's some sort of page table which describes the addresses of the sound data within the ROM.
• Each audio "page" has a 1-byte flag value at the start. The two MSBs specify the kind of sound.
  • 00 means silence, where the remainder of the byte (i.e. flag & 0x3F) specifies how long the silence should be in increments of 20 samples. A zero value here means an empty audio sample.
  • 01 means there are 256 "nibbles" of audio. I'm not sure if this means 4-bit values but I haven't seen any bit manipulation in the decoding. The sample rate is set to 160000 divided by the remainder of the flag value plus one.
  • 10 means the same as above, except the number of "nibbles" is stored as a byte following the flag.
  • 11 means that the sample is a repeating loop. The number of repeats is computed as (flag & 0x7) + 1.

For YMZ samples, the file contains 250 sample entries, each consisting of:

• 16-bit masked sample count, compute as count = (((value & 0xFF00) >> 8) / 6) * 1000
• High byte of buffer pointer.
• High byte of sample pointer.
• Mid byte of buffer pointer.
• Mid byte of sample pointer.
• Low byte of buffer pointer.
• Low byte of sample pointer.
• Sample data in the following format:
  • 4-bit YMZ280B format sample data (channel A)
  • 4-bit YMZ280B format sample data (channel B)

The YMZ280B format is step-based format where each next signal value in the wave is encoded as the difference from the previous signal value (or 0 for the first sample). The 4-bit value is an index to a lookup table containing the possible steps: The step LUT is calculated as follows:

// nib from 0000 to 1111
for (nib = 0; nib < 16; nib++) {
    int value = (nib & 0x07) * 2 + 1;
    diff_lookup[nib] = (nib & 0x08) ? -value : value;
}

That should hopefully get you started. The source code should get you the rest.