Posts for ScottySR

ScottySR
He/Him
Joined: 1/24/2019
Posts: 2
Location: Finland
Okay, so it seems that the red orb glitch is caused by the classic "forgot to change stuff after copy-paste". If you compare the blue orb's code with the red orb's, they are very similar. They did change most stuff right for the red orb, but one branch address. If there is no enemy present, the red orb's code will branch to the blue orb's code which starts to clear wrong areas of ram in the maze areas. Added variable names and branch/jump labels for easier reading: https://pastebin.com/raw/908iaPMp
ScottySR
He/Him
Joined: 1/24/2019
Posts: 2
Location: Finland
Taking a closer look at the red orb glitch: Using the red orb in a maze outside a fight runs the following subroutine:
--- $FCB3 ---

LDA #$00
STA $0310,X
STA $0330,X
STA $0350,X
STA $0370,X
STA $0390,X
STA $03B0,X
STA $03D0,X
STA $01A0,X
STA $04C8,X
STA $04D0,X
STA $0128,X
STA $0130,X
STA $0138,X

JSR $FCE8

LDA #$00
STA $04B8,X
STA $04C0,X
RTS

--- $FCE8 ---

LDA #$00
STA $04A8,X
STA $04B0,X
RTS
This particular subroutine is run whenever a projectile is despawned. The addresses above are pointing to projectile memory. This code also runs 8 times in a X incrementing loop when you use a blue orb in a side scrolling stage to despawn all projectiles. As it was mentioned above, the region $0400 - $058F is used to store the maze layout in the mazes, which is partially within the projectile memory used in side scrolling stages, and for this reason messes up the maze when it runs. The exact reason why this code runs with the red orb is still unknown though, but I'm trying to figure that out and see if this can be exploited elsewhere in some other way.