SCHG

Nem s1

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.

Introduction

Here are my hacking notes on the Sonic 1 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 1s and 0s. 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 1s and 0s, 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 1 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 1:

00

Green Hill zone

01

Labyrinth zone (act 4 is scrap brain zone 3)

02

Marble zone

03

Star Light zone

04

Spring Yard zone

05

Scrap Brain zone (act 3 is Final 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 256x256 block, and these are the things that the actual level info loads. It is made up of 256 16x16 blocks, and each block inside them can use a different palette line. You cannot place anything except a sprite or a 256x256 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 1D000. 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. Also, any patterns that are not used anywhere in the game will be preceeded by this red dot .

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 vaues, 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 in the S2 rom. 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.

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

These are the blocks that tie all the pieces for a level together. Pretty much everything major to do with a level is linked back to this block at some point.

One thing that's very imporant to understand is that the game engine used in S1 was not completed. It looks like some things that Yuji Naka planned to implement were not completed due to lack of time. Some of these things show up in the main level load block. First of all, the pointer to the main level patterns in this block is not used by the game at all. Instead the main level patterns are included on the pattern load cue for that level. In S2 another compression format was made, and the main level patterns were stored in this format, which was less dence to allow the main level patterns to be loaded into the VRAM faster, and for that this pointer was used. Several other things that were only to use one byte were also allowed for in this block, such as the music track to play for that level. Some of these were later moved to seperate sections of the code though, so only the pattern load cue and palette index numbers are used.

Now that you know that, here's a breakdown of the main level load blocks in
the S1 rom:

1D5A2: Main level load blocks (patterns/16x16/256x256/palette)

1D5A2-1D5B1: Green hill zone (00)

1D5A2: GHZ main level patterns (3DCF2) [04]

1D5A6: GHZ 16x16 block mappings (3BCF2) [05]

1D5AA: GHZ 256x256 bock mappings (3F09A) [00]

1D5AE: GHZ main level palette (04) [00 81 04]

1D5B2-1D5C1: Labyrinth zone (01)

1D5B2: LZ main level patterns (414D4) [06]

1D5B6: LZ 16x16 block mappings (411AA) [07]

1D5BA: LZ 256x256 block mappings (4301C) [00]

1D5BE: LZ main level palette (05) [00 82 05]

1D5C2-1D5D1: Marble zone (02)

1D5C2: MZ main level patterns (46016) [08]

1D5C6: MZ 16x16 block mappings (4580C) [09]

1D5CA: MZ 256x256 block mappings (4885A) [00]

1D5CE: MZ main level palette (06) [00 83 06]

1D5D2-1D5E1: Star light zone (03)

1D5D2: SLZ main level patterns (4A7FE) [0A]

1D5D6: SLZ 16x16 block mappings (50782) [0B]

1D5DA: SLZ 256x256 block mappins (5481C) [00]

1D5DE: SLZ main level palette (07) [00 84 07]

1D5E2-1D5F1: Spring yard zone (04)

1D5E2: SYZ main level patterns (510F0) [0C]

1D5E6: SYZ 16x16 block mappings (50782) [0D]

1D5EA: SYZ 256x256 block mappins (5481C) [00]

1D5EE: SYZ main level palette (08) [00 85 08]

1D5F2-1D601: Scrap brain zone (05)

1D5F2: SBZ main level patterns (57A66) [0E]

1D5F6: SBZ 16x16 block mappings (56BCC) [0F]

1D5FA: SBZ 256x256 block mappins (5A212) [00]

1D5FE: SBZ main level palette (09) [00 86 09]

1D602-1D611: End of game (06)

1D602: GHZ main level patterns (3DCF2) [00]

1D606: GHZ 16x16 block mappings (3BCF2) [00]

1D60A: GHZ 256256 block mappins (3F09A) [00]

1D60E: GHZ main level palette (13) [00 86 13]

I think that pretty much summs it up. Just change the vaue of the thing you want to modify to the appropriate value. If you wanted to give GHZ the MZ palette, just change the main level palette index number from 04 to 06 and it's done.

Pattern load cues

The pattern load cues are what loads all the peices 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 S1 rom:

This pointer list has an offset index to locate the correct cue. Go here for an explanation of how this works. Note that the number in parenthesis is the recorded number of requests in the cue. If a number follows it in brackets, it means the actual number that exists differs from the recorded one. This means any load requests past the recorded number were not being loaded, but still exist in the rom. 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 cues 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 4ADC-4B63. 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 layout in S1 is broken up into two peices, one for the foreground of the level, and one for the background. When being read into the ram, this data is interleaved to give the entire level layout. The offset index that proceeds the actual level data is a unique offset index. There are three offset values for each act, and four acts for each level value. The first value is the offset to the foreground to use for that act. The value is the offset to the background to use for that act. I have no idea what the third offset was intended to be used for, but it appears that it is not used in the game, so just ignore it.

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

Main level Block mappings

In S1 both the 16x16 and 256x256 block mappings are compressed. This means that in order to edit the block mappings, you'd need to be able to decompress, alter, then recompress them. Right now there is no way to do that, so you can only use the block mapings that are in the rom unless you want to do a savestate hack. Note also that becuase S1 uses 256x256 block mappings, you can't just port the block mappings from later sonic games.

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 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 1 savestate breakdown.

Mappings for Sonic

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 sprite for Sonic, 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 an 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.

Animated pattern load cues

While the function of these cues is identical to the ones in S2 and S2B, these ones are structured entirely differently, and as of yet I haven't figured the entire system of this one out. You can switch the animated pattern load cues between levels easy enough by changing the offset index preceeding them though.

Palettes

All the main palettes used in the game are linked in a pointer table at 2168. 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 S1 rom:

00

2168

SEGA screen palette (2208)

01

2170

Title screen palette (2288)

02

2178

Level select palette (2308)

03

2180

Primary palette line (2388)

04

2188

GHZ level palette (23A8)

05

2190

LZ level palette (2408)

06

2198

MZ level palette (24E8)

07

21A0

SLZ level palette (2548)

08

21A8

SYZ level palette (25A8)

09

21B0

SBZ level palette (2608)

0A

21B8

Special stage palette (26C8)

0B

21C0

LZ underwater level palette (2468)

0C

21C8

SBZ act 3 level palette (2748)

0D

21D0

SBZ act 3 underwater level palette (27A8)

0E

21D8

FZ level palette (2668)

0F

21E0

LZ underwater primary palette line (2828)

10

21E8

SBZ act 3 underwater primary palette line (2848)

11

21F0

Special stage results palette (2868)

12

21F8

Unknown palette (28E8)

13

2200

Ending sequence level palette (2928)

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.

Character start location array

The start location for the characters and the camera for each level are stored in this array at address 6112. 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

The music playlist is very simple to modify. There is one byte per level value, and that byte stores the value of the music track you want to play for that level. The values for the music tracks can be obtained from the sound test in the level select screen.

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 LZ act 1 to load up when you finish SBZ act 2, you would take the location of the table, which in this case is C6F4, and you would add 42 bytes to that location, and then you would replace the next two bytes from that point with 0100. That's becuase you add 8 bytes to the address for every level that comes before it, and in this case there are 5, 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.

Dynamic screen resizing

In S1, the programmers allowed for some very fancy effects to do with the height and width of the sceen. They allowed for the X/Y start, and X/Y ending locations to be changed at any point during the level, based on any event they cared to use. The method they used made the programmers job a little harder though and ate away some performance. They completely redesigned the way this worked for the S2 platform. All the programming for the screen resizing is compiled, so it's very difficult to edit directly.

Music/Sound FX pointers

The music and sound effects in S1 are very easy to change. Note that the midi's in the game start at a sound value of 80, and the sound effects start at a value of A0. If you want to determine the value of the sound or midi you want to work with, just read it staright off the sound test in the level select menu. The pointers to the midi's are at address 71A9C, and the pointers for the sound ffects are at 78B44. Both are simply 4 byte pointers to the address in the rom that the data is located at, so to find the pointer to the sound or midi you want to edit, add 4 bytes to the starting address of the pointer list for every sound or midi that comes before it after it's starting value. To switch a track, just switch thier pointer values.

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 D382. It’s pretty simple, just one pointer per address value. Here's the pointer list in Sonic 1:

01

D382

Sonic [12BD8]

02

D386

??????? [D5B2]

03

D38A

??????? [D5B2]

04

D38E

??????? [D5B2]

05

D392

??????? [D5B2]

06

D396

??????? [D5B2]

07

D39A

??????? [D5B2]

08

D39E

??????? [142F0]

09

D3A2

Sonic in special stage [1B984]

0A

D3A6

??????? [13C98]

0B

D3AA

Bar you hold onto in LZ [11206]

0C

D3AE

Opening blocks that open to pasage sonic gets sucked down in LZ [11346]

0D

D3B2

Unknown. Warps you to somewhere. [EB28]

0E

D3B6

??????? [A61C]

0F

D3BA

??????? [A69C]

10

D3BE

??????? [1C022]

11

D3C2

??????? [7328]

12

D3C6

Spinning light behind glass from SYZ [E90C]

13

D3CA

Fireball from MZ [E296]

14

D3CE

Unknown. Dives through the floor. [E304]

15

D3D2

Swinging spikeball on a chain from SBZ [7952]

16

D3D6

Spear from LZ [11F04]

17

D3DA

Unknown. Flashes between hitable and not hitable, but you can't hurt it, only the other way around. Frame changes in accordance with this. [7CA2]

18

D3DE

Misc standard platforms [7E32]

19

D3F2

??????? [81A8]

1A

D3F6

Collapsable platform [8210]

1B

D3FA

??????? [110C6]

1C

D3FE

Fireball launcher from SLZ [87CA]

1D

D402

??????? [885E]

1E

D406

Double big red explosion [8B4C]

1F

D40A

Crab enemy from GHZ and SYZ [94F0]

20

D40E

Big red explosion [8C1C]

21

D412

Unknown. It just sits there. [1C548]

22

D416

Buzz bomber [97DE]

23

D41A

Unknown. Sprite sits there and flashes. [9932]

24

D41E

Unknown. Sprite changes frame and disappears. [8CF2]

25

D422

Ring [9B26]

26

D426

Monitor [A118]

27

D42A

Normal explosion [8D62]

28

D42E

Unknown. Edges along grund at a terminal rate. As soon (as in immediately) as it leaves the screen it disappears. [8F22]

29

D432

??????? [9412]

2A

D436

One way barrier from SBZ [8934]

2B

D43A

Unknown. Sprite moves off bottom of screen. [AB20]

2C

D43E

Unknown. Sprite changes a few frames, then sits there moving quickly back and forth in a small area. [ABDA]

2D

D442

Drill badnick in LZ [ACA4]

2E

D446

Contents of monitor flying up frm monitor being busted [A302]

2F

D44A

Platfrom in MZ that moves up and down [AEB8]

30

D44E

Unknown. Big block. [B39E]

31

D452

Metal block with spikes on bottom from MZ [B67C]

32

D456

Button [BD2E]

33

D45A

Moveable block in MZ and LZ [BED2]

34

D45E

Title card [C306]

35

D462

??????? [B1DC]

36

D466

Spikes [CE28]

37

D46A

Rings flying out from being hit [9CB6]

38

D46E

??????? [14158]

39

D472

"Game over" sprite [C4B8]

3A

D476

End of level results screen [C572]

3B

D47A

Rock from GHZ [D050]

3C

D47E

Breakable barrier from GHZ [D11C]

3D

D482

Robotnic in his primary ship [17700]

3E

D486

Egg prison [1AB22]

3F

D48A

Large explosion [8DF6]

40

D48E

Motobug from GHZ [F61A]

41

D492

Red spring [DABE]

42

D496

Badnick that appears behind wall and fires projectile from GHZ [DD68]

43

D49A

Metal dude that goes in a ball like sonic from SYZ [DFFA]

44

D49E

Wall barrier from GHZ [E1D4]

45

D4A2

Sideways spikes that were cut in MZ [B99A]

46

D4A6

Block from MZ [E7D0]

47

D4AA

Bumper [E9D0]

48

D4AE

Large ball from GHZ that was cut [17AE4]

49

D4B2

??????? [D0BE]

4A

D4B6

Unknown. Some sort of teleport effect. Most likely belongs to those lost patterns. [14254]

4B

D4BA

Large golden ring [9E06]

4C

D4BE

Lava spurt with lava ripples [ED84]

4D

D4C2

Lava spurt [EE70]

4E

D4C6

Lava wave from MZ [F05E]

4F

D4CA

??????? [F806]

50

D4CE

That ground based badnick with spikes ontop from SYZ [F83A]

51

D4D2

Breakable block in MZ [FC92]

52

D4D6

Misc platforms [FDF8]

53

D4DA

Platform made up of small blocks that collapses [8320]

54

D4DE

Sprite for lava hurting you [F1B8]

55

D4E2

Bat from MZ [100A8]

56

D4E6

Block from SYZ [10286]

57

D4EA

Unknown. A small sprite with a small collision box that hurts you, but you can't bust it. [10782]

58

D4EE

Same as above, but different image [10976]

59

D502

Raising platforms from SLZ [10AD2]

5A

D506

Platform moving in circular motion in SLZ [10D5A]

5B

D50A

Lowering staircase from SLZ [10E90]

5C

D50E

Pylon in foreground frm SLZ [11044]

5D

D512

Fan from SLZ [114FC]

5E

D516

See saw [1163C]

5F

D51A

Walking bomb [119F6]

60

D51E

Badnick surrounded by spikeballs that shoots them at you [11CCE]

61

D522

Misc blocks from LZ [11FD4]

62

D526

Stone head that launches projectile in LZ [121E8]

63

D52A

Rotating wheel in LZ [1233C]

64

D52E

Small bubble [126A4]

65

D532

moving water sprites from LZ [12A9E]

66

D536

Spinning wheel in SBZ that shoots you off in different directions [1509A]

67

D53A

Spinning circle on wheel from SBZ [154E2]

68

D53E

??????? [1568E]

69

D542

Various platforms from SBZ [15730]

6A

D546

Giant pizza slicer thing from SBZ [1597C]

6B

D54A

Misc blocks in SBZ [15C12]

6C

D54E

Spikewheel from SBZ that runs through floor [15FF8]

6D

D552

Unknown. Looks like flamepipe frm SBZ [E4E0]

6E

D556

Broken pipe that lets out fire from SBZ [16146]

6F

D55A

??????? [1626A]

70

D55E

Big moving rectangle in SBZ [1652A]

71

D562

Unknown. A collsion box but no image. [1141A]

72

D566

Unknown. A spin tube? [16668]

73

D56A

Robotnic flying his default ship. [18230]

74

D56E

Unknown. Changes frames back and forth for awhile, and it can hurt you but you can't hurt it, then it diappears. [186A4]