Midway ADPCM hacking guide

1 week 3 days ago #1010 by docwallace
I've been threatening to do this for ages, and if I put it here, then there's no chance of this getting forgotten if I get hit by a bus or something.
WARNING: This is going to be LONG, so if the technical side of this doesn't interest you, you may want to save your time.

I've been looking at the Y and T Unit ADPCM sound board for some time, and the TL;DR is that we can now add new ADPCM samples, and amend the ROM code accordingly to do it.

I've described the basic process in videos before, but for one reason or another I'm unable to record right now in a format that isn't ridiculously low resolution, so the best way of describing this is here.

There is a document I'm building up at docs.google.com/document/d/1_49G0IsOiZ-O...jnw/edit?usp=sharing , but this is the simple version.

Essentially, there's a load of header magic in bank 3 of the U3 ROM, which for Mortal Kombat is starting at 0x20000 in the file. What you have to remember at all times is that that is mapped into the CPU at 0x4000, so wherever you see pointers back to a 0x4000 region, that is actually the 0x20000 in ROM. In the MAME debugger however, where the ROM is mapped in place, the adpcm:cpu memory window will show it in the correct place. I'll use the 'correct' internal values in the main here, and point out where things differ for those looking at the ROM in a hex editor, but in the main the conversion is very simple.

Also note that in this post, I'm going to refer exclusively to the SL1 version of the ROM, which is the untouched original from the standard MAME set. Obviously for Plus, when people have messed with it, some of this stuff will have changed as tables get moved around, expanded etc.

Sound board operation
The main program communicates with the sound CPU by copying bytes to one specific area of TMS memory space, that links serially to the sound board to act on, so the commands are short. In fact, every sound, speech or music cue is triggered with at most 2 bytes written to this serial space.

In the sound ROM, there are two tables of lookup data for interpreting these commands, one for if there's one byte (or a 2 byte 'word' starting with 00) and one for 2 byte 'words' starting with 7A.

To find where these tables live, check 0x400f and 0x4010 for the first (remembering that's actually 0x2000f and 0x20010), and 0x4019 and 0x401a (0x20019 and 0x2001a) for the second. This will give a word, read with most significant bit first, so 40 5E means looking at 0x405e, which as I've mentioned before is 0x2005e in the file. This is the base value.

Part 1: Command processing
Since each entry in this table is a word itself, take the command byte, multiply by 2 and add to the initial
base value to find the place. For this example I'm going to take the first ADPCM sample in the sound test which is the SMACK! sound. This has the command code 36, without the 7A prefix. so we're looking at the first offset table, which starts at 0x405e.

0x405e + (2 * 0x36) = 0x40ca.

Reading this (0x200ca in ROM) gives two bytes in succession, 07 06.

The first byte is a type designation for the sound command:

01 = MUSIC
04 = DAC

So 07 tells us, yes, this is a sample, and we need the sample data table next.
The entry offset for that table is the second byte, 06.

Part 2: Sample Table
There's only one sample data table, and that's found from the header again, at 0x400b and 0x400c
Looking at those in ROM (following our conversion rule 0x2000b, 0x2000c) gives 4416 - which is our base for the sample table.

0x4416 + (2 * 0x06) = 0x4422

Going to that space (in ROM 0x20422) shows a word that looks very much like a jump address (46 2A), because it is.
We go there (0x2062a) in this case, and there's a 4 byte sequence, 01 06 00 FF

The 00 FF seem to be ignored, as there's only two parameters here that need to be configured. Taking those first two bytes:

Byte 1 is the voice to use on the ADPCM chip, there are 4 in total, and playing a sample on a voice in use will cut that sample off to start the new one. To that end, you'll see a number of commands that are basically identical except for the voice byte to allow for mixing.

Byte 2 is yet another offset into a data table to actually find which sample needs to be played. This may seem strange, but because of the duplication mentioned above, this can be used to compress those near duplicate entries to reduce the amount of bytes needed to store the data, separating the changing part. Coincidentally, this offset is also 06 like the last one, but this is not always the case, and it has nothing to do with the offset we used to get here.

Part 3: Sample Table 2
This third lookup table used is defined, yet again, in the header at 0x4015 and 0x4016 , which when converted and looked up gives the word 4a26.

Using the same equation as before:

0x4a26 + (2 * 0x06) = 0x4a32

Looking at that space (in ROM 0x20a32) gives a jump address, 4B66

There is a 5 byte sequence 01 03 07 00 A5

01 is the bank in the ADPCM ROM combination (U12 and U13), 03 seems to be a priority byte to decide what to do about actually playing a sound or not if its a voice in use, 07 is the sample number in the bank, and 00A5 is the length of the sample in ticks, to allow the system to figure out roughly how long to play it before allowing interruptions etc.

With the tools already built to add samples to the ADPCM ROM, changing values in these tables to convert unused samples to point to new data is relatively straightforward, if time consuming, and with the amount of space left in U3, there's certainly potential to add a few little things of interest ;)

Please Log in or Create an account to join the conversation.

Created by ZPaul2Fresh8

Go to top