Home Page Forums Other Emulator Message Boards Modeler and M1 Trying to replace a sound sample in Golden Axe

Yes, the problem is still there. I had tried windowed mode with Alt+Enter, now I tried it with -window. Also, MAME only works with -video gdi for me.
The frame rate and speed are normal. Also, if I press Insert (for fast speed), the sound is heard too fast to be sure :-}
Mind that the sounds are all OK during attract mode or gameplay. The problem happens only in the service menu. I hear something like "welwelcomecome...", but it's not always exactly the same, like the delay differs a little, every time. If I select to hear a song, the problem persists throughout the song, I hear it twice, with a small delay.
I just noticed something funny, if I press Alt+Tab (to select another window), the sound starts playing because Alt is the second P1 button, and I hear it correctly. It seems the sound starts playing, and because the window goes to the background, it doesn't start playing for a second time, so it's heard correctly.

I don't know what the MAME debugger does that is different to "normal" mode. All I can suggest is try either an earlier version or a later version of MAME and see if the problem is still there. I have MAME 0251 on my machine as well and it works ok. Maybe it is a sound driver issue?

That sounds a lot like MAME not running at full speed when using DirectSound. Did you hit F11 so you can see the emulation speed when this is happening? Bitmap output is expensive with GDI video, so if you fast forward it will run faster because it’s skipping that for most of the frames.

I just checked and it works fine in the latest version of MAME in full-screen.

Just to rule out another possibility, does this happen on a unmodified copy of the ROMs as well as your modified versions?

Yes, it's with any version, both sounds and songs.

That's it! I had to skip 4 frames, because the speed was at 65-70%, and it sounds normal!
My PC is a little old, it has an Intel Core2 Quad CPU Q6600 @2.40GHz and 8GB RAM.
All that time, I thought the game was running at 100% speed :-O

I have not made much progress, so I am going to try and explain the ADPCM format as I understand it and if I am wrong please correct me:

ADPCM takes an audio signal value and then tries to predict what the next values will be based on previous values. It then stores the difference between the signal values rather than storing the next value as-is, which reduces the number of bytes needed to represent the signal value. ADPCM can adjust the amount the signal moves (+ or -) to respond to fast or slow changes in the signal, which is helpful because it only has a small number of discrete steps to represent the signal (16) but they can be spread over a wider or narrower range to suit the rate of change in the signal.

I guessed that 0x53 tells the chip to treat the next 128 bytes (256 nibbles) as audio data. Is the next byte (2 nibbles) following 0x53 then used to calculate the signal position from 0 or a previously stored value? Assuming each nibble represents a signed value, this means that they can represent values between -8 to +7. We have two different values to get - the step size, and the movement within that range. This makes me think that each pair of nibbles must be used to encode both of these values unless there is some way to use the previous saved value with the first nibble to set both values, then the second nibble uses the first nibble, etc. This would make sense because the step look-up table has 256 values in it, and therefore only needs 1 byte to retrieve a value from the table. Some ADPCM formats use a header to set a step size every X number of bytes.

The look-up table for the steps used by the NEC chip appears to be different to the OKI look-up table, so I think this is why it is proving difficult to use existing tools to convert WAV files to the NEC format. It is also possible that the OKI values are using values outside the range that the NEC chip can use, generating random noise rather than the expected sounds.

I am going to continue looking at the driver in M1 and I will hopefully have some answers soon.

Don't be discouraged, this is very complicated and too hard anyway. Sometimes I'm totally disappointed when in a dead end, but sometimes a new idea comes up.
You may keep trying if you want, but if you don't have the time, never mind :-) Maybe a future, much smarter ChatGPT could do it by itself :-)

Me neither!
I have found four groups with four memory addresses that change when you select a sound or when you play a sound, that they are repeated 4 times, so it's 16 addresses.
In each group, one of these can take the values 00 or 0D or 35, for songs, sound effects and voices. The voices are the the ADPCM sounds.
Another one can take values 00-13, which are the ADPCM sound IDs and they are also shown like this in the service menu. Near that byte, there are equivalent bytes for songs and sound effects (but as I'm not trying to change any of these, I won't deal with them).
There is one more, that works in the same way, but the values it takes are 35-48. That's because 00-13 are the voices IDs are 00-13, but 00-48 are all the sounds IDs, including the songs.
All the above bytes change as you select which sound you want to play (in the service menu). There is one more, that changes as you play the sound. I don't know yet if that byte defines which sound will be heard, or if it just shows which sound is being played. It takes values 00-48, for any type of sounds. So, for voice 00, that byte would be 35, for byte 13, it would be 48.
I have yet to find the pointers to the sounds, I don't know where to look. In order to be able to add new sounds, I will also have to find how to change (the above) 13 to 14 and 48 to 49.
I don't have much time lately, but I'll keep on looking.

To find out when music or samples are triggered, you could use the MAME debugger and look for writes to the soundlatch memory address. This will tell you which instructions in the main CPU code are used to trigger the sounds.

If there is a single byte with a value that changes whenever new music or a new sound effect is played, that might be the soundlatch. You can compare the memory address you found with the code in the MAME driver for Golden Axe to see if the address matches. So, the main CPU writes a byte to the sound latch memory address and the sound CPU (Z80) plays the music or sample. The epr-12390.ic8 ROM has Z80 code in it at the start as well as data (for playing the music?) and these instructions and data are then combined in memory with the ADPCM samples in the mpr-12384.ic6 ROM but the sample data is accessed at a higher memory address. So, the Z80 must be able to look at the address in the sound latch and know whether it is supposed to play music or a sample because it has to send instructions to the music chip or the ADPCM chip. I am not sure how it does this.

When I have time I will keep trying to understand the ADPCM code... at least I am learning something

People tell me I'm losing my time with romhacking, but it's exactly what you said!

I know about epr-12390.ic8, and I have been comparing trace files. But I don't just want to trigger a sound (that's a very important part of course), but to also change the service menu, so that you can select any new sounds. I've also looked at how the memory changes, that's how I found the 16 bytes that change, depending on the sound selection.

In fact, there are five things I would like to do:
1. Convert sounds to NEC ADPCM, so I can replace the "welcome" sound.
2. Find the sound pointers and be able to move them around in the ROM, to take advantage of the available space.
3. Add new sounds.
4. Play the sounds in the game.
5. Adjust the service menu so it shows the new sounds.

Obviously that's optimal, I'll be more than happy with replacing a sound :-)

Changing the service menu and playing different sounds in the game is going to be much more involved since that lives on the 68000 side. Most Golden Axe sets are encrypted by a dynamic scheme and would be very difficult to change.