Introduction

This is a guide to how I hacked Alex Kidd in Shinobi World to find its hidden
music. I’ve got quite a lot of experience in hacking games, and I’ve been able
to streamline the process, based on my experience and also because there are
now tools available which make it much easier than it used to be.

The game

Here is the target. While the VGM pack was made a long time ago, a forum thread
revealed that there are some unused tracks in the game, so I decided to hack it
and make a guide at the same time.

The method

My experience has shown me a few things:

Music engines are usually fairly independent from the rest of the game

The game code thus usually controls the music engine using a single-byte variable in RAM

This control variable is usually close to the other RAM used by the music engine

This RAM variable’s value is very often (but not always) something like $81 - ie. a small number with the high bit set.

Modern advanced emulators include one very useful feature: memory
viewers/editors. These allow me to see what’s in memory and to change it while
the game is running. I’m going to use this to make a music hack.

The guide

1. Open the game in the emulator.

2. Open the RAM viewer.

I’m using Meka, but
Emukon is just as good. To open it in
Meka, click on TOOLS - Memory Editor:

Then click on the RAM button to jump to the start of RAM.

As the game plays, you should see the values changing.

3. Find the music RAM

Scroll through the RAM while the demo runs, and music is playing. You are
looking for the music engine’s RAM. The way to recognise this is to notice that
music RAM changes very quickly and tends to all be in a relatively small
block (less than 512 bytes). This is because music is complicated - the engine
has to handle effects like vibrato, volume envelopes and fading on three
channels at once, and music changes notes many times each second - and, as
noted above, generally independently developed so it has to keep to a small
area of RAM to avoid clashing with the rest of the game.

It is also easy to recognise because it should be changing exactly in time with
every change in the music.

Scroll a page at a time through the RAM, either using the mouse wheel or the
Page Up/Page Down keys. If the game demo starts, a lot more RAM will
be actively used by the game engine. Just reset the game when this happens (the
Backspace key) and wait for the music to start before resuming the
search.

You should eventually find it at about offset $de00. (See hexadecimal explained if this doesn’t look like a number to you.)

4. Find the track control byte

Now comes the detailed searching. Make the game run until just before a
point where it changes the music. Save the game state (the F5 key)
about a second before it changes. Then look closely at the music RAM.

Load the game state (the F7 key) and look closely; you’re looking for one
of the following:

A value that is constant before the music changes, then changes at the same time as the music, and is then constant, or

A value that is constant (often $00 or $80) before the music changes, then has a value for one frame only, at the moment the music changes; it then goes back to “nothing”

You should definitely set the frameskip to 1/1 to be sure of being able to see
the second one; alternatively, a slow emulated speed such as 20Hz makes it
easier to spot. In our case, it’s not too hard; I can see that offset
$DE04, just 4 bytes in, seems to be acting as described in the second
case above. This isn’t surprising - it makes sense for the control variable to
be near the start, since it would be one of the first things written in the
music engine.

Click on it so that it is highlighted and the address of that byte will be
displayed in the lower-left corner. Make a note of it, so you can tell us about
it once you’ve finished.

5. Write to it

Next, we are going to write a new value to this address. The value I will write
is $81. This is often a good value to try. While the
correct address is selected, enter a new value for the byte by typing in the
two hexadecimal digits (8 and 1). (Again, you may need to set Meka to 1/1
frameskip to be able to type.) After you type the second digit, the value is
written and the highlight moves to the next byte. You will also notice that

The value we just wrote is changed to zero by the game

The music changes to the Level 1 tune.

This shows that we have found our variable :) This address is a write trigger - writing a new value there causes the music to change. This is the
easiest kind of music hack because it doesn’t require us to even look at the
code!

6. Isolating the music

When ripping VGMs, it’s better to log the music with silence at the start (it
makes trimming easier) and with no sound effects playing over it (since they
ruin the music).

To make silence at the start, try writing different values to the music control
variable. Ones to try include:

$80 - some games use index 0 for silence

$00 - it is easy to test for in Z80 code

$ff - another “nothing” value

Finally, see if there is a short piece of music that does not loop - perhaps a “level start” or “death” sound. You can play it to stop the current track, and when it finishes you have silence.

For Alex Kidd in Shinobi World, writing $ff works well.

To avoid sound effects we have several options. First, we can use the
Pause Hack for SMS games. Meka includes a version of
it in the meka.pat file, using the [*] selector to make it apply to all
games. Open that file in a text editor and find it; remove the semicolons “;” at
the start of the lines to make it active, and save the file.

[*]
ROM[0066] = FB, 18, FE

Next time you run Meka, any game you run will have this patch applied; when you
press Pause, it will make most (but not all) SMS games hang, but not stop the
music. This is also useful to stop any slowdown of music due to the game engine
using up all of the CPU time. Don’t forget to re-add the semicolons when you
finish to avoid it making all games hang when you pause.

A second choice is to play the game a bit and find somewhere where sound
effects do not happen, and the music does not change. Try when the game is
paused, or an options screen. Even if they don’t have music, the music engine
may still be active - try writing a value as described above in these
situations and see what happens.

For Alex Kidd in Shinobi World, the Pause hack works well. With both, you are
able to change the music while it is playing, so there is no need to exit the
emulator, edit files, load and save states or reset the game each time you want
to rip a different track.

7. Rip the VGMs

And there we go. We can go through all of the possible values for the music
engine, write them at $DE04, and they will play. By pressing the left arrow key,
the highlight can be moved back to $DE04 after writing each value, before
writing the next. We can then list what each value does and rip the music. In
most music engines, the lower numbers are music; the higher ones are sound
effects, and too-high values will either produce silence, random sounds or
crash the game. It’s always worth checking all the possible values, though:
there may be some music tracks mixed in with the sound effects, and there may
be some invalid values mixed in with the valid ones.

Write down the results because they might be useful in case you need to re-rip
the music. Here are the Alex Kidd in Shinobi World sound engine values:

$80

No effect

$81

Level 1

$82

Level 2

$83

Level 3

$84

Level 4

$85

Level Start

$86

Death

$87

Boss Music

$88

Level Complete

$89

Unused music

$8a

Continue Screen

$8b

Unused music (short)

$8c

Unused music (short)

$8d

Congratulations To You, Alex

$8e

Intro

$8f

Unused music

$90-$b4

Sound effects

$b5-$b6

Silent

$b7+

Errors

Hexadecimal explained

Normal (decimal) numbers count from 0 to 9, before increasing the second
(“tens”) digit. We use this “base 10″ system because we have 10 fingers.
Hexadecimal (often abbreviated to “hex”) numbers count from 0 to 9, then A to
F, before increasing the second (“sixteens”) digit. This “base 16″ system is
used when dealing with computers because it is compatible with binary numbers
(base 2) which computers use. It’s compatible because one hex digit corresponds
to 4 binary digits, so one byte can be represented by 2 digits.

You can convert between hex and decimal (and other number bases) using a
scientific calculator. Windows’ calculator will do this quite easily.

If a hex number happens not to contain any letters, you wouldn’t be able to
tell if it was decimal or hexadecimal. So various notations are used to signify
a hex number:

Put 0x before

0xc621

Put $ before

$c621

Put & before

&c621

Put h after

c621h

I tend to use the second (used in most Z80 assembler code).

Also, the case of the letters doesn’t matter. It’s just easier to type $c621
than $C621.

Finally, it is common practice to write out any leading zeroes according to
the possible values of the number in question. For the Master System, an address
is in the range $0000-$ffff, so you could write address $66 as $0066. A byte is
in the range $00-$ff, so you will often see zero written as $00, for example.

Binary explained

Binary is just another number system, but one that’s simple enough for a
computer to understand. It only has two numbers - 1 and 0 - so you have to
increase the next digit to the left instead of getting a value of 2. In binary,
1 + 1 = 10; 10 + 1 = 11;
11 + 1 = 100, and so on.

So you know that a binary number is binary and not any other number system, the
convention is to write it with a % sign in front of it, so:

%10101010 = 170 (decimal)

Obviously this lack of confusion over notation compared to hexadecimal was a
mistake, which is made up for by the confusing way you refer to parts of binary
numbers.

Each digit (1 or 0) in a binary number is called a bit, which is short for binary digit.

When you want to refer to a bit, you count from the right and start with 0. So, in %01110110, bit 7, bit 3 and bit 0 are zero, and there is no bit 8.

In a (decimal) number like 8463, the 8 means thousands, the 4 means hundreds, the 6 is tens and the 3 is “ones”. You knew that. Well, obviously changing the 8 is going to mean more difference than changing any of the others, and the 3 is least important in that respect. Similarly, the leftmost digit in a binary number is the most significant bit (MSB) and the rightmost (bit 0) is the least significant bit (LSB).

The MSB is also called the high bit, and the LSB is called the low bit.

When a particular bit has a value of 1, it is called set. When its value is 0, it’s called reset.

Again, it is common to write out leading zeroes, so you will see %00001000
instead of %1000. Most of the time, we only write in binary when there aren’t so
many bits that it becomes impractical - so it’s usually not used for more than
16 bits.

About the high bit being set

In my experience, the majority of games’ music engines work using control
values where the high bit is set. This means that the values passed to the music
engine are simple numbers selecting the music from a list (1, 2, 3, ...) but the
numbers have their high bit set, so they become ($81, $82, $83, ...). The music
engine does a first check on the value by checking if the high bit is set. If
it isn’t, it rejects it. It then resets the high bit and uses the value as an
index into a lookup table to find the music data, and begins playing.

I can’t think of a good explanation for this, but it is generally true,
especially for games made by Sega. Since $80 is often used for silence,
$81 is generally the starting value. When hacking a music engine, pay attention
to the parameters being used by the game; if it is always using values like
$8x and $9x then you’ve got a high-bit engine; if it’s using $0x and $1x then
obviously you haven’t. (Try slowing down emulation, and/or using the emulator’s
“run for 1 frame” option (Alt+F12 in Meka), to spy on values being
written to a particular address.)

When you’re writing values, note that if the currently playing music is number
$81, writing $81 might not change anything. So if nothing happens when you
expected it to, try $82.

Postscript

There are lots of different ways for music engines to work. This guide only
covers one of them. Hopefully I will be able to add to this guide when I hack
different types of music engine, but this is the most common type, especially
in first-party Sega titles, so it should set you on your way to hacking games
yourself.

The main alternatives are:

Games where the music control variable is somewhere totally different to the music engine, You can hack these by (tediously) searching the whole of RAM for the variable, instead of focusing just on the music engine’s RAM area.

Games which require a function call in the code to change the music, but still use a memory location to select the music. These won’t respond when the byte is written; they have to be hacked.

Games which require a function call in the code to change the music, and pass the parameter in a register. These are more tricky because there isn’t an address to search for in the disassembly. Finding the music engine’s entry point helps with these, since you can find calls to it or even hack it directly.

Games which use non-sequential music numbers. Several games with music code written by Matt Furniss, for example, use “blocks” of music; a short track might take 1, a long one might take 5. Their music numbers are references to blocks, so the numbers might be 1, 2, 3, 8, 13, and trying block number 5 would give you music part-way through a track and possibly with some errors.

Games where the music control variable passes through a chain of other code before being written. You may have to try to trace the execution backwards to find out how to control the music engine.

There is also the problem of avoiding music interruptions on non-SMS games, and
games where the pause hack doesn’t work. This is all rather complicated so I’ll
not go into it too deeply; but note that the memory editor lets you find lots of
things, including title screen timeout timers ($ffff frames is plenty of time
for most tracks), in-game timers, invincibility flags, etc.

I used Meka in this guide because it’s pretty and its memory editor does
everything I need. Other emulators may offer the features needed; Emukon is very
good for debugging and hacking, but it runs slowly on my computer.

If you want to distribute your ROM or RAM hacks to others, it is sometimes
better (if possible - it is not with “write trigger” hacks) to create patch file
entries because they may be easier to apply. See the emulator’s documentation
for instructions; Meka’s meka.pat file is self-documenting.