Introduction

Here are my hacking notes on the Sonic 2 rom. If you use these notes I'd appreciate it if you would mention it with your hack or your utility, so that other people can find their way here. For hex editing I recommend you use a hex utility called Hex workshop, and for emulators I recommend you get both Gens and Genecyst. Genecyst may be old and kinda crap, but it has a whole heap of debug outputs that really help when it comes to seeing exactly what it's doing and when.

First of all it's very important that you understand the basics. All data stored on a computer is in the form of 1's and 0's. On a CD for example, a laser hits the surface, and if the laser bounces back and hits the lens it's a 1, and if it doesn’t it's a zero. Each 1 or 0 is called a bit, and a bit cannot have any other characters in it other that a 1 or a 0. Now the computer deals with bits in groups of 4. There are 16 possible combinations for a group of four 1's and 0's, so to make it simpler it deals with it as one value, rather than 4 (Eg. 0110 becomes 6). Now as there are 16 possible combinations for a group of 4 bits, this value to represent their values must have 16 values itself, so rather than a simple 0-9, this value is 0-F (0123456789ABCDEF). This value is called a hexadecimal value (hex value for short). Each hex value is dealt with in groups of 2, called a byte, each byte having 128 possible combinations. Now on a final output level the byte may be looked up on an ASCII table, which will convert that value into a recognisable character (Eg. a byte value of 73 becomes a lowercase s on an English ASCII table). You will practically never touch the ASCII version of the code in hacking though.

Now one important thing to realise is that as one character of hex has 16 values and a decimal (real) value only has 10, it may be necessary to convert the numbers between them from time to time. This is done with the use of a base converter (included in hex workshop). Let's say you wanted to give Sonic 50 rings. If you enter 50 as the value, you will in fact end up with 80, because that value you are entering is actually a hex value, but if you use the base converter to convert it first, you merely enter the value of 50 into the decimal box, and it will spit out a hex value of 32, which will in fact give you 50 rings in the game. Another useful utility that you will need is a hex calculator (also included in hex workshop). A hex calculator is the same as a normal calculator, but it deals with hex values rather than decimal values.

Another thing you need to know is that each level in Sonic 2 has a value assigned to it, but this value does not correspond with each level's final position in the game. Here is a list of the level values in Sonic 2:

00

Emerald Hill zone

04

Metropolis zone

05

Metropolis zone act 3

06

Wing fortress zone

07

Hill Top zone

08

Hidden Palace zone

0A

Oil Ocean zone

0B

Mystic Cave zone

0C

Casino Night zone

0D

Chemical Plant zone

0E

Death Egg zone

0F

Aquatic Ruin zone

10

Sky Chase zone

One other thing you need to know is the way that the Mega Drive stores all the art. All the art that is used in the game is stored in the form of 8x8 pixel blocks. These blocks do not actually store colours at all, they actually only have one hex value per pixel. That value specifies what point on the palette line the pixel will get its colour from. The palette has 4 lines, each with 16 colours on them. Now the colours on the palette can be changed at any point during play, and some palette colours may even automatically change colour each couple of frames to make it look like the colour is flashing.

Now these 8x8 blocks are not what make up the level directly. 4 8x8 blocks are grouped together to form a 16x16 block, and it is at this point that the palette line to use for that 16x16 block is specified. The 8x8 patterns can also have their x, y, or x and y values reversed when placing them in a 16x16 block. Also it's at the 16x16 level that the collision definitions are specified. Now finally we get to a 128x128 block, and these are the things that the actual level info loads. It is made up of 64 16x16 blocks, and each block inside them can use a different palette line. You cannot place anything except a sprite or a 128x128 block directly into a level.

Now that you know all the basics, here's my breakdown:

Address listing

For the most part, there are no breaks in this list. If one address follows on directly from another on this list, it does so in the rom, with the exception of data that comes before 40000. All the compiled code that is used in the game is stored in this section, and that's a pain in the ass to sort through, so there will be many breaks there. The column on the left lists it's file location, the column in the middle contains it's name and description, and the column on the right will contain any special notes about it, such as compression format used if applicable, and number of blocks an art tile uses. The right column will also contain a link with the text further info, if that particular block requires it. That link will jump to a detailed explanation of that thing. Anything linked like that will also be listed in the contents at the top of the page.

Offset indexes

An offset index is a handy way of keeping a block of data grouped together, and also replacing a whole heap of pointers. The way it works is there is a list of two byte values, and depending on the block of data the game wants to load, it will take one of those values and add it to the starting address of the offset index. The most common usage is for every act of every level value, there is an offset that acts as the pointer to the block of data to use for it. Lets look at an example:

Now this is the beginning of the offset index for the sprite locations. Now, can you see which values are the offset for MTZ act 2? They're 0BC0. All you had to do to get that was to take the level value for MTZ, which is 04, and count across four bytes for every value it is above 00, then across another two because it's the second act. Now we take that value and using a hex calculator, add it to the address of the offset table, which is E6800. That will give us a value of E73C0, which is the address in the rom of the MTZ act 2 sprite locations.

Also notice those 5552 values in there? Well those are for the unused level values in the game. You'll see some damn weird values put in for them in many places, and that's what causes the game to lockup in the final build of sonic 2 if you try and enter one of those levels.

There are other forms of an offset index such as the one where there's just one offset per level value, and another type that actually uses a double offset index. The first is easy enough, but a double offset index will specify two values per level, but that's not for act one and two, but rather two blocks of data to use for both acts.

Main level load block

This
pointer table is what is used to load up the block mappings and main level
patterns for every level in the game. Here's a breakdown of the pointer table in
the S2 rom:

Now as you can see, these pointers specify the loading addresses in the rom for the 16x16 and 128x128 block mappings, as well as the main pattern block for that level. The main pattern block will always be loaded into the VRAM at address 0000. These loading addresses are all preceeded by a one byte value, so the address pointer only uses three bytes rather than the standard four. The value that proceeds the 128x128 block mappings specifies a value on the palette index to load for that level. For more information on the palette system, go here. The values preceeding the main level pattern and 16x16 block mapping pointers give the index numbers of the pattern load cue's to use for that level. For more information on that go here.

Pattern load cues

The pattern load cues are what loads all the pieces of art into the VRAM that are not in the main level load block. Here's a breakdown of the pattern load cues in the S2 rom:

This pointer list has an offset index to locate the correct cue. Go here for an explanation of how this works. Now, each load cue has a two byte value before it that specifies how many addresses are in the cue, to avoid it reading too far, and going into the next cue. This value is dead simple, just enter the number of patterns on the cue in hex between the first two bytes, but you have to count 00 as 1, so if there was 16 loading addresses in the cue, you'd have 000F preceding it. After that, there are 6 bytes per load request. The first four bytes are a pointer to the art block to use, and the two bytes after that are the location in the VRAM to load them into.To change the pattern load cue's being loaded for a level, you need to change the values in the main level load block. For more information on that go here.

Collision definitions

Ok, I’m going to explain how collision works on objects that are not sprites in the sonic games. First of all forget the image that the block contains. The image has absolutely nothing to do with the collision. There's basically in invisible collision box on top of every 16x16 block that sets what's solid and what's not. This collision box has two parts to it. The main part of it is the collision array (an array is basically a table of values). The collision array stores the actual data that says that is a block is solid in certain places. It does that through 16 bytes per collision box. To understand how those 16 bytes set what's solid, imagine a 16x16 block. Now imagine that 16x16 block with the numbers 1-10 (hex) down the side starting from the bottom and going up to the top, and starting from the left and going up as it moves right along the top, so that you can give an exact location of each pixel. (eg, the top left pixel would be 10,00) Now, in this array the first two bytes define what's solid for the row of pixels on the left side of that 16x16 block. Basically the first of those two bytes says where to start making things solid, and the second byte says where to stop making them solid. So if you entered the value 0010, the first row would be solid from the very bottom of the block all the way up to the top. If you were to enter the value 020E, there would be two pixels on either side of the block that are not solid, and everything in the middle would be. The next two bytes after that are for the next row, etc. After 16 bytes the definitions for the next collision box begin.

Now, to specify which blocks use which collision boxes, there are collision indexes, which give an array location for each 16x16 block. If you look at the space used by the collision array, you can divide that by 16 (the number of bytes used by each entry into the array) to give a one byte value, which represents the maximum number of collision boxes that the array can hold in the S2 platform, which is FF. Now, for each level there is at least one 16x16 collision index, and that index consists of a whole heap of array locations, one for each 16x16 block. If for example you wanted the 9th 16x16 block to use the collision box with an array location of 3E, you would give the 9th byte of the collision index for that level a value of 3E.

It is through collision indexes that the loops work in the game. It's commonly believed that there are layers, and that the sprite represented by 4 rings changes between them. This is partly true. For any levels that use multiple layers like that, there is a secondary 16x16 collision index. That object switches the 16x16 collision index in use. The pointers to these 16x16 collision indexes are stored at 49E8-4A70. The first set of pointers in this group specify the location of the primary collision index to use for each level, and the second set specify the location of the secondary collision index to use for each level.

Now just setting something as solid, doesn't give it the effect of having a slope. There's an index in the rom, which has one byte in it for each collision array location. To understand how this value works, think of two lines running parallel to each other, both with the value 0-F along them. Now, the first value of the byte gives a point on the right line, and the second value gives a point on the left line. Now imagine drawing a line between these to points. If the points are different, the resulting gradient will be taken to create the effect of a slope and the resistance going up it on the box in the corresponding collision array location.

Level layout

The level data in the S2 rom is compressed. Editing compressed data is extremely impractical, so you can either extract it first using an extraction program such as ChaoSaX-Extract, and once it's in that form refer to my savestate hacking info for information on how to edit it. Once you've finished editing it you can then use the soon to be added compression routine in ChaoSax-Extract to recompress it, and then you can place it back into the rom. If it is a larger size than the original, you will need to fiddle around with the locations and the offset index to get it back in.

Ring placement

The data for ring placement has an offset index to locate the correct group. Go here for an explanation of how this works. Now, in the rom each ring does not have to be stored individually. Instead you can place one ring, and specify that a certain number of rings come after it. The definitions for one ring takes up 4 bytes in the rom. Let's look at an example:
1234 5678
Now, in this example the ring will be placed at an x location of 1234, and a y location of 678. With that value where the 5 was entered, if the value entered is below 8, an additional ring will be placed next to the one before it for every unit that the value entered is above 0. Entering a value above 8 will place an additional ring below the one before it for each unit that the value entered is above 8. When specifying a position as the start of a group of rings, if the group is horizontal, the rings will go across to the right of that point, and if the group is vertical the rings will go down from that point. The value FFFF closes the group of ring locations, and it is essential that this is at the end of the ring locations list, or else the game will keep on reading past that point until it hits that value.

Sprite placement

Sprites are quite simple to define. It takes six bytes to define one sprite. The first two bytes are the x location of the sprite, and the next two bytes are the y location of the sprite. The 5th byte is the number on the sprite array to lookup to get the location for the function to use for the programming of that sprite, and the 6th byte is an optional declaration to use with the function for that sprite. Go here for more info on what exactly that means, and a list of all the sprites in the S2 rom.

Main level Block mappings

The block mappings in the S2 final rom are compressed. If you want to edit them you need to extract them first, edit them, and then recompress them afterwards. For more information on exactly what the block mappings do, and how to edit them, refer to the sonic 2 savestate breakdown. Note that the 16x16 block mappings in the S2 beta rom are not compressed, so if any port from the beta to the final is to be successful, those mappings will need to be compressed first.

Main level pattern blocks

Unlike the beta, the main pattern block for the levels do not use the standard art compression format, but a less complex one to allow the patterns to be loaded faster into the VRAM, and hence cut down on loading times for levels significantly. Also unlike the standard art compression format, this one has been cracked. A decompression utility such as ChaoSaX-Extract is capable of decompressing these patterns. If a port is to be done from the beta, it will be necessary to either allow the game to decompress the main pattern block into the VRAM, and then recompressing the appropriate blocks manually and putting them into the rom, or just cheat and stick these patterns on the pattern load cue. That is rather sloppy though. For information on how to edit extracted patterns, refer to the Sonic 2 savestate breakdown.

Uncompressed art

Any art that needs to be updated on the fly will not be compressed in the rom. This is because the game can't work with compressed data, and needs to extract any data it wants to use to the ram. This decompression process takes a fair bit of computation, and because of that it wouldn't be possible to create the appearance of a smooth animation using compressed data. The same reason is true as to why any data that is not loaded into the ram will always be uncompressed, because otherwise they would have to load it into the ram just to read it.

Now, for example all of the blocks for Sonic and Tails are uncompressed, because they of course need to be updated quickly. You can use basically any editing utility to edit them, but you can only change what each block looks like through this. In order to edit what blocks are placed where in each of Sonic's animation frames, you need to edit the mappings for them, and for more information on that go here. Now in their uncompressed form, you can edit them just like you would in the VRAM, so for more information on that check the sonic 2 savestate breakdown.

Mappings for Sonic/Tails

What the mappings do is they tell the game what patterns to display, and where to put them for each of the frames that the sprite has. The mappings for most sprites are contained within their function (go here for more details), but with the Sonic and Tails sprites, to allow the programmers to add a new frame easily without having to recompile the function, and hence the whole game because of the size difference, they created a separate array containing the mapping data for each frame. I haven't examined this to see how it works yet, but when I do I’ll explain the format here.

Sega intro sound

The Sega intro sound is just a 16000HZ wav sound. Opening up the rom in any sound editing program that supports raw audio with the settings listed next to the location on the list will enable you to playback the sound effect. You could also insert your own sound in the same place as long as it's at the same bitrate. The bitrate is to do with the quality of the sound. The lower it is the crappier it will sound, because that's to do with how often the output is modified. Just think of the difference between long play and short play on a VCR. Stuff recorded in long play does save space, but the quality of the recording is worse.

Art compression format

The art compression format is a very dense compression format. It's only used for art because the format relies on the data being in blocks of 64 bytes. This format is used for all the compressed art in sonic 1 and sonic 2 beta, and all the compressed art except for the main level pattern blocks in Sonic 2 and S3&K. As I said this format is very dense, and as such it requires a hell of a lot of computation to decompress. Because of this it also requires a hell of a lot of time and effort to crack. I've had a go at it, but the lightning has yet to strike. When I crack it I’ll post the format breakdown here, and create a simple program to decompress it, but until then it is impossible to directly edit any art using this format. The porting of a compressed block of art is simple though, so if you want to transfer beta art to the final, you can just tack it onto the end and enter the pointer into the pattern load cue of the level or event you want it to appear at, along with a VRAM location to load it into. Go here for more information on that.

Dynamic pattern reloading

Dynamic pattern reloading is a method of loading patterns into the VRAM, but unlike the other methods, this one has no limitations, because it uses actual programmed code. Basically this is here for any effects to do with patterns changing in game that isn't posible using the normal load cue system, like the hills in the background of HTZ where the patterns to display are determined by the position of the screen. Because the programming for it is in the form of compiled code, direct editing of it is not possible.

Animated pattern load cue's

Animated patterns require the art they are working with to be in an uncompressed form, so if you are attempting to make an animated pattern, make sure the art is uncompressed or it won't work. Now, the length of each load request on the cue varies depending on the animation. The first byte specifies a value that will determine how often to switch frames in the animation. If you use this value you will not be able to specify a frame as having a different duration to another. Setting this to FF will disable automatic frame control and allow the user to input a manual duration for each frame. This will mean that for every frame the user wants in the animation, they have to allow another byte at the end of the load request. If you want automatic pattern control, which you would use if you want all the animations frames to have the same duration. Just enter how many screen refreshes to wait until the next frame of the animation is displayed. Bytes 2,3, and 4 are the address in the rom to load the patterns from. Bytes 5 and 6 are the location in VRAM to load the patterns into. Byte 7 is the number of frames the animation has, and byte 8 is the number of spaces in VRAM to use for each frame. The function of the bytes beyond this point depend on whether or not automatic frame control is enabled, so refer to appropriate section below.

With automatic frame control:
One byte per frame of animation. This byte simply specifies the image to use for each frame of the animation. Based on the loading address entered, this value is the offset in 8x8 blocks to load each frame from in the rom. So if for example you were dealing with an animation that had 4 8x8 blocks per frame, and there were 4 frames of that, and you wanted it to display each frame one by one, you would enter the value 0004 080C.

Without automatic frame control:
Two bytes per frame of animation. The first byte is the offset of blocks in the file to load the animation frame from. This byte simply specifies the image to use for each frame of the animation. Based on the loading address entered, this value is the offset in 8x8 blocks to load each frame from in the rom. The second byte is the number of screen refreshes to keep that image loaded for, before going on to the next animation frame.

Misc sprite definitions

It looks like there are some sprites that get thier mappings and whatnot from this index, so they can reuse just a couple of sprites for some of the the miscellaneous objects in a level that the character doesn't actually interact with, but those objects can be completely different from one level to the next. A handy way of avioding programming each one individually, and thus saving a hell of a lot of space. As for how to edit them, well I haven't looked at that yet, but when I do i'll post an explination of the format here.

Rasterised layer deformation

Raster effects are simply effects to do with deformation of an image based on lines of pixels. In Sonic 2, these effects are used to create the movement effects for the backgrounds of all the levels, as well as the 2 player splitscreen effect. Because the programming for these effects are stored in the form of compiled code, you'll have to learn 68K ASM in order to edit them. Switching between levels is easy enough though, just change the corresponding value on the preceeding offset index to link to the effect you wish to use.

Palettes

All the main palettes used in the game are linked in a pointer table at 294E. In this pointer table there are 8 bytes per palette. The first four simply give a location in the rom for the data to load. The fifth and sixth bytes give the location in the system ram to load the data into, and the seventh and eighth bytes give the number of bytes being loaded. Here's a palette pointer:

0000 2942 FB20 0007

Now in this case the palette is being loaded from 00002942 in the rom into the beginning of the second above water palette row (FB20), and it's loading 4 colours (0007). Here's a listing of the palette pointers in the S2 rom:

00

2782

SEGA screen palette (28C2)

01

278A

Title screen palette (2942)

02

2792

Unknown palette (2962)

03

279A

"Sonic and Miles" screen palette (29E2)

04

27A2

EHZ palete (2A22)

05

27AA

Level value 01 palette (2A22)

06

27B2

WZ palette (2A82)

07

27BA

Level value 03 palette (2A22)

08

27C2

MTZ palette (2AE2)

09

27CA

MTZ act 3 palette (2AE2)

0A

27D2

WFZ palette (2B42)

0B

27DA

HTZ palette (2BA2)

0C

27E2

HPZ palette (2C02)

0D

27EA

Level value 09 (2A22)

0E

27F2

OOZ palette (2CE2)

0F

27FA

MCZ palette (2D42)

10

2802

CNZ palette (2DA2)

11

280A

CPZ palette (2E02)

12

2812

DEZ palette (2EE2)

13

281A

ARZ palette (2F42)

14

2822

SCZ palette (3022)

15

282A

HPZ underwater palette (2C62)

16

2832

CPZ underwater palette (2E62)

17

283A

ARZ underwater palette (2FA2)

18

2842

Main special stage palette (3162)

19

284A

Unknown palette (3082)

1A

2852

Unknown palette (30A2)

1B

285A

Special stage 1 palette (31C2)

1C

2862

Special stage 2 palette (31E2)

1D

286A

Special stage 3 palette (3202)

1E

2872

Special stage 4 palette (3222)

1F

287A

Special stage 5 palette (3242)

20

2882

Special stage 6 palette (3262)

21

288A

Special stage 7 palette (3282)

22

2892

Unknown palette (32A2)

23

289A

Unknown palette (32C2)

24

28A2

Unknown palette (32E2)

25

28AA

OOZ boss palette (30C2)

26

28B2

Menu palette (30E2)

27

28BA

Unknown palette (3302)

To change the palette being loaded for each level, you need to change the palette index number in the main level load block. For more information on that go here. The palettes themeslves are very easy to modify as they are all uncompressed in the rom. Refer to the savestate hacking documents for information on how to edit palettes.

Level size array

All the sizes of the levels are stored in a simple array, and can be easily modified to change the boundaries of the level. This array is located at C054, and for each act there are four values. The first gives the X start location of the level, and the second gives the X end location of the level. Likewise the third value gives the Y start location of the level, and the fourth gives the Y end location of the level.

Character start location array

The start location for the characers and the camera for each level are stored in this array at address C1D0. It couldn't be any simpler to modify, there's just two values per act, the first being the X location, and the second being the Y location.

Music playlist for levels

This is actually part of a sub in the code, but it's editable all the same. Pretty simple, just one byte per level. That one byte is the value of the song you wish to play. You must enter the value in the form in which it is displayed in the beta version, which is with 80 as the starting value, not 00 as it is displayed in the final. You'll notice with the value for death egg, it's 08 not 88, which is why there's no sound in the level.

Level order

There are several different sections in the game to do with the order of levels. The first one is the one that determins which level the game loads when someone finishes a level. The second one is the one which determins which level to load when you select a level from the level select menu. The level select one is easy to modify, just enter the level value followed by an act number for each of the levels you want to load, in the order you want them to be loaded. For a list of the level values for all the different stages, look at the beginning of the introduction to this page. Note that if you load the same level into the level order twice, when you link to it via the level select, it will continue the sequence from the last one in the list, not the first.

The second system for which level to load when one ends works slightly differently. There is a list of values, with two bytes allocated to each act of each level. That two byte value is simply the value of the level you wish to load when that level ends. So, if you wanted ARZ act 1 to load up when you finish MTZ act 2, you would take the location of the table, which in this case is 142F8, and you would add 18 bytes to that location, and then you would replace the next two bytes from that point with 0F00. That's becuase you add four bytes to the address for every level that comes before it, and in this case there are 4, and then you would add another 2 bytes becuase you want to alter the level to load when you finish the second act.

Also, note that when you want a level to be the last level in the game, you must enter the value FFFF as the stage to load when it finishes. This tells the game to end and return to the title screen.

Object debug list

This list is what determins what sprites you can place in debug mode, and in what levels. An offset index is used to locate which object debug list to use for which level, so if you want further info on that go here. Now, there is a 2 byte value at the start of each debug list. That 2 byte value is simply the number of sprites in the list. After that there are 8 bytes per sprite. Here's an object that's present in an object debug list from sonic 2:

2601

2D36

0800

0680

1

2

3

4

5

6

7

8

And here's a quick referance sheet of what each byte does. For further info
on each one, refer to information below.

1

Object number

2-4

Sprite mappings

5

Declaration

6

Frame to display

7 and 8

flip/mirror/palette/VRAM location

Object number:This value is what determins which object to use. For a list of all the sprites in the game, check out the sprite programming section of this document here. In the case of the above example the object number is 26, which is a monitor.

Sprite mappings:This is a pointer to the location in the rom to load the mappings for that sprite. This will be located in the programming for the sprite itself. Do not change this unless porting between levels, or you're absolutely sure you know what you're doing, or the game will most likely hang. This only affects the preview picture, not the placed object itself. In this case, the sprite mappings are being loaded from the address 012D36 in the rom.

Declaration:This is the declaration for the loading of the sprite. For information on exactly what that is, go here. In this example the declaration is 08, which switches the type of monitor it is in the case of this sprite.

Frame to display:This is simply the frame of the sprite that will be displayed on the preview picture before you place an object. Right now it's set to 00, which is the first frame.

Flip/mirror/VRAM location:The first hex value of the 7th byte is to do with flipping and mirroring of the sprite, as well as the palette line to use for it. Refer to the following table for an explination of what responce each value will create.

Value

palette line

flipped horizntally

flipped vertically

0

1

n

n

1

1

n

y

2

2

n

n

3

2

n

y

4

3

n

n

5

3

n

y

6

4

n

n

7

4

n

y

8

1

n

n

9

1

y

n

A

2

n

n

B

2

y

n

C

3

n

n

D

3

y

n

E

4

n

n

F

4

y

n

In the case of our example, the value of 0 is used, so the preview image will use the first palette line, and will not be flipped or mirrored.

The last hex value of the 7th byte, and all of the 8th byte in this block combine to give a starting location in the VRAM to find the patterns to use for that sprite when displaying the preview. This is not an actual location, but merely the number of blocks after which to load the patterns from. After the value of 800 is passed, the block number resets to zero but the image is mirrored. In this case, that block number is 680.

And that's about it. I've just realised that this is a rediculous amount of detail for such a small thing, but at least you're sure to get it.

Sprite programming

The programming for a sprite in the sonic games are stored as a function, and that function can take one declaration. People often confuse this declaration with a subtype value, but it's not really. What that basically means for the non programmers out there is that when the game places a sprite, you can enter a value along with the sprite number that may alter something about that sprite, but what it does varies depending on what sprite you're working with. Now because these functions are now compiled, the only way you can effectively edit them is to find the code for it and decompile it into assembly, alter it as necessary, and then recompile it and enter it back into the rom. This document will contain all the info necessary to enter a new sprite or replace an old one, but when it comes to the ASM you're on your own.

Now, the value assigned to a sprite in the game is done by a pointer index at 1600C-1637C. It’s Pretty simple, just one pointer per address value. Here's the pointer list in Sonic 2. I've named all the ones I could at the time. I made this list quite a while ago though, and I think I could do a better job if I redid it now, but I can't be stuffed doing it at this point in time.

1

Sonic [19F50]

2

Tails [1B8A4]

3

??????? [1FCDC]

4

??????? [208DC]

5

??????? [1D200]

6

Rotating cylinder in Metropolis zone [214C4]

7

Oil (stretches across entire map) [24020]

8

Unknown (some kind of vertical barrier, but barrier is not visible) [1DD20]

9

??????? [338EC]

A

??????? [1D320]

B

Section of pipe that tips you off from chemical plant zone [2009C]

C

Unknown (some strange thing that bobs up and down. Possibly top of water in HPZ.) [20210]

D

Unknown (hit it from left or right and get thrown back faster than should be possible) [191B8]

E

Flashing stars from intro [12E18]

F

??????? [13600]

10

Unknown (tails won't move) [347EC]

11

??????? [F66C]

12

Master emerald [2031C]

13

??????? [203AC]

14

See saw thingy from hill top zone [21928]

15

Swinging platform from ARZ [FC9C]

16

Diagonally moving lift thing from HTZ [21DAC]

17

Unknown (looks like some sort of steam burst like from MTZ) [10310]

18

Stationary floating platform from ARZ [104AC]

19

Unknown (some kind of floating platform that moves back and forth, but not very far) [22018]

1A

Collapsing platform from either OOZ or MCZ [108BC]

1B

Booster things from CPZ [222AC]

1C

??????? [111D4]

1D

Unknown (seemed to have a random area within a set distance from the sprite in which you could get hurt.) [22408]

1E

Spin tube from CPZ [2259C]

1F

Collapsing platform from OOZ [10A08]

20

Unknown (lava bomb that Robotnic drops in HTZ?) [22FF8]

21

Unknown (sprite just changes between two palette lines) [80BE]

22

Arrow shooter from ARZ [25694]

23

Pillar that drops it's lower part from ARZ [2588C]

24

??????? [1F8A8]

25

A ring [11F44]

26

Monitor [12670]

27

An explosion of an enemy, giving off an animal and 100 points [21088]

28

An animal and the 100 that are given off from busting a badnick [1188C]

29

The 100 [11DC6]

2A

Stomper from MCZ [115C4]

2B

Raising pillar from ARZ [25A5A]

2C

Sprite that makes leaves fly off when you hit it from ARZ [26104]

2D

One way barrier from CPZ and DEZ [1169A]

2E

Image of what was in monitor flying up like it does when you bust it [12854]

2F

Unknown (a small block) [23300]

30

Unknown (something you can't see with a collision box the size of the whole damn screen) [238DC]

31

Lava collision marker [20DEC]

32

Unknown (A block that when you hit it from the top you get 100 points, and it then splits into six pieces which fly down off the screen) [2351A]

33

Platform that shoots up in the air from oil ocean zone [23AF4]

34

Sprite for level title card [13C48]

35

??????? [1D97E]

36

Vertical spikes [15900]

37

Sprite of rings spraying out from being hit by an enemy [12078]

38

Shield that surrounds character [1D8F2]

39

Unknown (sprite comes from the left, and sits on the screen near the centre. If you press jump it will reset to Sega logo. Possibly game over sprite.) [13F74]

3A

End of level result screen [14086]

3B

Unknown (a block) [15CC8]

3C

Unknown (a barrier you can smash by dashing into. Like the rock barriers in Sonic 3.) [15D44]

3D

Block thingy in OOZ that launches you into the round ball things [24DD0]

3E

Egg prison [3F1E4]

3F

Fan blowing to the left from OOZ [2A7B0]

40

Weird lever like spring from CPZ and ARZ [26370]

41

Red spring facing upwards [18888]

42

Thing that pops up and releases steam sideways from metropolis zone [26634]

43

Spiky ball from OOZ [23E40]

44

Star ball that sonic bounces off from CNZ [1F730]

45

Strange spring from OOZ facing vertically [240F8]

46

Ball sitting on strange spring from OOZ [24A16]

47

Button [2FCF4]

48

Thingy from OOZ that you enter when flying as a ball, and it turns and throws you another direction [25244]

49

Unknown (Huge vertical laser from WFZ?) [20B9E]

4A

Octopus badnick from OOZ [2CA14]

4B

Buzz bomber from EHZ [2D068]

4C

??????? [1637C]

4D

??????? [1637C]

4E

??????? [1637C]

4F

??????? [1637C]

50

Seahorse badnick from OOZ [2CCC8]

51

CNZ boss [318F0]

52

HTZ boss [2FC50]

53

Things spinning around MTZ boss [32940]

54

MTZ boss [32288]

55

OOZ boss [32F90]

56

EHZ boss [2EF18]

57

MCZ boss and Earthquake [30FA4]

58

Unknown (some kind of really big explosion?) [2D494]

59

Unknown (alters the palette to put in some colours that look really awesome in ARZ, then teleports you back to x0 y0 and doesn't allow you to move) [35FBC]

5A

??????? [35554]

5B

??????? [353FE]

5C

Shark badnick from EHZ [2D394]

5D

CPZ boss [2D734]

5E

??????? [6FC0]

5F

??????? [70F0]

60

??????? [34FA0]

61

??????? [34EB0]

62

??????? [1637C]

63

??????? [340A4]

64

Twin stompers from MTZ [26920]

65

Unknown (a long platform) [26AE0]

66

Unknown (a tall bumper from CNZ, that I don't think was ever implemented in a level) [26F58]

67

One of the spin tubes from MTZ [2715C]

68

Block that has a spike that comes out of each side sequentially from MTZ [27594]

69

Nut from MTZ [27884]

6A

Unknown (jump on it and it's fine. Jump off it and it moves down) [27AB0]

6B

Unknown (Same type of block as above, but it doesn't move) [27D6C]

6C

Unknown (a block that moves up and to the left slowly)[28034]

6D

Floor spike from MTZ [27794]

6E

Unknown (a block that rotates round in a circle) [283AC]

6F

End of special stage result screen [143C0]

70

Unknown (Big circle of sprites rotating around, and changing their tiles depending on their position) [285C0]

71

Unknown (six vertical blocks that change patterns) [112F0]

72

??????? [2893C]

73

Unknown (a small thing with a picture of a ring on it) [289D4]

74

Unknown (a small block with no patterns on it) [20EE0]

75

??????? [28BC8]

76

Spike block thing from MCZ [28DF8]

77

Unknown (long block) [28F88]

78

Stairs from CPZ that move down to open the way [291CC]

79

Starpoll [1F0B0]

7A

Platform that moves back and forth on top of chemicals in CPZ [293A0]

7B

Unknown (acts exactly like a spring, but tries to use level specific patterns) [29590]

7C

Big pylon thing that's in the foreground in CPZ [20FD2]

7D

??????? [1F624]

7E

??????? [1E0F0]

7F

Vine switch that you hang off in MCZ [297E4]

80

Vine that you hang off and it moves down from MCZ [2997C]

81

Unknown (Long invisible vertical barrier. Suspect it's pasted over the force fields used in the boss at the end of WFZ.) [2A000]

82

Platform that is usually swinging from ARZ [2A290]

83

3 adjoined platforms from ARZ that rotate in a circle [2A4FC]

84

??????? [2115C]

85

Vertical spring from CNZ that you hold down jump on to pull back further [2AB84]

86

Flipper from CNZ [2B140]

87

??????? [7356]

88

??????? [34A5C]

89

ARZ boss [30480]

8A

Unknown (a line of text on the centre of the screen. Will have to put in correct tiles to see what it says.) [3EAC8]

8B

??????? [21392]

8C

Blowfly enemy from ARZ [36924]

8D

Unknown (ummm, a blowfly behind a wall like grounder is, but not exactly behind it. When it busts out weird things happen.) [36A76]

8E

Unknown (Same as above) [36A76]

8F

Unknown (a thing that sits in one place and does nothing. You can bust it like a badnick.) [36B88]

90

Unknown (a sprite that launches up and to the left, then curves back down. You can bust it like a badnick.) [36BD4]

91

Unknown (heads towards you. Can be busted like a badnick.) [36DAC]

92

Unknown (when you pass it, it sends a large burst up which hurts you.) [36F0E]

93

Unknown (sprite rapidly reverses direction and spirals down.) [36FE6]

94

Lava snake [37322]

95

Red circle dude from hill top zone that has lava balls circling around him that he throws at you. [370FE]

96

Lava snake... again [37322]

97

Unknown (sprite accelerates down and to the right) [373D0]

98

??????? [376E8]

99

Bomber badnick from SCZ [377C8]

9A

Turtle thing on the back of another larger turtle thing from SCZ [37936]

9B

??????? [37A06]

9C

??????? [37A82]

9D

Coconuts (the badnick) from EHZ [37BFA]

9E

Snake like badnick from MCZ that flies out from wall at you [37E16]

9F

Crab like badnick from MTZ [3800C]

A0

Unknown (sprite falls down) [3815C]

A1

Praying Mantis dude from MTZ [383B4]

A2

Unknown (sprite falls down, then locks up emulator) [384A2]

A3

Glowbug from MCZ [3873E]

A4

Exploding star from MTZ [3899C]

A5

Unknown (sprite moves back and forth, throwing something at you that curves up and back down) [38AEA]

A6

Unknown (sprite moves up and down slowly, shooting a fast moving projectile down and to the left) [38B86]

A7

Spider badnick from CPZ [38DBA]

A8

??????? [38F66]

A9

??????? [39032]

AA

??????? [39066]

AB

Unknown (sprite sits there and does nothing. You can bust it like a badnick) [390A2]

AC

Jet badnick from SCZ [3937A]

AD

Unknown (appears to be a block and has no image, but if you hit it in the corner it busts like a badnick) [3941C]

AE

??????? [39452]

AF

Unknown (block that laser beams shoot from to form barrier at end of WFZ? Just a hunch.) [3972C]

B0

Unknown (weird sums it up. It alters the palette, 128x128 block mappings, and quickly moves to the left as a killable badnick. Destroying it interrupts the process of altering the block mappings data (among other things).) [3A1DC]

B1

Unknown (appears across from it's actual position and does nothing. Can be busted like a badnick.) [3A3F8]

B2

??????? [3A790]

B3

??????? [3B2DE]

B4

Unknown (sprite flashes between frames. Can be busted like a badnick.) [3B36A]

B5

??????? [3B3FA]

B6

Tilting platform from WFZ [3B5D0]

B7

Unknown (sprite flashes between there and not there really fast, then disappears completely) [3B8A6]