Talk:AAAHH!!! Real Monsters (Genesis)

Secret Screen
Use Action Replay code to warp directly to the dump bonus level after the Sega logo.

Most of the details are on the main page. Here's the rest:

button press values 10 = B 20 = C 40 = A

The two compares that check if BBBA BAAC was entered while the game was paused:

02:4B7A 0C B9  CMPI.L  #$10101040,($FFFFE86A) 02:4B84 66 0C  BNE     #$0C [02:4B92] 02:4B86 0C B9  CMPI.L  #$10404020,($FFFFE86E) 02:4B90 67 30  BEQ     #$30 [02:4BC2]

The game simply refuses to branch to (enable secret screen)

Why?


 * It seems $FFFFE86A and $FFFFE86E are both in WRAM of the 68k, though it seems all offsets are usually given in 6 figures only, not 8. Are you sure your effective address (and addressing mode) is correct when you decompiled that bit of code? If it is and this accesses WRAM, you have to make sure whatever is writing cached button presses to that area is actually actively doing so. Another thing that leads me to believe this is wrong is the fact that both CMPI.L's seem to access the same address (offset by 0xB9 to the ea), yet they are offset by the program counter change in your snippet, which seems odd.
 * It seems quite unbelievable that a game would cache 6 to 8 button presses in WRAM, anyway, don't you think?. Now I know nothing about the 68k and Genesis in general, but usually you would program button combos as a tight loop (spin lock) and then advance once a single button is pressed in the correct sequence, else start over. So I guess this means you have to recheck the addressing mode you dumped this or if you cannot do that, emulate it and set a breakpoint there so you know what addressing mode is used and what is actually referenced by those compares. --Tauwasser 20:41, 17 May 2011 (EDT)
 * EDIT: It seems I was mistaken to assume that 8bit opcodes were used. Basically, it should read (0C B9) (40 10 10 10) (6A E8) (FF FF) in your ROM, so that's (opcode) (operand) (first extension word) (second extension word). So it pretty much seems to be the case that you should make sure some other code is actually caching button presses (if that's what they are) to those WRAM areas. --Tauwasser 21:20, 17 May 2011 (EDT)

The 68000 has a 24-bit address bus, so the upper byte of addresses are ignored. Furthermore, the 68000 can sign-extend memory addresses stored in instructions. Any memory address > $FF8000 can be automatically sign extended to read $FFFFxxxx, saving space and time =P Not sure why they didn't do that here... Also 68000 is big endian, not little endian. - Andlabs 21:29, 17 May 2011 (EDT)
 * Ah, gotcha! I just read a quick summary of memory map and opcodes. Anyway, reading from FFE86A and FFE86E combined with the info from the current wiki page suggests that the button combo is correct and has to be the very last thing entered (or else some other buttons would shift everything forward). Is the pause menu the only menu that actually writes to that RAM range? --Tauwasser 22:59, 17 May 2011 (EDT)
 * Yes. The button check routine is simliar to the one for Monsters Options, which caches all 32 button presses (RAM range )  That code works fine, but for some reason the  compare for this code always fails.  --JLukas 23:21, 17 May 2011 (EDT)

CMPI.L test
As a test, adding Action Replay codes causes the opcode to read the button presses from itself: 02:4B86 0C B9  CMPI.L  #$10404020,($024B88) Pause the game, enter BBBA xxxx (xxxx= any combo of A B or C, this is required to shift BBBA into FFE86A), unpause and collect all gold skulls in 4 bounces. It works and goes to the secret screen. It will recognize 10404020, but not from RAM. Addressing issue? One guess would be that a CMP.L to FFE86E would only fetch the first 16 bits correctly, then read the next 16 bits from FFE860 instead of FFE870. But if that was the case, the Monsters Options wouldn't work either, as it also reads FFE86E (and FFE85E, too.) Hmmm --00:32, 18 May 2011 (EDT)
 * What is the RAM value at that moment after hitting the last button? What happens if you use a patch code to force the value into that RAM spot? Crossing the 16-byte boundary should work fine... - Andlabs 02:01, 27 May 2011 (EDT)
 * Regen's RAM viewer reports the correct 10404020. If it is a bank boundary problem, 20202040 and 40404020 (crosses boundaries in the other code) work, but not 10404020. --JLukas 02:30, 27 May 2011 (EDT)