Pokes for fixing the corruption of Cavern 7 ('Miner Willy meets the Kong Beast') when Willy passes through the top/bottom of a cavern in Manic Miner

[IRF]

This should be useful for anyone designing games based on the Manic Miner game engine, who wish to have the option of Willy jumping up beyond the top of caverns (appearing at the bottom), or falling off the bottom of caverns (appearing at the top) - without fear of causing corruption of the game code.

(In the original Bug Byte MM release, this bug affects the layout data of Cavern 07).

Fixing the bug can be achieved using five POKES.  Three contiguous spare bytes at #841C-1E are used for this.  (Note that the other spare byte at #841B should retain its original value of #30, or else be NOPped out.)

In hexadecimal:

POKE #8405, #1C
POKE #8406 #84
POKE #841C, #C3
POKE #841D, #CC
POKE #841E, #85

In decimal:

POKE 33797, 28
POKE 33798, 132
POKE 33820, 195
POKE 33821, 204
POKE 33822, 133

I've tested these out and they do the job. See the attached files - one is original Manic Miner (Bug Byte version), with a hole created in the floor of the Central Cavern. Drop Willy through the hole [he dies], then teleport him to 'Miner Willy Meets the Kong Beast' [type 6031769, then press 1+2+3+6 simultaneously] to see the corruption in action.

 

EDIT: You can also see what happens when Willy jumps up off the top of the screen, thanks to an additional platform placed four cell-rows below the top of the Central Cavern.  I've also changed the Air INK in Central Cavern to Yellow - note the brief, temporary & harmless graphical glitch below Willy (in pixel-row 1 of cell-row 10), just as he passes the top of the screen.  (N.B. This only occurs when Willy jumps up from the new platform located four rows below the top, not from the platform located three rows below the top - I only added the latter platform in order to break Willy's fall, so that the top-left of the cavern can be accessed quickly and safely by dropping down from the start position at the bottom-left.)

 

Then the second file is the same as the first, but with the above POKES applied. Repeat the exercise (fall through the hole, then make your way to Kong Beast), and Hey Presto! - there is no screen corruption [EDIT: other than the temporary, harmless effect noted above] and the bug has been fixed!

I'll provide an explanation of how this works when I have more time.

UPDATE: For the Software Projects version of the game, the bug causes corruption of the horizontal guardians in Room 8, which can soon prove to be fatal and prevent the game being completed. This variant of the bug can also be fixed, but one of the POKES is slightly different - swap the fourth POKE above for this one:

POKE #841D, #D2
or
POKE 33821, 210

MANIC Corruption Fix.zip

Edited August 1, 2017 by IRF

[IRF]

My apologies, the previous POKES didn't entirely fix the problem.  I've just discovered that the corruption is potentially more far-reaching if Willy jumps up off the top of a cavern, from a position four cell-rows below the top, compared with if he falls off the bottom.  With the previous version of the POKES that I provided, this caused a permanent, although non-fatal, corruption of one of the right-facing Toilet sprite-frames in "Eugene's Lair".

 

Therefore I've amended my previous post, tweaking some of the POKES slightly.  The code corruption should be fully prevented this time.*

 

N.B.  If you previously downloaded the zip file which I attached to my previous message above, then please delete it and re-download it with the correctly functioning POKES in place.  (There were previously two downloads, which I suspect that was Andy [spider] and Danny?)

 

(*Except for a brief temporary glitch that occurs at the 'Screen File' level (#4000-#4FFF) in the lower half of the screen, below Willy in cell-row 10, pixel-row 1 - a pair of Willy's graphic bytes is briefly drawn as he jumps off the top.  However, since the filled-in pixels don't appear at the buffer level, they can't collide with any guardians, so this doesn't affect the gameplay.  Note that this temporary glitch can also occur in the original game engine, without the POKES, if Willy jumps off the top - although it isn't visible if it coincides with Air cells and if the Air INK and PAPER colours match, or if it coincides with graphic bytes that are already completely infilled.)

Edited January 7, 2017 by IRF

[IRF]

Oh, and an explanation (of both the bug and the fix) will still follow - in fact, it was when I went to type up the explanation that I got distracted by noticing the potential for further 'overspill' of Willy's graphics.

 

(Fortunately, there are three contiguous unused bytes available for the POKES, whose addresses are of the correct format, and which lie just beyond the furthest potential reach of the corruption!)

Edited January 7, 2017 by IRF

[IRF]

A more detailed explanation for this fix is now available here:

 

https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/conversations/messages/7050

[IRF]

I've just discovered that this bug can actually be fixed using a single* POKE!

 

POKE #92B5, #2C

 

It replaces the INC IX at #92B4 with an INC IXL.  So the 'Draw Willy' routine doesn't start looking up addresses, via the IX index, that are beyond the end of the table in page #83 of the code.

 

Instead, when Willy is falling off the bottom of a Manic Miner cavern, the rest of his sprite is drawn at the top of the cavern (although in the first time-frame, it may not be visible if the Air INK and PAPER settings match).

 

Because whilst the low byte of IX may be incremented from #FF to #00, the high byte of IX always retains the value #83 if only IXL is incremented.  (Whereas in the original code, the incrementation of the IX register-pair means that it can proceed from #83FF to #8400.)

 

N.B. This does not address the issue where Willy falling past the bottom of a cavern causes errant (de facto Water) cells to be created in the top two cell-rows.  To resolve that, a separate fix would need to be applied to the code which writes Willy's attributes to the screen.

 

(* For elegance, you could also replace the preceding INC IX at #92B2 with an INC IXL, but that isn't necessary to fix the bug because the IX index always holds an even value going into those two consecutive INC IX commands, and so the first of the two will never increment IX from #83FF to #8400.)

Edited August 27, 2018 by IRF

[jetsetdanny]

Brilliant! :)