Interesting, so that's why it doesn't crash if you place and break tons of S monitors with Knuckles instead.
FYI, I confirmed my theory: if you find this piece of code: [68k]Queue_Kos_Module: lea (Kos_module_queue).w,a2 tst.l (a2) ; is the first slot free? beq.s Process_Kos_Module_Queue_Init ; if it is, branch addq.w #6,a2 ; otherwise, check next slot $$findFreeSlot: tst.l (a2) beq.s $$freeSlotFound addq.w #6,a2 bra.s $$findFreeSlot ; --------------------------------------------------------------------------- $$freeSlotFound: move.l a1,(a2)+ ; store source address move.w d2,(a2)+ ; store destination VRAM address rts ; End of function Queue_Kos_Module[/68k] and replace it with this: [68k]Queue_Kos_Module: lea (Kos_module_queue).w,a2 tst.l (a2) ; is the first slot free? beq.s Process_Kos_Module_Queue_Init ; if it is, branch moveq #$1E/6-2,d3 ; -2 since we already checked one slot; I *think* $1E is the queue size? addq.w #6,a2 ; otherwise, check next slot $$findFreeSlot: tst.l (a2) beq.s $$freeSlotFound addq.w #6,a2 dbra d3,$$findFreeSlot rts ; --------------------------------------------------------------------------- $$freeSlotFound: move.l a1,(a2)+ ; store source address move.w d2,(a2)+ ; store destination VRAM address rts ; End of function Queue_Kos_Module[/68k] then you can break as many monitors as you wish and nothing will happen. Funny thing: future versions of SCH use KosM and don't have the above bounds check, but even if I were to add a S3&K-like S monitor, it still would not crash because the Hyper Stars only get queued for decoding if they are not loaded already.
By the strict definition of a glitch, though, how relevant is that distinction? In all the time I've been lurking around here, and other sites, I've seen this argument presented, but never understood it in full.... I mean, I could see deliberately causing the aforementioned problem as one thing, but doing one thing, and another problem popping up down the pike due to it seems different, to me at least.
The thing about debug is you're intentionally putting the game into an unstable mode designed specifically for testing. Things aren't going to behave as they should. When glitches happen in regular gameplay though, you'll have found a bug in the system. It's something that shouldn't be there and has, for whatever reason, slipped through the net.
Well, Debug mode can help them find bugs yes, like "Oh we need to test this badnik but I don't want to go all the way over there, so I'll just plant one." But I don't think "The game had a seizure because you planted 50 Super Sonic boxes" counts as a bug really. It depends on what it's used for.
Exactly. Most games have some form of debug mode while in development (and in the case of the classic Sonic games, they're left in for release). Typically they involve a level select, some method of moving about the level a lot more quickly, object manipulation, etc.
I encountered the term well before venturing online - I would imagine it came from Sega of America when cheats were officially revealed.
If 'anything goes' then spawning a boss object when the graphics are not loaded can also be considered a bug, Or using Game Genie to modify a random address. Or Plugging the cart out of the system while running. In the instruction manual doesn't say to not do that. Its the game's fault the system freezes.
It's called Edit Mode in the leftover source code that was found in Sonic 2's "Nick Arcade" prototype also:
Nobody said anything goes. I was pointing out the difference between a bug and a glitch. None of those things would be bugs, but they'd certainly be glitches.
Most of the cheat references in magazines/guides I saw in the UK in the nineties referred to it as "level design mode", a term that seems to have been almost completely lost to time, apart from this one presumably ancient cheat page. As a youngster, this terminology left me quite disappointed when I realised any changes would disappear as soon as I simply moved away - but I don't know if I'd ever even have bothered putting in a code for "debug mode", which sounds pretty boring.
It has a lot to do with RAM addresses being the same with the level select enabled flag not being unset. Sonic & Knuckles and Sonic 1 use a different RAM address than Sonic 2 & 3 but it's the same one between them. Sonic 3 & Knuckles will use Sonic 1 & Sonic & Knuckles' level select flag RAM address, I'm not sure if the swap would actually work here, though.
The official Sonic 1 and 2 strategy guides call it debug mode. They were published in 1992. EDIT: Just checked, it actually calls it the "Construction Set mode" but the Sonic 3/Sonic CD guide from 1994 calls it "Debug mode." Also "Cheats! The ultimate guide for Genesis and SNES" from gamepro lists it as "debug mode' for Sonic 1, 2, and 3. SWATPro also called it debug mode.
Well okay then http://retrocdn.net/index.php?title=File:GamePro_US_029.pdf&page=133 GamePro #29, "December 1991". http://retrocdn.net/index.php?title=File:MeanMachines_UK_16.pdf&page=37 Mean Machines #16, "January 1992". And there's a bunch in 1993 for Sonic 2.
I'm guessing the term isn't actually from Sega, then. Any idea what the debug mode in Ghouls n Ghosts was referred to?