The Sonic 3 prototype is rather well known for having many abilities that didn't make it into the final; of course, the most infamous of these is the proto-"Drop Dash" you can perform in-game, but there are also two unused abilities that can only be accessed through hacking. Silver Sonic 1992 covered both of them in the video below, but I will summarize them both here as well: The first of these abilities is a multidirectional air dash, unreferenced by any code but present at $B8B8. A code analysis by Silver Sonic 1992 found out that this was an early version of Hyper Sonic's air dash in Sonic 3 & Knuckles; it functions similarly to the final, but does not yet destroy all enemies on screen and creates camera problems due to flaws with how the camera movement was programmed into it. It also, strangely, has a check to ensure the camera moves for Tails (at this point, Tails is more similar to his Sonic 2 programming than Sonic 3), meaning that he likely too was meant to use it in some manner. The second of these abilities should get called by the Sonic_JumpHeight code, but is stopped right before by a branch to a return command; disabling said branch and pressing A in the air causes Sonic to shoot out a ring in both directions without deducting from his ring count. This should in theory also destroy badniks, monitors, and even collect rings, however it (for some bizarre reason) makes reference to Sonic's collision code, meaning it often fails to detect anything. This wasn't repurposed for anything in the final. With how similar the Hyper Dash is in the final, I'll only be posting the ring throw code here. Code (Text): Sonic_ThrowRings: btst #2,Obj_Status(a0) beq.w Offset_0x00B8B6 move.b (Control_Ports_Logical_Data+1).w,d0 andi.b #$20,d0 beq.s Offset_0x00B83A move.w Obj_Speed_X(a0),d2 bsr.w SingleObjectLoad bne.w Offset_0x00B80C bsr.w Obj_ThrownRing move.w #$800,Obj_Speed_X(a1) move.w #0,Obj_Speed_Y(a1) add.w d2,Obj_Speed_X(a1) bsr.w SingleObjectLoad bne.w Offset_0x00B80C bsr.w Obj_ThrownRing move.w #-$800,Obj_Speed_X(a1) move.w #0,Obj_Speed_Y(a1) add.w d2,Obj_Speed_X(a1) Offset_0x00B80C: btst #2,Obj_Status(a0) beq.s Offset_0x00B83A bclr #2,Obj_Status(a0) move.b Obj_Height_2(a0),d0 move.b Obj_Height_3(a0),Obj_Height_2(a0) move.b Obj_Width_3(a0),Obj_Width_2(a0) move.b #0,Obj_Ani_Number(a0) sub.b Obj_Height_3(a0),d0 ext.w d0 add.w d0,Obj_Y(a0) Offset_0x00B83A: move.b (Control_Ports_Logical_Data+1).w,d0 andi.b #$10,d0 beq.s Offset_0x00B8B6 move.w Obj_Speed_X(a0),d2 bsr.w SingleObjectLoad bne.w Offset_0x00B870 bsr.w Obj_ThrownRing move.w #$800,Obj_Speed_X(a1) btst #0,Obj_Status(a0) beq.s Offset_0x00B866 neg.w Obj_Speed_X(a1) Offset_0x00B866: move.w #0,Obj_Speed_Y(a1) add.w d2,Obj_Speed_X(a1) Offset_0x00B870: btst #2,Obj_Status(a0) beq.s Offset_0x00B89E bclr #2,Obj_Status(a0) move.b Obj_Height_2(a0),d0 move.b Obj_Height_3(a0),Obj_Height_2(a0) move.b Obj_Width_3(a0),Obj_Width_2(a0) move.b #0,Obj_Ani_Number(a0) sub.b Obj_Height_3(a0),d0 ext.w d0 add.w d0,Obj_Y(a0) Offset_0x00B89E: move.w #0,Obj_Speed_Y(a0) move.w #$200,d0 btst #0,Obj_Status(a0) bne.s Offset_0x00B8B2 neg.w d0 Offset_0x00B8B2: add.w d0,Obj_Speed_X(A0) Offset_0x00B8B6: rts ; End of subroutine Sonic_ThrowRings Code (Text): ; =========================================================================== ; --------------------------------------------------------------------------- ; Object - Thrown Ring ; --------------------------------------------------------------------------- ; Offset_0x00B994: Obj_ThrownRing: move.l #ThrownRing_LoadIndex,(a1) move.w Obj_X(a0),Obj_X(a1) move.w Obj_Y(a0),Obj_Y(a1) move.l #Rings_Mappings,Obj_Map(a1) move.w #$26BC,Obj_Art_VRAM(a1) move.b #$84,Obj_Flags(a1) move.w #$180,Obj_Priority(a1) move.b #8,Obj_Width(a1) rts ;------------------------------------------------------------------------------- ; Offset_0x00B9C8: ThrownRing_LoadIndex: moveq #0,d0 move.b Obj_Routine(a0),d0 move.w ThrownRing_Index(pc,d0.w),d1 jmp ThrownRing_Index(pc,d1.w) ; =========================================================================== ; Offset_0x00B9D6: ThrownRing_Index: dc.w ThrownRing_Init-ThrownRing_Index dc.w ThrownRing_Main-ThrownRing_Index ; =========================================================================== ; Offset_0x00B9DA: ThrownRing_Init: addq.b #2,Obj_Routine(a0) move.b #2,Obj_Ani_Number(a0) move.b #8,Obj_Height_2(a0) move.b #8,Obj_Width_2(a0) bset #1,Obj_Player_Status(a0) ;------------------------------------------------------------------------------- ; Offset_0x00B9F6: ThrownRing_Main: move.l a0,a2 jsr (Touch_Response).l cmpi.b #2,Obj_Routine(a0) beq.s Offset_0x00BA10 nop nop nop nop nop Offset_0x00BA10: cmpi.b #2,Obj_Ani_Number(a0) beq.s Offset_0x00BA22 nop nop nop nop nop Offset_0x00BA22: move.b (Vertical_Interrupt_Count+3).w,d0 andi.w #3,d0 bne.s Offset_0x00BA36 addq.b #1,Obj_Map_Id(a0) andi.b #3,Obj_Map_Id(a0) Offset_0x00BA36: bsr.w SpeedToPos tst.b Obj_Flags(A0) bpl.w DeleteObject bra.w DisplaySprite Also take notice of the "nop" code in the thrown rings; "nop" stands for "no operation" and is typically used for code requiring precise CPU timing, however they are also often used by developers (especially in the Genesis Sonic games) to blank out any code that was there. As a result, the thrown rings likely had some secondary purpose that is now long gone. Now here's where the mystery comes into play... For a long time, concept art for Sonic 3 was extremely limited, that is until the release of Sonic Origins and tons of never before seen pieces. Among these were two scraps showing unused shield ideas for the game: Now a lot of these on their own are nothing special, and indeed many of them did get used in the final just condensed down. However for this, we are interested in two; Flame (#1) and Thunder (#2). Their descriptions, translated, reads "attacks" and "wipes out enemies, takes time to charge." My theory is that the unused abilities in the prototype (the air dash and the ring throw) were, in fact, programmed takes on these abilities; for the air dash, it is often theorized that Hyper Sonic was created as a result of the game split as an incentive to complete the Sonic & Knuckles Special Stages (although I have found no sources to indicate this was ever confirmed, please correct me if I'm wrong), but its presence here creates a hole in that theory. However, with the fact that the Thunder ability was seemingly repurposed for Hyper Sonic in S3K, it's possible that here, it was the original Lightning Shield's double-jump ability. As for the ring throw, it is a bit harder to explain, however it's possible this was an early Fire Shield ability. The evidence here is admittedly a bit looser than the above, but another thing about the above images is that "Bubble" (#3) and "Water" (#4) had no specified double-jump ability, instead they would've allowed you breathe underwater, and move faster underwater respectively; if we do process by elimination, that means that the ring throw ability could only really have been meant for the Fire Shield. As for why it's a ring instead of a fireball, it was a placeholder asset until a proper graphic could be created; Sonic 2 did something similar with the debug pathswapper objects also using the ring graphics. Now it's important to stress that none of this is confirmed (nor likely will be in the future given... Naka's unavailable), so do not take any of this theorizing as truth. The only reason I made these connections was using vague context clues, however at the end of the day, only Sega truly knows what these were meant for (if even that).
There is one thing I think is worth noting though, and that’s base Mecha Sonic’s attacks. Specifically, while two of his attacks (his air dash and his bounce) match up with the Fire and Bubble Shields respectively, his third attack better matches up with the Drop Dash. Following the pattern set by the other attacks and their corresponding Shields, this would suggest that the Drop Dash may have originally been the move associated with the Lightning Shield.
That is also true, and something I never noticed, although that does raise the question on why it's enabled by default for Sonic in the prototype while the other two abilities are intentionally disabled. It's not even like the dropdash is even that hard to disable; how it works is that in the jump code, it sets a number to -1, then triggers it once the "Sonic_ResetOnFloor" routine is thrown. Disabling either more-or-less disables the entire thing. (ignore the variable name; Esrael probably got confused while labelling the variables)
The ring throw and the mention of Mecha Sonic remind me of his 360 degree ring throw while he's super.
Another thing is that the drop dash is available in Competition Mode, unlike all other abilities which lack any code for them specifically in the prototype. It seems more like the drop dash was intended to be a regular ability for Sonic in general rather than a shield ability, as no shields exist in Competition.
(double posting) A sort of addendum I am writing for a few more theories that came to my mind while I'm documenting NyperYuhgard's disassembly: Internally, the Ball Shooter is after the Beam Rocket in both ID, and the position of its code. Taking into account that the Beam Rocket has a different spawn position in the prototype (towards the middle of the stage), is it possible the Launch Base 2 was only having one boss before the split happened? This also would explain why Knuckles never fights it in S3&K, nor Big Arms in the Limited Edition prototypes (Big Arms is completely missing in 1103, not even having any art present). Another observation is how disorganized the object list is towards the end. $B8 to to $C4 are all taken up by IceCap objects, only for it to devolve into the Tunnelbot, hidden monitors (which aren't even used yet), the capsules, Knuckles in the intro, the IceCap trampoline supports, Knuckles' switch (incl. the LBZ cutscene), and the final intro. This suggests that all these objects were added in a rush with no attempt made at organization.
I think the lack of Big Arms in 1103 is highly interesting - perhaps they decided to add a Final Boss in once it became clear that Sonic 3 would be split. Ball Shooter after Beam Rocket is curious, I always thought personally that Ball Shooter was a strangely easy and out of place boss fight. I wonder if perhaps it was conceived for Knuckles because his lower jump height would probably make it more challenging.
Eh, I don't think so for Knuckles as he doesn't fight it at all in his route and there's no indication in either the prototype or the final that he was ever meant to fight it. I just think that Ball Shooter was conceived at the last second to extend Launch Base ever so slightly. I should also bring up this piece of concept art in Origins, which shows that the path to the Death Egg boss was intended to simply be Sonic running along a beam followed by a single boss, so it seems clear that Big Arms was added at the last second to give the game some conclusion, also explaining why they never implemented the "if Super Sonic, do not hurt" check. Might also start using this thread to post other coding oddities, such as an unused Sonic 2-like sound queue system. If you're unaware, Sonic 2 had a strange sound queue setup where each one got assigned a piece of ram in 68k memory, which when called is then run through an input system (Sonic 2 GitHub labels this as "sndDriverInput") to be used by the Z80... this was really just slow and unnecessary, and was replaced with a more optimized one for Sonic 3. However, it seems like the developers initially retained this as the code still exists. In Sonic 3 Alone, all the code below the return command was removed, however the return command was still referenced despite now being completely useless (complete with all the Z80 stops!). The dummy command was finally removed in Sonic & Knuckles, but that STILL left in the Z80 stops.
Is it really? I thought the idea was to minimise the number of times that the Z80 bus is requested by only doing it in the vertical interrupt handler. On top of minimising the amount of time spent waiting for the Z80 bus to be obtained, this also has the benefit of avoiding a race condition: it is possible for the vertical interrupt to occur right after the Z80 bus is requested, but before it is used for anything; since the interrupt handler releases the Z80 bus, this will cause writes to the Z80 RAM to fail, resulting in sounds or even songs to simply not play. Even worse, if the interrupt occurs after the bus is requested, but not after the loop that waits for the bus to be obtained, then the loop will repeat endlessly and the game will freeze. I have no idea why Sonic 3's developers scrapped Sonic 2's system.
I'd also like to point out, in relation to the sound queue, that Sonic CD also has it for its FM sound effects driver, which runs on the Z80.
Ah, that makes sense. Also, take a wild guess who's the unlucky one trying to disassemble the 1103 Z80 driver? (I barely know Z80)
Given that you made a guide on switch Sonic 2's sound queue system to Sonic 3's back in 2014, I wonder if the reason had to do with PCM quality. Or, more likely, the sound queueing system came alongside the new sound driver.
The Z80 driver has been fully disassembled! (almost, data shifting still creates problems) Therefore, let me document other oddities with the driver I've found. Firstly, despite Volume Envelope $25 already existing in the data, it goes unreferenced by the table; $26 is missing entirely. Many sound drivers including Sonic 1 and 2 had a 'priority' system which determines what sounds should not get interrupted (usually the continue sound); Sonic 3 & Knuckles removed this entirely, however the table for it still exists, although the rest of the code seems to have been gutted out already. I am unsure what the $E1852 data block is meant to be. Sonic 1 also had a system called "special SFX" which was used exclusively by Green Hill's waterfalls to play it continually (and the prototype had a few more of these); the final Sonic 3 driver has some remnants from an attempted reimplementation of the system, before it was scrapped in favour of the continuous SFX system. As it turns out, the coordination flag for it does exist (replaced in the final by its continuous SFX flag), but is simply a return command at this point. And finally, you're more than well aware of the horrible sound glitches this prototype has; as it turns out, it's because cfStopTrack doesn't perform the needed bankswitch to the sound bank, relying on the zPlaySound function itself to perform the switch, which it often fails to do.
The $E1852 data block doesn't have anything to do with that table: SoundDriverLoad only loads $1852 bytes of data, stopping short of Offset_0x0E1852. That table is really just referencing RAM address 0x1852, which is an empty space. It would appear that the developers had already reserved space for the universal voice bank, but not filled it in yet. I couldn't tell you what the data at Offset_0x0E1852 is, unfortunately. It appears to start with a single Z80 pointer, but that's all that I can figure out. I wouldn't call the driver's Special SFX support a 'partial reimplementation' of S1's system; vanilla SMPS has pretty much always had Special SFX support built in, the Sonic drivers just tend to remove it as part of their customisation.
Fair point; I just called it "re-implementation" here since I am very, very unfamiliar with Z80 drivers. As for other things I have found, the developers were already in the middle of implementing PAL optimization (although, the final has a bug which still causes the wrong tempo): That value that is called once in the final is called more here; I've called it "zSoundIndex" so far, but I will admit I'm not sure if that is a fully accurate descriptor: (also called in cfStopTrack) zGetPointerTable seemingly uses a RAM variable to get the sound driver pointers; I say seemingly because the bit-perfect decompilation uses RAM $1C02 for it, even though the pointers are located at $1200. Unless there's a Z80 quirk I'm missing:
Double-posting for two reasons. First is that I've created a small hack of the prototype to fix the bankswitch failure, meaning all the irritating sound glitches will no longer occur (missing music restores are caused by a missing feature). And secondly, I think I've figured out how zPointerTable works; both the 1103 and Final driver load a default set of 'variables', except that the final have them all set to $00, making it worthless. Here, however, $1C02 is set to $1200, which is the location of the sound driver pointers are. Since the Z80 needs them byte-swapped, it is listed as $0012 in the 68000 memory. In the final, it instead uses an unused part of the Z80 memory to set a pointer to it... even though it can just directly call it.
