Hi everyone.. issue 216 of Retro Gamer is officially out and we have our Sonic 1 prototype article, which is a brief backstory on Buckaroo’s discovery. A very interesting story and still amazed that this exists. I had images of the article here but they were too small and blurry. I uploaded higher quality images 1-2 comments lower.. Enjoy!!
Is it possible to upload larger images? The resolution of both are just 246px by 320 px (e.g. too small to read)
I really thought this day would never come. I've been out of the "loop" with the sonic community for a long time. I only just found out about this amazing find today, and only because I saw the proto ping on one of my persistent ebay searches. Good work everyone, a massive shoutout to Buckaroo for dumping this, as well as drx for your incredible work not only releasing this, but hunting for and releasing so many things over so many years. As an aside, by some major fluke I'm continuing the trend from earlier in this thread, it's also actually my birthday today on the day I discover this. This release holds a particular fondness for me, and it's around this little guy in particular: This is of course Splats the bunny. What's probably been lost to time is that I originally found his artwork in the Sonic 1 ROM. On the 9th of May 2002 if my filesystem timestamps are correct. Those images I posted above are the ones I posted online when I made the discovery, before that nobody knew that artwork was still in there. I actually consider this my first significant contribution to the community. I had done some personal digging through these roms in fits and bursts since I first came across the famous Simon Wai Sonic 2 beta around January 2001. First I started by messing around in savestates. For fun, here's some of my earliest notes from my archives, when I was messing around with genecyst savestate files, timestamp 14 Feb 2001: Code (Text): Block breakdown 0-477: Basic file stuff and a few unknown variables 478-2477: Music 2478-A477: Animated sprite makeup A478-B477: Level design B478-D477: Tile makeup (no effect on sprites) D478-F477: Character position and animation F478-12477: Camera position, water level, pallette, background makeup/movement, level dimensions, map triggers, ring and non active sprite locations, collision info, debug mode 12478-1C477: Patterns 1C478-1D477: Active sprite makeup 1D478-1E477: No noticeable effect 1E478-1F477: Makeup of what's currently in foreground 1F478-20477: No noticeable effect 20478-21477: Makeup of what's currently in background 21478-22477: No noticeable effect 22478-22510: A few more unknown variables Internal groups FA78-10060: Collision info 10C68-1126B: Sprites 1147A-11577: Underwater pallette if applicable Single variables 11278 and 11279: Camera x position 1127C and 1127D: Camera y position 1133E and 1133F: Screen height 11340 and 11341: Screen x start position 11342 and 11343: Screen x start position 11346 and 11347: Camera speed D480 and D481: Character x position D484 and D485: Character y position D488 and D489: Horizontal speed of character D48A and D48B: Vertical speed of character (8000 is max up 7FFF is max down and working back accordingly) D492: Character's current animation frame D4A3: Slide value (80 and over is sliding, 7F and under is not sliding) D4A8 and D489: Character flashing (0000 not flashing, 0001 and up flashing) D4A0: Smoke when dashing (00 off, 01 and up on) General stuff D4B6 and D4B7: Something to do with character and collision with layers D4BE and D4BF: D478-DCA0: Makes it freeze D478-D67B: Something to do with character animations and character position D7F8-D802: Makes it freeze 000AC and 000AD something to do with what tails is currently doing 11368-11560: Something to do with screen size or movement 10060-100EC: Wiped collision info completely 11A68-11C59: Things go unbelevably weird in terms of patterns and a few other things. Wipes map triggers 12088-12477: Locks up exact level length: 22C0 Last value tweaked: D4B7 After a few weeks of messing around, I went on to other things, until I looked at it again a year or so later, and found quite a vibrant community had sprung up around this beta, which had found a lot of cool stuff. At this point I got hooked, and started digging into the games deeper myself. On the 6th of March 2002 I launched my website, based at that time mostly around documenting the savestate layout, such as where key variables were held in memory, and the format for the data blocks that were loaded into memory, such as pattern data, mapping data, and collision data. Although this was based on my own original research, a lot of it had probably already been covered elsewhere. Honestly, the community was fairly disorganised back then and it was hard to figure out what was "known" and what wasn't. In April 2002, my attention had turned squarely towards the layouts of the ROM files themselves, with the graphics tiles in their still unbroken compression format making up a sizable portion of that. Since I was literally mapping out every byte of the ROM files from beginning to end, it became easy to locate unused data embedded in the ROMS. Once I'd come across a number of new sets of tile data I hadn't seen before, I created a thread on the forums to share them. I think it was the Area51 EZboard at that time. Everything I posted at first had apparently already been discovered months earlier by others, and I remember Sonique got a bit stroppy with me for not checking what was already known. Honestly that was hard because you had to trawl all the threads in the forum, it wasn't all organized in a nice wiki like it is here on Sonic Retro today. Well a few hours later I added some new graphics I'd dug up as I kept on actively advancing through the ROM, among which was Splats the bunny. This was, I believe, the first genuinely new significant discovery that I made, and the buzz I got from being the first person to ever see those graphics outside of the developers and perhaps early reviewers, is the main thing that pushed me onwards to keep on documenting and finding new things. All the time I was pulling apart the Sonic 1 ROM though, I hoped to find the code to bring Splats to life. I pulled that ROM apart, and I mean totally apart if you're familiar with my early efforts documenting the layout of these ROMS and then later disassembling them too, and it was sad when I knew for sure that code for this guy no longer existed in the final game. Seeing Splats come to life as it was originally designed was, for me, one of the things I personally wanted to see probably more than anything else. Today, almost 19 years after I first discovered the Splats artwork, I got to see him properly animated and jumping around for the first time. It's a really cool feeling. I must say, it's strange knowing there's another brand new beta sitting there now, possibly full of all kinds of other undiscovered goodies. Kind of brings back the feelings of the early days in the community, like there's a treasure trove right there just waiting to be unearthed. I remember I found this at the same time as Splats: Anyone know if there's code connected to this in the new Sonic 1 beta? If Splats is in there, maybe this is too?
Ok, had time to fully read through this thread, and have a good play around with the ROM..... and I couldn't resist the urge to get my hands a bit dirty. Since nobody seems to have done a thorough scrub for hidden artwork in the binary itself, I decided to dust off my tools from days gone by and do a sweep myself. Nothing fancy, this is what I did: 1. Fired up nemsrch.exe to locate and extract all Nemesis compressed artwork from the final and prototype roms 2. Used a file duplicate search tool to locate all matching files and delete the duplicates from the extracted proto set. This left me with 21 sets of artwork. 3. Dug up Tile Layer Pro. Tried it out, and remembered how much I hated it. Found the more modern "Tile Molester" that all the cool kids seem to be using these days, and used it to convert all the data to PNG files. And here you go, a flat list of all compressed artwork in the ROM which is either different or missing from the final release, with an arbitrary main palette from S2 loaded. Raw, unorganized, I leave further investigation to the masses. 0x00018000: 0x00018720: 0x00026672: 0x00027DBE: 0x0002961E: 0x000297B6: 0x0002A104: 0x0002A386: 0x0002BBC2: 0x0002D2FC: 0x0002E6C8: 0x0002E77C: 0x0002E8E6: 0x00035EF8: 0x00046D20: 0x0004D8F8: 0x00053A04: 0x00060864: 0x0006512E:
"These graphics were found by Nemesis" - it's like SWS2B in real time. Others have dug a lot of this out, but I think that Chaos Emerald is new
Decided to do one more thing. I made the original clean Sonic 2 disassembly here a looooooong time ago. It was the first disassembly of a Mega Drive game that properly separated code and data, where you could rearrange and move anything around and recompile a working ROM, since all code was properly disassembled as code, data blocks were properly separated, and relative offsets were embedded in offset form rather than absolute addresses. In order to do this, I used a hacked version of Gens to spit out known valid code locations encountered during execution, then bashed the game exploring and interacting with everything I could. I fed that data into IDA Pro as disassembly start locations, then started cleaning everything up, fixing references, finding unexplored branch paths, filling out unexplored jump table entries, etc. Generating the input to IDA pro was quick, a few hours, but the cleanup took me over a month of 8+ hour days. When I made my emulator Exodus (https://www.exodusemulator.com), as well as all the debug features I built, I made one specific feature with communities like this in mind: Active Disassembly. This feature tracks offsets, code references, data references, array bounds, jump tables, PC relative addressing, and a bunch of other things within the emulator. In a nutshell, I designed it to automatically do in a few seconds what took me a month to do manually. Once it was done, I was able to generate a disassembly of Sonic 2 similar to the result I achieved manually, but in a matter of hours rather than a month. I think this feature is still not really known or understood well, so I figured I'd throw it at the Sonic 1 proto. I just messed around for about 30 minutes to be thorough, and got a pretty damn near complete disassembly out of it. Should be useful to someone. Here's the standalone ASM file exported from Exodus directly: https://nemesis.exodusemulator.com/MegaDrive/S1Proto/Sonic the Hedgehog (16-bit) (Prototype).asm And here's an IDA Pro disassembly, with the IDC script I used to generate it, and the Exodus savestate and debug savestate that generated the IDC script. From this you could continue editing in IDA pro, or load the state in Exodus to restore the active disassembly session and repeat the export yourself if you want, or expand the analysis. https://nemesis.exodusemulator.com/MegaDrive/S1Proto/Sonic1ProtoActiveDisassembly.zip
A lot of those unused graphics are documented on The Cutting Room Floor, along with the palettes. These are already accounted for: 0x00018000 0x00018720 (the SEGA logo in the beginning) 0x00026672 0x0002A386 0x0002E8E6 (listed as object 4B) 0x00060864 0x0006512E 0x000651FE These ones aren't there on TCRF: 0x00027DBE 0x0002961E 0x000297B6 0x0002A104 0x0002BBC2 0x00065B76 These I question to why it's different or unused in the prototype: 0x0002D2FC (the zone names) 0x0002E6C8 (the points scored when destroying enemines, EDIT: Oh, so 200, 500, and 1000 go unused in the prototype) 0x0002E77C (game/time over sign) These would need palettes applied to them to better observed what's missing: 0x00035EF8 (looks like Labyrinth Zone stuff) 0x00046D20 (looks like Star Light Zone stuff) 0x0004D8F8 (looks like Sparkling Zone stuff) 0x00053A04 (looks like Clock Work Zone stuff)
Can we stop uploading scans of a magazine that's literally on sale on store shelves at this very moment, please? Go and buy the damn thing, it's part of the release! I have removed the legible ones twice now, stop doing it.
I apologize.. I had already bought the digital issue of the magazine and that’s how I was able to share.. will know not to cross boundaries for next time
I'm ignorant of how video game palettes work, so apologies if this is a dumb question, but does that Chaos Emerald only exist in this prototype with a blue colour scheme? In SegaSonic Bros. and the 8-bit Sonic 1 all six Chaos Emeralds are blue, so could this be related?
I'm sure someone could explain better than me, but I'll take a crack at it: The palette is a table that tells the system what color to draw a certain graphic. By changing what colors are in the palette, you can recolor something without actually having to redraw it. Everything Nemesis uploaded is using Sonic's palette, so the Emerald appears blue, but by changing the palette, the Emerald could instantly appear a different color, without needing a separate Emerald graphic for each color.
Yes but in the final game, the blue and red emeralds for instance are different graphics which both use Sonic's palette. If there's only a single emerald graphic in the prototype and it's blue, then it lends credence to what @Pengi is suggesting.
Ah, yes. I forgot the lights from the GHZ boss aren't implemented/animated yet. Which technically makes them unused. The same happens on that Japanese video tape that was discovered last year.
Yep, I'd seen there was a fair bit up there, but I was leaving the cross checking to others. In terms of these three specific tilesets you referenced, I'm not claiming they're unused in the prototype (although as you note the points seem to be), I'm just checking for any artwork blocks which aren't included in the final release, or contain binary differences to what's there. For those three art blocks, here's the breakdown (not correct palette again): Zone names: - Proto - Final - Diff Points: - Proto - Final - Diff Game/Time over: - Proto - Final - Diff
Not sure if this tidbit helps at all, but in the final game, if you fall out of the special stage boundaries into the void, you'll first come across a broken rotating wall full of only blue chaos emeralds. One of these emeralds is actually obtainable, and with some debug trickery and some well placed jumps, you can complete a full playthrough of the game with 6 blue emeralds. The game has no trouble doing this either, and you can even mix and match emeralds too (like getting the good ending with 4 blue emeralds, a yellow one, and a red one) :p
So I read the Retro Gamer article. Without revealing the depth of its contents and the text of the story, it's frustrating that it leaves us with a big mystery as to the origin of just how this prototype survived. The story tells us some of how it was discovered, but not a lot about where it's been (Not the fault of the author or those who delivered it. It simply isn't known!). There's 30 years of history in where that cart has been that we don't know about, and it seems to be sheer dumb luck that it was discovered. Even more disturbing when you realize that it's possible someone could've had beta and not even known it because they don't know the games that well. Luckily, that didn't happen here. Makes you wonder what else is lurking in a pile somewhere risking being lost by bitrot? Luckily, we've now found pretty much all of the existing big ones for classic Sonic. At this point, Sonic CD R2 and the real art assets of Sonic 2's desert level are the only possible "big finds" we could even really come across anymore, and they likely don't even exist in playable builds.
For what it's worth, going by my recollection, the Chaos Emeralds were only Blue in the Master System version of Sonic the Hedgehog. As a kid, I pinned it down to technical limitations. As an adult, knowing how many other scrapped concepts the Master System version ended up using?... This is purely speculative, of course. But an observation that feels worth pointing out. EDIT: I'm a potato. This's what I get for rushing replies whilst being busy. Fred is right.
