Under the Surface of Classic Sonic

If anyone had caught onto the inputs needed to trigger this secret, it's the same input required to activate the hidden Japanese credits in Sonic 1, on REV01!

As well as the code that sets the secret to be active. Note the lack of the intro Skip flag here.

Another bug that prevents this from appearing is that the code fails to set the global variable to skip the intro to false.

Due to this, it never reaches the code to fully set up the hidden credits.

Below is a reverse-engineered estimate of the code where the game sets up the hidden credits.

A side effect of the C press removal is that its still possible to input the first 6 presses... by hitting 6 frame perfect Down-Right inputs to total a value of 16.

However, in the version included in Sonic Origins, the C press check is not there. Below is an image of a reverse-engineered estimate of what the code for inputs may look like in Origins currently.

In the code that handles cheat inputs, the game looks for 6 presses that are the equivalent to a value of 16 when pressed, followed by Up, Down x3, Left, then Right.

Stealth, also known as Simon Thomley, said the initial input for the 6 presses was a (in engine) C press when he implemented this.

In the remake of Sonic 3 & Knuckles included with Sonic Origins, there is a hidden credits cheat code in the title screen.

However, due to a very specific change in the code that handles cheat inputs, as well as a flag not being set when activated, this is impossible to see under normal play.

Alongside different positioning for the boss, the wheels also do not actually collide with the ground until the bounce off after defeat.

In the Nick Arcade prototype of Sonic 2, there lies leftover scraps of a build process for an even earlier build. One of the things that can be found is an earlier version of Emerald Hill's boss.

It has only 2 hit points, no hitbox for the drill, and a weird bobbing animation.

In the vertical scrolling code, it follows the top boundary + 32. I assume that this might be related to old HUD code that displayed on the top 32 pixels of the screen?

There is unused code that draws a chain of life icons, but that's on the bottom... www.youtube.com/watch?v=zkLf...

Interesting how it can basically do that for each individual axis, and not just none or both at the same time. And no, this code was not reused for later games that do have auto-scrolling.

When a flag is set, then the camera will stop following the player for its assigned axis. Instead, the left or top boundary will be treated as a target position for the camera to slowly scroll towards, hence why this might be related to auto-scrolling. [2/2]

scrh_flag and scrv_flag do function in the Sonic 1 prototype, and may be related to a potential scrapped auto-scroll function.

Each are individually set if the stage boundaries for their respective axis are the same, and change how the camera moves. [1/2]

Also, scra_v_line (0xFFF73E / v_lookshift), the one that tracks the camera's vertical focal point (for looking up and down), is set to the last word in the stage's boundary data, which is always 0x60, but could be changed on a per stage basis.

Wonder what they were planning...

There's some unused variables related to camera scrolling in Sonic 1 and Sonic CD. Here are their official names, taken from Sonic Gems Collection.

Sources:
tcrf.net/Proto:Sonic_...
git.sr.ht/~benoitren/s...
forums.sonicretro.org/index.php?th...

Sonic did get changed to "sonic" in Sonic 3, and was "super_sonic" or "ssonic" for when he's super.

Dr. Eggman was "egg", or "eggman". Metal Sonic was "msnc" or "mecasnc".

Leftover symbol data included a lot of internal names for various things.

Sonic was "play00", "play01", or "play02", depending on the game mode. Tails was "fox" in Sonic 2, but was changed to "miles" in Sonic 3. Knuckles was either "knuckles" or "nuckle". Amy was "emie".

"bit" makes sense for "Nemesis", as it uses a bitstream, and "map" makes sense for "Enigma", as it's used for tilemaps.

"div", I can only guess. My guess is that it's short for "divide", since graphics data does effectively get divided into chunks that are loaded gradually.

Interestingly, lists of graphics to decompress in a batch (the community calls them "PLCs" or "Pattern Load Cues"), are often prefixed with "ddev" (i.e. "ddev01"), and also related function and memory symbols such as "divdevset", "divdevtbl" and "divdevwk".

Sonic Jam apparently also has a variable called "bitdev_d6", which presumably goes with those other 3. Register d6 on the 68000 CPU is used and saved for that exact purpose, so there's that.

The Gems Collection of Sonic CD, despite not using "Nemesis" or "Enigma", has a few leftover variables, which are called "bitdevadr", "bitdevcnt", and "bitdevcnt2", which seem to have been used for decompressing tiles gradually to prevent freezing when loading in new graphics.

"bitdevr", we currently don't have any 100% solid proof, but there have been symbols found that hint towards it.

A Sega CD documentation page revealed a memory address labeled "bitdevwk". This address points to the "Nemesis" code table buffer used by the Sega CD BIOS.

"mapdevr" was found in a collection of symbols leftover in the Nick Arcade prototype of Sonic 2, and the address attached to it was located where the "Enigma" decompression code was at.

Sega did have their own formats. The 2 most well known ones are "Nemesis" and "Enigma". "Nemesis" was used for tile graphics and "Enigma" was used for tilemaps.

Symbol data revealed "Nemesis" to potentially be called "bitdevr", and "Enigma" to actually be called "mapdevr".

Clownacy was also the one who found out that variant of LZSS from Okumura was "Saxman".

Funnily, they are compressed in LZEXE themselves, so to help make reverse engineering efforts easier, I extracted the LZEXE and UPACKEXE code from the EXEs and decompressed them and uploaded them here: drive.google.com/file/d/13Wmz...

Unfortunately, the original source code for LZEXE seems to have been lost, but the author did provide the executable files.

Fun fact, LZEXE is a derivative LZSS format distributed by Okumura, which is about the same exact format as the one known as "Saxman". Sonic 2 used that format for compressing sound data.

bellard.org/lzexe/okumur...