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

M1 emulates the Z80 sound chip and puts a value in the sound latch memory location (0xE800) to play the sounds. In M1, the track list for Golden Axe is manually written and you can change it if you want. If this list is deleted or does not exist, when M1 starts it will put 0x01 in the sound latch and (maybe) play a sound if 0x01 is valid. When you select the next song, it will put 0x02 in the sound latch and try to play a sound. You can continue up to 0xFF. The starting number and end number are defined in m1.xml but the number cannot be greater than 255 because it has to fit in an 8-bit memory address. M1 does not know if the sound values are valid, so you just have to try all possible songs until you find one that works. Also, M1 does not know what type of sound it is supposed to play, it is the Z80 that controls everything.

I do not know how the Z80 chip knows whether to play music, a sound effect, or an ADPCM sample just using the sound latch value. To find out you would need to disassemble the Z80 code and look for any code that reads 0xE800. Then, I would assume it will jump to different places in memory using this value. The rom you mentioned before (epr-12390.ic8) contains the Z80 code, so it has access to the bank information.

I was able to add a (noisy) new sound to the ROM using SoX - I used the SEGA logo sound from Sonic the Hedgehog Audacity still does not work for me - I always get an error message when I try to export to VOX. Hopefully there will be some progress soon - I found some more code examples with comments for other ADPCM codecs that I can look at.

The usual way a sound driver like that works is that the codes from the latch select sequences from a table. Sound effects or voices are a sequence with just one or two notes. That way the code is very straightforward, and you have maximum flexibility for something like the "Sonic spills his rings" sound where there's a short burst of a bunch of notes, but it's still technically a sound effect.

Thank you, I will check that.

I noticed in the Z80 code that the 0xE800 memory location isn't referenced directly anywhere in the instructions - there is no "LD A,(E800)" like I was expecting. I found one byte at 0xF814 that appears to be a volume value(?) and the values in this byte also appear in the sound latch sometimes so I think the sound latch is also being used for volume control.

Set a watchpoint on e800 on the Z80 for reads and then cause the game to trigger it.

I did try that but nothing happens. For example, if I do this

wp 0xF814:soundcpu,1,r,1,{ printf "0x%x set with data 0x%x\n",wpaddr,wpdata ; g }

then I get the expected result, such as


but when I do this

wp 0xE800:soundcpu,1,r,1,{ printf "0x%x set with data 0x%x\n",wpaddr,wpdata ; g }]

nothing gets triggered even though I can see the value changing in the memory window?

Hi, I have a small update: I found out how the service menu plays the selected sounds and I finished that part.
The sound ids are 41 to 54. When you push the button to play a sound, the value is already written in D1, but it doesn't use that. Instead, it looks it up in a table. Here are the bytes of the table:
41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 00 4E 71 4E 71
It's obvious, isn't it? There is room for 5 new sounds. If there's a need to add more than 5 sounds, I could change the code so it doesn't use the table, but the D1 value.

This means I can now do any changes I want to the sounds, and the only thing that has to be done is the most important, to be able to create NEC ADPCM sounds :-0

By the way, I inserted one of the sounds I found online from that "Mk VII Warning Computer" device (from here: https://rutube.ru/video/87049aff131218a5d9bc3122fd866cc9/), just to check.
The sound quality is incredible! It's almost like hearing a 44100 Hz 16-bit sound!

Do you think it would be a good idea to create a GitHub repository to document this information? I think it would be a good reference tool for other System 16 rom hacks. If we include such things as a disassembly of the 68000 and Z80 code, we can add information to it as we understand more about the code. I have been using Ghidra to disassemble some other roms and the output is quite helpful because it creates hyperlinks whenever there is a jump or call to different areas of memory, and it has some other features such as being able to assign names to memory locations. It also does decompilation to C code, which is useful for understanding what the machine code does even if the compilation is not 100% correct.

Anyway, it is just a suggestion. The reason I thought about this is that I need to start documenting the APDCM encoding process using a flowchart or something similar so that I can understand the process better.

For years, I was just releasing the translation, with the exception of Kick off 2 for the Amiga (I wrote two tutorials). Any notes were on paper and if I was happy with the result, I wouldn't keep them, the goal was the translation. Some years ago, I kept the notes for Micromachines for the SNES as it was really complicated, but unfortunately I lost them. That time, I managed to change a sprite from small to large (SNES has two types of sprites), which was something I couldn't find anywhere else, it was something I did myself. With the arcade Mighty Bomb Jack, I managed to add code in the graphics chip. These things are worth documenting, for other translators to use in that game, or for a romhacking trick in general. I'll probably write a tutorial for this one.
This time, with Golden Axe, I decided to keep notes in a file instead of paper (even though they are in Greek). Romhacking.net used to be the best place to find documents and notes, but it has stopped updating. I will definitely release my notes and maybe write a tutorial for changing the sound, but I don't know about a repository, we'll see.
The GreekRoms webpage is awful and we have to create a new one sometime, maybe I should make one soon and organize everything better there.

Testing an OKI codec today, I noticed something interesting:



The parts of the sample that look "normal" play ok in M1. The noise in the middle appears to be where the sample hits the upper or lower end of the audio values and then is clamped in the wrong direction. The noise at the start is possibly due to the wrong prediction values being calculated or the ADPCM default "state" not being correct. It seems that the first few samples are random to some extent because the encoder does not have enough samples to work with.

I adjusted the state table values from the OKI defaults to the 7759 default and the sample plays back at the normal volume (but with noise in some parts of the sample).

This is a big step!
I think some parts of the code should also change. Or maybe another ADPCM variant would sound better with the 7759 defaults. You would have to do something similar with different ADPCM variants (if you find the code first), but the result could be the same, who knows...

I searched the Internet some more. I was expecting to find different and rare ADPCM variants in Aminet (https://aminet.net/search?query=adpcm); I did, but I didn't even setup an Amiga to check, as they are different.