SCHG

Nem s2b

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

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 beta:

00

Emerald Hill zone

02

Wood zone

04

Metropolis zone

05

Metropolis zone act 3

07

Hill Top zone

08

Hidden Palace zone

0A

Oil Ocean zone

0B

Dust Hill zone

0C

Casino Night zone

0D

Chemical Plant zone

0E

Genocide City zone

0F

Neo Green Hill zone

10

Death Egg 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 20000. 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.

To indicate sections containing leftover data from previous builds, a colour
coding system is in place. The address value for a block of data will be coloured
if that block of data is from a previous build. Different colours are used to indicate
layering of this data. Red is the first layer, green is the second, blue is the
third, yellow is the fourth, and pink is the fifth. This is not to indicate the build
that a block of data belongs to, so it doesn't mean that all lost data that's coloured
in red is from the same build. In many cases, it's impossible to relate any two blocks
of data from different sections to each other.

Also, any patterns that are not used anywhere in the game will be preceeded by this red
dot . Patterns located in sections of lost data will not be
marked in this way however.

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. 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 S2B 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 <a href="#Palettes">here</a>. 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 cue's

The pattern load cue's 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 cue's in
the S2B 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 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 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 S2B is stored in the rom in a way similar to how the level
layout is stored in the ram in S3&K. All the level data for a level is broken
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, and is similar to a double offset index. There are two offset values for each
act. The first offset is linking to the data for the foreground for that act, and the
second offset is linking to the background for that act. The level data itself
is not compressed however, so you can just edit it directly. For information on
how to edit it, check the savestate section.

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

Main level block mappings

In the S2B rom, the 128x128 block mappings are compressed, but the 16x16 block
mappings are not. This means you can edit the 16x16 block mappings directly,
but the 128x128 block mappings must be decomporessed to be edited effectively.
At this point in time, there is no untility that is capable of compressing
data into the format used by 128x128 block mappings, so the only thing that's
really possible for now is porting the block mappings from one level to another.
For information on what the block mappings do, and how to edit them, check the
savestate section.

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

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 Becuase 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
four byte blocks 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 16 colours
(0007). Here's a listing of the palette pointers in the S2B rom:

00

294E

SEGA screen palette (2A16)

01

2956

Title screen palette (2A96)

02

295E

Level select palette (2B16)

03

2966

Primary palette line (2B96)

04

296E

EHZ level palette (2BB6)

05

2976

01 level palette (2BB6)

06

297E

WZ level palette (2C16)

07

2986

03 level palette (2BB6)

08

298E

MTZ level palette (2C76)

09

2996

05 level palette (2C76)

0A

299E

06 level palette (2F36)

0B

29A6

HTZ level palette (2CD6)

0C

29AE

HPZ level palette (2D36)

0D

29B6

09 level palette (2BB6)

0E

29BE

OOZ level palette (2E16)

0F

29C6

MCZ level palette (2E76)

10

29CE

CNZ level palette (2ED6)

11

29D6

CPZ level palette (2F96)

12

29DE

GCZ level palette (2BB6)

13

29E6

ARZ level palette (3076)

14

29EE

DEZ level palette (2BB6)

15

29F6

HPZ underwater palette (2D96)

16

29FE

CPZ underwater palette (2FF6)

17

2A06

ARZ underwater palette (30D6)

18

2A0E

Sonic 1 special stage palette (3156)

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 5986, 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 5B02. 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 BF9A, 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 <a href="#offset">here</a>. 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.

Leftover data from previous builds

All through the S2B rom, there are blocks of leftover data from earlier builds of the game.
You see, when sonic team were working on the game, they would compile beta versions of the
game onto flashcarts, for test purposes and distribution. Because the data was compiled directly
onto the cart, any locations that didn't have to be written to retained the data they posessed
before. On a final release cart, this simply would've resuled in blocks of data all contaning
the value of FF, but in the case of this flashcart, data for earlier versions of the game had
been written to these areas previously. Any areas of lost data that I have extra information
about will be noted here.

End of compressed ARZ 128x128 block mappings

This small reminant of a rather recent build indicates a minor change in the above
blocks of data, which resulted in a slightly shorter file size. This was most likely
just a minor amendment to the block mappings for a level, resulting in them not
compressing quite as well.

large chunk of CNZ 128x128 block mappings

This contains a large proportion of an earlier version of the CNZ 128x128 block
mappings. The block of data is missing the first 3340 (D0C) bytes. From this
we can see a massive chanage in CNZ between this compilation and the one in our
beta. These block mappings have been changed so radically, that only a pattern
in thier layout is recogniseable when compared to our current beta one. This
indicates a massive restructuring in the order of the 16x16 block mappings of
this build as well, but unfortunately that data was written over.

CPZ patterns/block mappings

These are the complete patterns and block mappings for an earlier version of CPZ.
There are a few minor changes in the patterns, and some fairly major changes in the
16x16 and 128x128 block mappings.

Compressed ARZ 128x128 block mappings

This lost data is in an uncompiled form, and at first I mistook it for code. Apart
from the fact it is in this form, the data appears to be very close to that of our
current beta. There is a commented line at the very start of the block, which contains
further information about the block of compressed data. Thanks go out to Iceknight,
who figured out that the text in this comment was in Kanji, and thanks go out to
Kojichao and sth2k for translating it. The commented line reads:

I had already guessed the purpose of the first three numbers, But I still can't figure
out the puropse of the last one, or at least not one that would be worth putting in a
comment. If anyone has any idea what the fourth number is used for, let me know.

lost Pattern load cue's

Due to changes in the structure of the rom, there are quite a few pattern load cue's
left from previous compilations. In fact, in this one small area in the rom, I have
identified six different layers of lost data from previous compilations, and these
compilations seem to be a lot newer than the remains of level data judging by some
of the link locations on the cue. Here's a breakdown of the lost pattern load cue's:

If you want more info on the pattern load cue's, go here.
From these load cue's we can see that there were some changes in the locations of
some of the small blocks of compressed art, and that has resulted in some of the
older pointers linking to the wrong data. The thing that I find most interesting
about this deals with the load cue for the end of signpost level load cue. You'll
notice with this cue that the last two load requests were cutoff in our beta, which
link to those hidden bonues at the end of an act in Sonic 1, and more importantly,
the flash effect from entering the giant golden ring, that leads to a special stage.
The patterns for this ring are in the rom, but until I saw this I wasn't convinced
that it was ever implemented in the game. Now, if you look at the cue that's colour
coded yellow, you'll notice it isn't cutoff yet, but in the green compilation it
has been, so somewhere between those two compilations, the ideas they were using
for the method of entering the special stage, and the bonus points at the end of a
level were changed. If you compare the link locations of the main level patterns
for any of the levels in the yellow load cue's with the current link locations,
and the lost block mappings and art there, it's clear that all these cue's are for
compilations made after the compression methods for both 16x16 and 128x128 block
mappings were put in place, which either means that those blocks of data with the
block mappings and level patterns are from a much earlier compilation than I
figured, or the ideas for the end of a level were changed just before the time of
our beta.

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

Now, the value assigned to a sprite in the game is done by a pointer index at
D01A-D249. It’s pretty simple, just one pointer per address value. Here's the
pointer list in Sonic 2 beta:

01

Sonic [FC48]

02

Tails [10E38]

03

Collision index switcher [144B0]

04

??????? [15090]

05

Tails' tail [11F96]

06

Spiral loop in EHZ [1572C]

07

??????? [180D0]

08

??????? [12B42]

09

Sonic from S1 special stage [21D40]

0A

Flashing number that gives air countdown [1207C]

0B

Block that tips you off from CPZ [148AC]

0C

Unknown (A small one way block. At set intervals the platform raises slightly then goes back down. Movement is slow and erattic, not smooth.) [149FC]

0D

Signpost [F1F4]

0E

Unknown (a huge block locked onscreen) [B7B4]

0F

Unknown (very very weird. Using the blocks for a computer, every time you press jump another block for it appears locked onscreen int he top left corner) [B83A]

10

??????? [223E2]

11

Bridge [7FDC]

12

The master emerald [14AFC]

13

Waterfall from HPZ [14B78]

14

See-saw [15B8C]

15

Unknown (crashes emulator) [85F8]

16

Diagnally moving and falling platform from HTZ [1600C]

17

Ball badnick from CPZ that goes up one tube and down another [8B9C]

18

Fixed large platform from CPZ [8D38]

19

Large platform from CPZ moving from side to side [1621C]

1A

Collapsing platform from OOZ [9128]

1B

Boosters from CPZ [16468]

1C

??????? [999C]

1D

Enemy made up of small blue balls in CPZ [165B0]

1E

Spin-tube from CPZ [16724]

1F

Breakaway platform made up of small blocks from MZ in S1 [9274]

20

Unknown (An invincible object that drops two fireballs at a time, one on either side. object is fixed and cannot be hurt.) [17174]