A few things on this game. (All of these are based on the Japanese release. I did most of this stuff with the help of Exodus and IDA Pro) 1.) Art This game uses lots of Nemesis compression. The only thing that isn't compressed as far as I can tell is Mickey's player sprite (cutscene Mickey tiles are compressed). The game also uses Enigma compression too, but I'm not entirely sure what it could be using it for. It doesn't seem to be using it for any graphics, maybe related to tile mapping. It isn't used very often. Nemesis is usually used for graphics, but I've seen archives for tile/stage mappings too. I played through the entire game and documented every used Nemesis archive in the game. I compiled a list of the location ranges of each archive (note, names are kinda ambiguous and are kinda wrong, but it'll give you a good idea of what they might be). There are a few interesting things I noticed. For some reason, the first Toyland stage loads the ghosts from the third Forest stage even though they aren't used (could be wrong though). Also, every tea cup stage in the game loads those swedish fish enemies, even though there's no way they can jump out of the water. There are only two unused Nemesis archives in the entire ROM. The first is located at $49900, and appears to be "Mickey Mouse" in big multi colored text: The second at $4AD52 appears to be maybe some kind of mapping data (perhaps for this art): 2.) Level Select and No Clip remnants One thing that always made me curious about this game was it's lack of in game cheat codes. I investigated all the rumored cheat codes that were floating around for the game, and while all of them are false, there is evidence that they exist or used to exist in the game. The first thing was a level select. The only instance of a level select code existing was in an issue of Hobby Consolas detailing a cheat if you press all the buttons on the title screen. This implies that upon pressing start at the title screen, you should see the results immediately after. There are no special game screens for a stage select nor were there any subroutines around the title screen routines that were unused. However, upon looking at the sound test I found unused code at $A02C that directly manipulated the current stage variable in RAM: Code (ASM): ROM:0000A02C GM_SoundTest_StageSelect: ; Unused! Seems to be loaded within the sound test? ROM:0000A02C move.b (RAM_CurrentPressedButton+1).w,d5 ROM:0000A030 move.w (RAM_CurrentStageID).w,d0 ; Move Data from Source to Destination ROM:0000A034 btst #6,d5 ; Test a Bit ROM:0000A038 beq.s loc_A044 ; Branch if Equal ROM:0000A03A subq.w #1,d0 ; Subtract Quick ROM:0000A03C bpl.s loc_A054 ; Branch if Plus ROM:0000A03E move.w #$1B,d0 ; Move Data from Source to Destination ROM:0000A042 bra.s loc_A054 ; Branch Always ROM:0000A044 ; --------------------------------------------------------------------------- ROM:0000A044 ROM:0000A044 loc_A044: ; CODE XREF: GM_SoundTestLoop+42j ROM:0000A044 btst #4,d5 ; Test a Bit ROM:0000A048 beq.s loc_A054 ; Branch if Equal ROM:0000A04A addq.w #1,d0 ; Add Quick ROM:0000A04C cmpi.w #$1B,d0 ; Compare Immediate ROM:0000A050 ble.s loc_A054 ; Branch if Less or Equal ROM:0000A052 moveq #0,d0 ; Move Quick ROM:0000A054 ROM:0000A054 loc_A054: ; CODE XREF: GM_SoundTestLoop+46j ROM:0000A054 ; GM_SoundTestLoop+4Cj ... ROM:0000A054 move.w d0,(RAM_CurrentStageID).w ; Move Data from Source to Destination ROM:0000A058 lea (vdp_data_port).l,a2 ; Load Effective Address ROM:0000A05E move.l #$4B0C0003,(vdp_control_port).l ; Move Data from Source to Destination ROM:0000A068 mulu.w #3,d0 ; Unsigned Multiply ROM:0000A06C lea Array_StageSelectValues,a1 ; Load Effective Address ROM:0000A070 adda.w d0,a1 ; Add Address ROM:0000A072 moveq #0,d1 ; Move Quick ROM:0000A074 move.b (a1)+,d1 ; Move Data from Source to Destination ROM:0000A076 move.w d1,(a2) ; Move Data from Source to Destination ROM:0000A078 move.w #$3A,(a2) ; ':' ; Move Data from Source to Destination ROM:0000A07C move.b (a1)+,d1 ; Move Data from Source to Destination ROM:0000A07E move.w d1,(a2) ; Move Data from Source to Destination ROM:0000A080 move.w #$3A,(a2) ; ':' ; Move Data from Source to Destination ROM:0000A084 move.b (a1)+,d1 ; Move Data from Source to Destination ROM:0000A086 move.w d1,(a2) ; Move Data from Source to Destination ROM:0000A088 rts ; Return from Subroutine ROM:0000A08A ; --------------------------------------------------------------------------- The only thing preventing this code from running is a single ret before the first line. NOP it out and the code runs fine: You can access it yourself with the following Game Genie codes: Game Genie codes: RGST-A6XN (UE) RGTA-A6VL (J) The "No Clip" cheat wasn't so lucky. Traditionally, the code was always rumored to work when the game is paused. So I found the subroutine for pausing the game, and noticed a bunch of NOPs where calls for button checks and such would probably be: Code (ASM): ROM:00009808 ; =============== S U B R O U T I N E ======================================= ROM:00009808 ROM:00009808 ROM:00009808 PauseGame: ; CODE XREF: GM_StageLoop+34p ROM:00009808 move.w #$100,(z80_bus_request).l ; Move Data from Source to Destination ROM:00009810 nop ; No Operation ROM:00009812 nop ; No Operation ROM:00009814 nop ; No Operation ROM:00009816 nop ; No Operation ROM:00009818 tst.b (RAM_EnablePauseFlag).w ; 1 = true, 0 = false ROM:0000981C bne.s loc_9834 ; Branch if Not Equal ROM:0000981E move.b #$80,(byte_A01C12).l ; Move Data from Source to Destination ROM:00009826 nop ; No Operation ROM:00009828 nop ; No Operation ROM:0000982A move.b #0,(byte_A01C13).l ; Move Data from Source to Destination ROM:00009832 bra.s end ; Branch Always ROM:00009834 ; --------------------------------------------------------------------------- ROM:00009834 ROM:00009834 loc_9834: ; CODE XREF: PauseGame+14j ROM:00009834 move.b #$C1,(byte_A01C0A).l ; Move Data from Source to Destination ROM:0000983C nop ; No Operation ROM:0000983E nop ; No Operation ROM:00009840 move.b #1,(byte_A01C13).l ; Move Data from Source to Destination ROM:00009848 ROM:00009848 end: ; CODE XREF: PauseGame+2Aj ROM:00009848 move.w #0,(z80_bus_request).l ; Move Data from Source to Destination ROM:00009850 rts ; Return from Subroutine ROM:00009850 ; End of function PauseGame ROM:00009850 I looked everywhere for code that might enable No Clip but I haven't found anything yet. I would suspect it would be common with the player code, but I can't seem to find any unused branches or sections of code that do anything close to what the mode is supposed to do. I'll have to keep searching for it. 3.) Objects This game keeps the main subroutine code for each object (including the player) in a huge table of pointers. The main subroutine, depending on what the object is, will first load the address of a "move" table filled with offsets to functions for certain object actions and then jump to it depending on the object's current condition in game. If it's an enemy, it'll include an additional branch that will check if the enemy has been hit by Mickey's butt, a projectile, or by a rainbow gem. There are some pointers that are never touched which seems to hint at unused objects. Here are a list of pointers for the objects that seem to be unused (excluding duplicates and null'd subroutines); I haven't bothered to load all of them yet, but I found some odd ones. The last two objects in this list are kinda interesting: The object itself can't be destroyed, has no collision, and does literally nothing. The second unused object in the list is a 1:1 copy of the first object. The object uses the first few tiles from VRAM to build the object (which in a stage the tiles are always the same because the tiles being used are always loaded in the same place). 4.) Other odds and ends Some other neat things I've noticed while digging through this game. I'll arrange it in a small sublist to make it kinda easier to read: Much like how Labyrinth Zone in Sonic 1 was originally meant to be the second Zone but was changed because it was deemed a bit too difficult for a second stage, Castle of Illusion had a similar dilemma. The second substage in the Forest level (the one with the big rolling Apple) was originally supposed to be the third substage. The original second substage was actually supposed to be what is now the forth substage (the one with the ghosts). The decision to swap the stages is made evident in the level order in the level select, pointers for the stage in various tables, and even the first few seconds of the song of the stage (boost the tempo of the beginning of the song and you'll notice it's actually the normal Forest theme but with different sounding instruments). This was probably changed due to the platform difficulty presented. I'd imagine it was probably too difficult to balance Mickey's butt stomps on ghosts without having played a traditional platforming challenge that can be found in the third substage first. Speaking of stages, there were originally supposed to be three tea cup stages for the Library stage but got dropped down to two. I can't seem to find data for that missing stage, but in the level select, the level actually points to 4-1-t1. What's odd, however, is that upon completing the tea cup stage - you get sent back to the Library in mid air a little after where the second tea cup warp is supposed to be. The unused exit can be found in the stage select under 4-1-4. Here's a silly oversight that I saw while disassembling the game. Some backstory first - the game features a 100% z80 sound driver. The game passes off the sound id of the music/sfx it wants to play to $F40E and calls a 68k function to play the sound (79F86). The code itself works as intended, but there's a small catch. Music usually takes precedent over sound effects in game, so sound effects will really only play all the way out unless you don't change the music right away. This becomes a problem in one instance in the game where one sound goes completely unheard even though it's used. When you collect the key in the first substage in the Toyland world (that changes all the platforms to slopes), there's actually supposed to be a sound that plays. They have the code to play the sound, and it get's executed as it should. But after returning from the function that initiates the playback for the sound, the game will pass and call ANOTHER instance for playback for the song that plays when Mickey runs down the slope. Because music takes precedence over sound effects, this accidentally cancels out the sound that's supposed to play. Here's the code that does it: Code (ASM): ROM:0000083E move.b #$C3,(RAM_CurrentSoundID).w ; play "key got" sfx ROM:00000844 jsr PlaySound ; Jump to Subroutine ROM:0000084A move.b #$93,(RAM_CurrentSoundID).w ; play "mickey runs down slope" music ROM:00000850 jsr PlaySound ; Jump to Subroutine At first maybe switching the ID's around would fix the problem, but you can't play both at the same time like this. The second call to PlaySound has to occur later somehow for the sound to play all the way out. It looks like the developers had a major issue with the ROM size restrictions for this game. Besides the fact that this game has a lot of compressed data, it also has a lot of the programming for certain game modes/screens toward the end of the rom. It seems that they had planned ahead to dedicate certain ROM regions for code and art (with liberal use of padding data), but when they had to add screens that were obviously programmed late, like the game over/ending screens, they probably couldn't fit what they wanted in the area of the rom they had already dedicated for code. From the looks of things, they used whatever free space they had in that artificial code segment they made and made certain "game mode" subroutines in their game mode/screen table dedicated to simply jumping to the actual function code that starts at the end of the rom. To illustrate my point, look at the game mode table here and notice how many of them are _j, or "jumping" subroutines: Code (ASM): ROM:000003D8 GM_Array: dc.w GM_Init ; 00 ROM:000003DA dc.w GM_SegaLoop_j ; 02 ROM:000003DC dc.w GM_OpeningInit ; 04 ROM:000003DE dc.w GM_OpeningLoop ; 06 ROM:000003E0 dc.w GM_InitSoundTest ; 08 ROM:000003E2 dc.w GM_SoundTestLoop ; 0A ROM:000003E4 dc.w GM_StageInit ; 0C ROM:000003E6 dc.w GM_StageLoop ; 0E ROM:000003E8 dc.w GM_StageInverter ; 10 ROM:000003EA dc.w GM_TitleLoop ; 12 ROM:000003EC dc.w GM_EndingInit ; 14 ROM:000003EE dc.w GM_Ending ; 16 ROM:000003F0 dc.w GM_GameOverInit_j ; 18 ROM:000003F2 dc.w GM_GameOverLoop_j ; 1A ROM:000003F4 dc.w GM_CopyrightInit_j ; 1C ROM:000003F6 dc.w GM_CopyrightLoop_j ; 1E ROM:000003F8 dc.w GM_InitCastleLoop_j ; 20 ROM:000003FA dc.w GM_CastleLoop_j ; 22 ROM:000003FC dc.w GM_StageClearInit_j ; 24 ROM:000003FE dc.w GM_StageClearLoop_j ; 26 ROM:00000400 dc.w GM_OutsideCastle ; 28 ROM:00000402 dc.w sub_A286 ; 2A ROM:00000404 dc.w GM_CastleEscapeInit ; 2C ROM:00000406 dc.w GM_CastleEscapeLoop ; 2E 5.) Some RAM locations: Just a few locations I found, not nearly all of them though... 6.) Disassembly I started to label a disassembly of the game which you can download here. It's no where near complete, but I got a lot of the data down at least. It's the first one I made that's this involved, so excuse the bad mistakes I made. You can open the Ida Pro database in 6.1 or later.
A very intersting read. I like that there are games other than Sonic that are getting looked at. And finding these secrets like the "Key SFX" but we never got to hear it, and the unused objects are curious to me. It HAS to be there somewhere. It could all be well that they may have removed the "noclip" code, but chances are, they would've removed the code in the "pause_game" routine, rather than replacing them with nops. I have a feeling when they were in their final testing area, they replaced those "braches to subroutines" with nops (the urge to test with noclip has gone), so that if they suddenly spot something wrong at the last minute, they could quickly replace them nops with the "bsr XXXXX" and noclip their game. In other words, if they really have removed the noclip code, they surely would've have removed them branches rather than replace them with nops. OR, those nops have replaced something else entirely different, and we're/you're just assuming that's where the noclip branches are. Oh, and your title, it's not crap! :v:
No surprises perhaps but "Mickey Mouse" is likely the former title for the game - Land of Illusion on the Master System was known as "Mickey Mouse 2" for most of its development, and I seem to recall reading something similar going on for Castle of Illusion. I'll keep an eye out for this.
A couple more things I found/curious about. I went through the unused objects I listed and I could only get 3 of them to do anything noticeable. $6E74 slowly turns the palette for some objects on the first plane completely black, creating a silhouette effect. Another unused subroutine (which I've forgotten the address of) does something similar, but affects more objects on the screen. When I was documenting the Nemesis art, I noticed the table used by most of the game has these entries in every odd number'd element that appear to be unused: Code (ASM): ROM:0000AA00 NemesisArtArray:dc.l $42000000 ; DATA XREF: LoadNemArt+10o ROM:0000AA00 ; ROM:0000A97Co ... ROM:0000AA00 ; Predicted ROM:0000AA04 dc.l Nem_OpeningText ; Predicted ROM:0000AA08 dc.l $60000000 ; (Predicted offset) ROM:0000AA0C dc.l Nem_Forest1FG ROM:0000AA10 dc.l $77000000 ; (Predicted offset) ROM:0000AA14 dc.l Nem_Forest1BG ROM:0000AA18 dc.l $60000000 ; (Predicted offset) ROM:0000AA1C dc.l Nem_ToyLand2_3FG ROM:0000AA20 dc.l $41A00001 ; (Predicted offset) ROM:0000AA24 dc.l Nem_ToyLand2_3BG Does anyone know what these could be? I noticed some enemies have unused moves in their table that I may/may not have overlooked. I recall a while a go that the bird enemy in the game (used in the forest) has an action that makes it flap in place until you walk over/under it, where it'll fly in your direction. I'll have to identify more object routines before I mess around with the action tables in each one, but there might be some good stuff there. Finally, you know that cool effect in the third substage of the second stage (Toyland) that flips the entire stage upside down when you collect the power up? The main subroutine (GM_StageInverter) for the effect is very special, and is considered it's own separate game mode. The cool thing about this function is that it can be loaded (before the next frame of course) and work on almost any stage in the game with varying degrees of success. To try it for yourself, at any point in the game just change the value at F300 to 0010. It's definitely better suited for levels where the camera doesn't move up or down with Mickey like the stage it's normally used in. It'd be interesting to see something similar in Sonic hacks...
Those all appear to be VDP commands to write to VRAM at various addresses: $0200, $2000, $3700, $2000, $41A0. It makes sense for them to go together with the art pointers in ROM so that the art loading function only needs an index to know what art to load from ROM and where to put it in VRAM, like Sonic games' PLC lists, but more efficient as it doesn't have to manually convert the VRAM offset to a VDP command.
I found some unused uncompressed sprite data for Mickey at 1FE1F to 208DE in the Japanese ROM. I'm no good at assembling tiles though, can anyone take a crack at it? It uses Mickey's palette from the opening cutscene, so it might've been used for something to that affect. 1E35F to 1E3DE seems to contain another unused sprite for Mickey too. 29774 to 298F8 might be an unused Enigma archive. I never figured out what the game seems to store in Enigma archives... 4BC5D to 4BD3C seems to be something, no idea what it is. Doesn't look like graphic data... I also kinda sorta figured out the function of one unused object in the game. This one is a little bizarre... The unused object at 7188 in the rom scrolls layer b down (usually the bg) in the vdp every $80 frames for FFFF frames. I have no idea what the heck it could've been used for since the timer is coded to run for a long time and doesn't seem to do anything else.
I was thinking the same but it affects the background layer rather than the foreground, so I'd assume if you were doing credits the graphics would sit in the top layer in the VDP. The speed of the scroll is also very slow and lasts a long time, so I'm not sure. Of course, this could've been all adjusted if the code was used, but I think that because it's an object it could've been used for something else. EDIT: Oh yeah, there's one more piece of unused code that's a bit weird that I found that's part of Mickey's object but is part of the main object loop for the character (I.e not in a jump table): Code (ASM): ROM:0000B674 ; =============== S U B R O U T I N E ======================================= ROM:0000B674 ROM:0000B674 ; Has a strange effect on Mickey. ROM:0000B674 ; If $F452 is true, it will shoot Mickey to the very top of the stage and have him fall down. ROM:0000B674 ; It's impossible for this function to occur normally, since Mickey could either fall to his death if he drops down a bottomless pit, ROM:0000B674 ; or he would simply hit his head on a ceiling. This is probably a remnant of a condition for the player if No Clip mode is used and the ROM:0000B674 ; player is accidentally placed outside the stage from the bottom. ROM:0000B674 ROM:0000B674 Chk_PlayerOutOfBounds: ; CODE XREF: Obj_Player+40p ROM:0000B674 move.b (byte_FFFFF452).w,d0 ; Move Data from Source to Destination ROM:0000B678 beq.s _end ; Branch if Equal ROM:0000B67A cmpi.b #$2B,3(a0) ; '+' ; Predicted (Code-scan) ROM:0000B680 beq.s _end ; Predicted (Code-scan) ROM:0000B682 clr.l $1C(a0) ; Predicted (Code-scan) ROM:0000B686 clr.l $18(a0) ; Predicted (Code-scan) ROM:0000B68A move.b #$2B,3(a0) ; '+' ; Predicted (Code-scan) ROM:0000B690 clr.w $22(a0) ; Predicted (Code-scan) ROM:0000B694 move.b #$81,$26(a0) ; Predicted (Code-scan) ROM:0000B69A move.b #1,(RAM_InvincibilityFlag).w ; Predicted (Code-scan) ROM:0000B6A0 ROM:0000B6A0 _end: ; CODE XREF: Chk_PlayerOutOfBounds+4j ROM:0000B6A0 ; Chk_PlayerOutOfBounds+Cj ROM:0000B6A0 rts ; Return from Subroutine ROM:0000B6A0 ; End of function Chk_PlayerOutOfBounds I'm going to better label the object pretty soon, but basically this code clears the X/Y coordinates of Mickey's object and I believe inits the object with a certain action (that is used). The value at FFFFF452 is used in a few more places but nothing ever sets this to a value where the routine can carry out the whole way through, so most of this code goes unused. When I did my disassembly a while a go, I thought that this code might act of kind of like a way to catch the player if they go out of bounds (like in a wall or outside the stage). The reason is that the few bottomless pits there are in this game, the game has a special routine for having Mickey fall. But when there's no instance for the object to call the falling routine this is probably called instead to allow the player to move back to the top of the level if they fall out of the level's bounds. The only reason I figured this was because if you set the byte at FFFFF452, Mickey will shoot all the way up to the top of the screen and (if there's a ceiling) get stuck and hit his head endlessly. If there's no ceiling, I believe he just falls back down. It even makes him invincible for a brief period. But there's a bit more to this code that deal with the player object that I'll have to look at. Very strange. Not no-clip though, but it might be related to it (since it'd be the only way in the game to fall outside the stage's bounds that I can think of).
I tried my hand at it before getting frustrated that pieces weren't lining up. Didn't save a pic since it looked very incomplete, but it was clearly spelling out MICKEY and something trailing after it. Also figured that both the green-ish and blue-ish sections combine, which was what was making it so difficult to match things.
I managed to assemble an incomplete "MICKEY MOUSE" logo with all those tiles before the program I was using crashed (so no pic either, sorry). There seemed to be a lot of missing graphics, but I guess that the mappings reused some of them in different places. EDIT: Man, whoever was in charge of those graphics made some insanely clever tile recycling! This is the logo without repeating any tiles, as posted by rabidabid over the Cutting Room Floor forums: And here's what it looks like after I copied and pasted tiles from surprisingly different places: ...And I still can't find the last two tiles, as you can see. >=( EDIT 2: Finished! Holy shit, I can't believe the last two missing tiles were the same ones next to them, only mirrored! The slightly ambiguous curve in the "U" should have clued me in. Some possibly relevant info about this logo: It's just one tile less wide than the "Castle of Illusion" one used in the final, which works to its advantage as it can be centered perfectly on the Mega Drive's display (having three empty tiles to each side). Interestingly, the lettering here is based on the classic color cartoon title cards instead of the official modern logo: Official logo: Logo seen in-game in Castle of Illusion and also in the non-Japanese covers of World of Illusion, Land of Illusion and Legend of Illusion, which mixes features from both: Which, by the way, also shares similarities with the logo in Mickey Mousecapade, Mickey's Dangerous Chase and Mickey Mania (and I'm guessing any merchandise that said anything other than just "Mickey Mouse"), so those may have been made with a special font supplied by Disney:
Quick bump, I forgot to mention something before. There is one noticable difference besides just the language between the Japanese and the American releases. The only layout change between the two versions is that in the Japanese version, the first platform that you need to jump on to advance after you encounter the first tea cup in the fourth stage was extended a bit to make it easier to jump on. I'll take a picture of this later, but it's a very minor change that would've gone unnoticed unless you did a byte compare of the nemesis archive for the stage tile layout.
