Castle of Illusion (J) crap

Discussion in 'Technical Discussion' started by evilhamwizard, Nov 2, 2015.

  1. evilhamwizard


    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):
    1. ROM:0000A02C GM_SoundTest_StageSelect:               ; Unused! Seems to be loaded within the sound test?
    2. ROM:0000A02C                 move.b  (RAM_CurrentPressedButton+1).w,d5
    3. ROM:0000A030                 move.w  (RAM_CurrentStageID).w,d0 ; Move Data from Source to Destination
    4. ROM:0000A034                 btst    #6,d5           ; Test a Bit
    5. ROM:0000A038                 beq.s   loc_A044        ; Branch if Equal
    6. ROM:0000A03A                 subq.w  #1,d0           ; Subtract Quick
    7. ROM:0000A03C                 bpl.s   loc_A054        ; Branch if Plus
    8. ROM:0000A03E                 move.w  #$1B,d0         ; Move Data from Source to Destination
    9. ROM:0000A042                 bra.s   loc_A054        ; Branch Always
    10. ROM:0000A044 ; ---------------------------------------------------------------------------
    11. ROM:0000A044
    12. ROM:0000A044 loc_A044:                               ; CODE XREF: GM_SoundTestLoop+42j
    13. ROM:0000A044                 btst    #4,d5           ; Test a Bit
    14. ROM:0000A048                 beq.s   loc_A054        ; Branch if Equal
    15. ROM:0000A04A                 addq.w  #1,d0           ; Add Quick
    16. ROM:0000A04C                 cmpi.w  #$1B,d0         ; Compare Immediate
    17. ROM:0000A050                 ble.s   loc_A054        ; Branch if Less or Equal
    18. ROM:0000A052                 moveq   #0,d0           ; Move Quick
    19. ROM:0000A054
    20. ROM:0000A054 loc_A054:                               ; CODE XREF: GM_SoundTestLoop+46j
    21. ROM:0000A054                                         ; GM_SoundTestLoop+4Cj ...
    22. ROM:0000A054                 move.w  d0,(RAM_CurrentStageID).w ; Move Data from Source to Destination
    23. ROM:0000A058                 lea     (vdp_data_port).l,a2 ; Load Effective Address
    24. ROM:0000A05E                 move.l  #$4B0C0003,(vdp_control_port).l ; Move Data from Source to Destination
    25. ROM:0000A068                 mulu.w  #3,d0           ; Unsigned Multiply
    26. ROM:0000A06C                 lea     Array_StageSelectValues,a1 ; Load Effective Address
    27. ROM:0000A070                 adda.w  d0,a1           ; Add Address
    28. ROM:0000A072                 moveq   #0,d1           ; Move Quick
    29. ROM:0000A074                 move.b  (a1)+,d1        ; Move Data from Source to Destination
    30. ROM:0000A076                 move.w  d1,(a2)         ; Move Data from Source to Destination
    31. ROM:0000A078                 move.w  #$3A,(a2) ; ':' ; Move Data from Source to Destination
    32. ROM:0000A07C                 move.b  (a1)+,d1        ; Move Data from Source to Destination
    33. ROM:0000A07E                 move.w  d1,(a2)         ; Move Data from Source to Destination
    34. ROM:0000A080                 move.w  #$3A,(a2) ; ':' ; Move Data from Source to Destination
    35. ROM:0000A084                 move.b  (a1)+,d1        ; Move Data from Source to Destination
    36. ROM:0000A086                 move.w  d1,(a2)         ; Move Data from Source to Destination
    37. ROM:0000A088                 rts                     ; Return from Subroutine
    38. 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):
    1. ROM:00009808 ; =============== S U B R O U T I N E =======================================
    2. ROM:00009808
    3. ROM:00009808
    4. ROM:00009808 PauseGame:                              ; CODE XREF: GM_StageLoop+34p
    5. ROM:00009808                 move.w  #$100,(z80_bus_request).l ; Move Data from Source to Destination
    6. ROM:00009810                 nop                     ; No Operation
    7. ROM:00009812                 nop                     ; No Operation
    8. ROM:00009814                 nop                     ; No Operation
    9. ROM:00009816                 nop                     ; No Operation
    10. ROM:00009818                 tst.b   (RAM_EnablePauseFlag).w ; 1 = true, 0 = false
    11. ROM:0000981C                 bne.s   loc_9834        ; Branch if Not Equal
    12. ROM:0000981E                 move.b  #$80,(byte_A01C12).l ; Move Data from Source to Destination
    13. ROM:00009826                 nop                     ; No Operation
    14. ROM:00009828                 nop                     ; No Operation
    15. ROM:0000982A                 move.b  #0,(byte_A01C13).l ; Move Data from Source to Destination
    16. ROM:00009832                 bra.s   end             ; Branch Always
    17. ROM:00009834 ; ---------------------------------------------------------------------------
    18. ROM:00009834
    19. ROM:00009834 loc_9834:                               ; CODE XREF: PauseGame+14j
    20. ROM:00009834                 move.b  #$C1,(byte_A01C0A).l ; Move Data from Source to Destination
    21. ROM:0000983C                 nop                     ; No Operation
    22. ROM:0000983E                 nop                     ; No Operation
    23. ROM:00009840                 move.b  #1,(byte_A01C13).l ; Move Data from Source to Destination
    24. ROM:00009848
    25. ROM:00009848 end:                                    ; CODE XREF: PauseGame+2Aj
    26. ROM:00009848                 move.w  #0,(z80_bus_request).l ; Move Data from Source to Destination
    27. ROM:00009850                 rts                     ; Return from Subroutine
    28. ROM:00009850 ; End of function PauseGame
    29. 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:
    1. 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.
    2. 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.
    3. 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):
      1. ROM:0000083E                 move.b  #$C3,(RAM_CurrentSoundID).w ; play "key got" sfx
      2. ROM:00000844                 jsr     PlaySound       ; Jump to Subroutine
      3. ROM:0000084A                 move.b  #$93,(RAM_CurrentSoundID).w ; play "mickey runs down slope" music
      4. 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.
    4. 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):
      1. ROM:000003D8 GM_Array:       dc.w GM_Init            ; 00
      2. ROM:000003DA                 dc.w GM_SegaLoop_j      ; 02
      3. ROM:000003DC                 dc.w GM_OpeningInit     ; 04
      4. ROM:000003DE                 dc.w GM_OpeningLoop     ; 06
      5. ROM:000003E0                 dc.w GM_InitSoundTest   ; 08
      6. ROM:000003E2                 dc.w GM_SoundTestLoop   ; 0A
      7. ROM:000003E4                 dc.w GM_StageInit       ; 0C
      8. ROM:000003E6                 dc.w GM_StageLoop       ; 0E
      9. ROM:000003E8                 dc.w GM_StageInverter   ; 10
      10. ROM:000003EA                 dc.w GM_TitleLoop       ; 12
      11. ROM:000003EC                 dc.w GM_EndingInit      ; 14
      12. ROM:000003EE                 dc.w GM_Ending          ; 16
      13. ROM:000003F0                 dc.w GM_GameOverInit_j  ; 18
      14. ROM:000003F2                 dc.w GM_GameOverLoop_j  ; 1A
      15. ROM:000003F4                 dc.w GM_CopyrightInit_j ; 1C
      16. ROM:000003F6                 dc.w GM_CopyrightLoop_j ; 1E
      17. ROM:000003F8                 dc.w GM_InitCastleLoop_j ; 20
      18. ROM:000003FA                 dc.w GM_CastleLoop_j    ; 22
      19. ROM:000003FC                 dc.w GM_StageClearInit_j ; 24
      20. ROM:000003FE                 dc.w GM_StageClearLoop_j ; 26
      21. ROM:00000400                 dc.w GM_OutsideCastle   ; 28
      22. ROM:00000402                 dc.w sub_A286           ; 2A
      23. ROM:00000404                 dc.w GM_CastleEscapeInit ; 2C
      24. 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.
  2. redhotsonic


    Also known as RHS Tech Member
    United Kingdom
    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:
  3. Jayextee


    Comic Mischief Member
    Kathmandu, Nepal
    Oh man, how long until a decent layout (and art? One can dream) hack for this game? <3
  4. Black Squirrel

    Black Squirrel

    waiting for you on the beach Wiki Sysop
    Northumberland, England
    it's a quipu
    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.
  5. evilhamwizard


    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):
    1. ROM:0000AA00 NemesisArtArray:dc.l $42000000          ; DATA XREF: LoadNemArt+10o
    2. ROM:0000AA00                                         ; ROM:0000A97Co ...
    3. ROM:0000AA00                                         ; Predicted
    4. ROM:0000AA04                 dc.l Nem_OpeningText    ; Predicted
    5. ROM:0000AA08                 dc.l $60000000          ;  (Predicted offset)
    6. ROM:0000AA0C                 dc.l Nem_Forest1FG
    7. ROM:0000AA10                 dc.l $77000000          ;  (Predicted offset)
    8. ROM:0000AA14                 dc.l Nem_Forest1BG
    9. ROM:0000AA18                 dc.l $60000000          ;  (Predicted offset)
    10. ROM:0000AA1C                 dc.l Nem_ToyLand2_3FG
    11. ROM:0000AA20                 dc.l $41A00001          ;  (Predicted offset)
    12. 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...
  6. MainMemory


    Have no fear...Amy Rose is here! Tech Member
    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.
  7. ICEknight


    Researcher Researcher
    That looks like it may have been used when entering some dark doors... that do not exist anymore.
  8. evilhamwizard


    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.
  9. ICEknight


    Researcher Researcher
    Credits scroll?
  10. evilhamwizard


    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):
    1. ROM:0000B674 ; =============== S U B R O U T I N E =======================================
    2. ROM:0000B674
    3. ROM:0000B674 ; Has a strange effect on Mickey.
    4. ROM:0000B674 ; If $F452 is true, it will shoot Mickey to the very top of the stage and have him fall down.
    5. 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,
    6. 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
    7. ROM:0000B674 ; player is accidentally placed outside the stage from the bottom.
    8. ROM:0000B674
    9. ROM:0000B674 Chk_PlayerOutOfBounds:                  ; CODE XREF: Obj_Player+40p
    10. ROM:0000B674                 move.b  (byte_FFFFF452).w,d0 ; Move Data from Source to Destination
    11. ROM:0000B678                 beq.s   _end            ; Branch if Equal
    12. ROM:0000B67A                 cmpi.b  #$2B,3(a0) ; '+' ; Predicted (Code-scan)
    13. ROM:0000B680                 beq.s   _end            ; Predicted (Code-scan)
    14. ROM:0000B682                 clr.l   $1C(a0)         ; Predicted (Code-scan)
    15. ROM:0000B686                 clr.l   $18(a0)         ; Predicted (Code-scan)
    16. ROM:0000B68A                 move.b  #$2B,3(a0) ; '+' ; Predicted (Code-scan)
    17. ROM:0000B690                 clr.w   $22(a0)         ; Predicted (Code-scan)
    18. ROM:0000B694                 move.b  #$81,$26(a0)    ; Predicted (Code-scan)
    19. ROM:0000B69A                 move.b  #1,(RAM_InvincibilityFlag).w ; Predicted (Code-scan)
    20. ROM:0000B6A0
    21. ROM:0000B6A0 _end:                                   ; CODE XREF: Chk_PlayerOutOfBounds+4j
    22. ROM:0000B6A0                                         ; Chk_PlayerOutOfBounds+Cj
    23. ROM:0000B6A0                 rts                     ; Return from Subroutine
    24. 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).
  11. Shoemanbundy


    Chicago, Illinois
    selling shoes
    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.
  12. ICEknight


    Researcher Researcher
    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:
  13. evilhamwizard


    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.