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

Alex Kidd in Shinobi World

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:

How to open the Memory Editor

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

The Memory Editor looking at 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:

  1. A value that is constant before the music changes, then changes at the same time as the music, and is then constant, or
  2. 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.

These values change in time with the music, and the circled one is the controller.

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

  1. The value we just wrote is changed to zero by the game
  2. 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:

$80No effect
$81Level 1
$82Level 2
$83Level 3
$84Level 4
$85Level Start
$87Boss Music
$88Level Complete
$89Unused music
$8aContinue Screen
$8bUnused music (short)
$8cUnused music (short)
$8dCongratulations To You, Alex
$8fUnused music
$90-$b4Sound effects

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 before0xc621
Put $ before$c621
Put & before&c621
Put h afterc621h

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.


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.

The best thing you can do with any successful hacking is to tell other people. Post it on the SMS Power! forums, perhaps in the "Hacks to find music" thread, and everyone will love you just a little bit more.