Nem s2

From Sonic Retro

 This historical hacking document is preserved here for archival purposes.It has not been revised since its original writing and may be outdated. For an SCHG-equivalent document, see SCHG:Sonic the Hedgehog 2 (16-bit).

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:

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:

E6800: 004A 037A 5552 5552 5552 5552 5552 5552 0734 0BC0 10EE 10EE 1748 1AFC

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.

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:

42594-42660: Indexed main level load block

(patterns/16x16/128x128)

42594-425A0: Emerald hill zone (00)
42594: EHZ/HTZ main level patterns (95C24) [04]
42598: EHZ/HTZ 16x16 block mappings (94E74) [05]
4259C: EHZ/HTZ 128x128 block mappings (99D34) [04]
425A0-425AC: Unknown (01)
425A0: EHZ/HTZ main level patterns (95C24) [06]
425A4: EHZ/HTZ 16x16 block mappings (94E74) [07]
425A8: EHZ/HTZ 128x128 block mappings (99D34) [05]
425AC-425B8: Unknown (02)
425AC: EHZ/HTZ main level patterns (95C24) [08]
425B0: EHZ/HTZ 16x16 block mappings (94E74) [09]
425B4: EHZ/HTZ 128x128 block mappings (99D34) [06]
425B8-425C4: Unknown (03)
425B8: EHZ/HTZ main level patterns (95C24) [0A]
425BC: EHZ/HTZ 16x16 block mappings (94E74) [0B]
425C0: EHZ/HTZ 128x128 block mappings (99D34) [07]
425C4-425D0: Metropolis zone (04)
425C4: MTZ main level patterns (9DB64) [0C]
425C8: MTZ 16x16 block mappings (9CFD4) [0D]
425CC: MTZ 128x128 block mappings (A06C4) [08]
425D0-425DC: Metropolis zone act 3 (05)
425E0: MTZ main level patterns (9DB64) [0C]
425E4: MTZ 16x16 block mappings (9CFD4) [0D]
425E8: MTZ 128x128 block mappings (A06C4) [08]
425DC-425E8: Wing fortress zone (06)
425DC: WFZ/SCZ main level patterns [10]
425E0: WFZ/SCZ 16x16 block mappings [11]
425E4: WFZ/SCZ 128x128 block mappings [0A]
425E8-425F4: Hill top zone (07)
425E8: EHZ/HTZ main level patterns (95C24) [12]
425EC: EHZ/HTZ 16x16 block mappings (94E74) [13]
425F0: EHZ/HTZ 128x128 block mappings (99D34) [0B]
425F4-42600: Hidden Palace zone (08)
425F4: OOZ 16x16 block mappings (A3364) [14]
425F8: OOZ 16x16 block mappings (A3364) [15]
425FC: OOZ 16x16 block mappings (A3364) [0C]
42600-4260C: Unknown (09)
42600: EHZ/HTZ main level patterns (95C24) [16]
42604:

EHZ/HTZ 16x16 block mappings (94E74) [17]
42608: EHZ/HTZ 128x128 block

mappings (99D34) [0D]
4260C-42618: Oil ocean zone (0A)
4260C: OOZ main level patterns (A4204) [18]
42610: OOZ

16x16 block mappings (A3364) [19]
42614: OOZ 128x128 block mappings

(A6834) [0E]
42618-42624: Mystic cave zone (0B)
42618: MCZ main level patterns (A9D74) [1A]
4261C: MCZ

16x16 block mappings (A8D04) [1B]
42620: MCZ 128x128 block mappings

42624-42630: Casino night zone (0C)
42624: CNZ main level patterns (B0894) [1C]
42628: CNZ

16x16 block mappings (AFFC4) [1D]
4262C: CNZ 128x128 block mappings

(B2CF4) [10]
42630-4263C: Chemical plant zone (0D)
42630: CPZ/DEZ main level patterns (B6174) [1E]
42634:

CPZ/DEZ 16x16 block mappings (B5234) [1F]
42638: CPZ/DEZ 128x128 block

mappings (B90F4) [11]
4263C-42648: Death egg zone (0E)
4263C: CPZ/DEZ main level patterns (B6174) [20]
42640:

CPZ/DEZ 16x16 block mappings (B5234) [21]
42644: CPZ/DEZ 128x128 block

mappings (B90F4) [12]
42648-42654: Aquatic ruin zone (0F)
42648: CPZ/DEZ main level patterns (BCC24) [22]
4264C:

CPZ/DEZ 16x16 block mappings (BB944) [23]
42650: CPZ/DEZ 128x128 block

mappings (C1434) [13]
42654-42660: Sky chase zone (10)
42654: WFZ/SCZ main level patterns (C5004) [24]
42658:

WFZ/SCZ 16x16 block mappings (C4074) [25]
4265C: WFZ/SCZ 128x128 block

mappings (C85E4) [14]

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:

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 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 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.

References

Sonic Community Hacking Guide
General
SonED2 Manual | Subroutine Equivalency List
Game-Specific
Sonic the Hedgehog (16-bit) | Sonic the Hedgehog (8-bit) | Sonic CD (prototype 510) | Sonic CD | Sonic CD (PC) | Sonic CD (2011) | Sonic 2 (Simon Wai prototype) | Sonic 2 (16-bit) | Sonic 2 (Master System) | Sonic 3 | Sonic 3 & Knuckles | Chaotix | Sonic Jam | Sonic Jam 6 | Sonic Adventure | Sonic Adventure DX: Director's Cut | Sonic Adventure DX: PC | Sonic Adventure (2010) | Sonic Adventure 2 | Sonic Adventure 2: Battle | Sonic Adventure 2 (PC) | Sonic Heroes | Sonic Riders | Sonic the Hedgehog (2006) | Sonic & Sega All-Stars Racing | Sonic Unleashed (Xbox 360/PS3) | Sonic Colours | Sonic Generations | Sonic Forces
Technical information
Sonic Eraser | Sonic 2 (Nick Arcade prototype) | Sonic CD (prototype; 1992-12-04) | Dr. Robotnik's Mean Bean Machine | Sonic Triple Trouble | Tails Adventures | Sonic Crackers | Sonic 3D: Flickies' Island | Sonic & Knuckles Collection | Sonic R | Sonic Shuffle | Sonic Advance | Sonic Advance 3 | Sonic Battle | Shadow the Hedgehog | Sonic Rush | Sonic Classic Collection | Sonic Free Riders | Sonic Lost World
Legacy Guides
The Nemesis Hacking Guides The Esrael Hacking Guides
ROM: Sonic 1 | Sonic 2 | Sonic 2 Beta | Sonic 3

Savestate: Sonic 1 | Sonic 2 Beta/Final | Sonic 3

Sonic 1 (English / Portuguese) | Sonic 2 Beta (English / Portuguese) | Sonic 2 and Knuckles (English / Portuguese)
Move to Sega Retro
Number Systems (or scrap) | Assembly Hacking Guide | 68000 Instruction Set | 68000 ASM-to-Hex Code Reference | SMPS Music Hacking Guide | Mega Drive technical information