[File] Manic Miner - Highscore Challenge

[jetsetdanny]

21 minutes ago, DigitalDuck said:

There's a limit to how many lives you can have before each level becomes incompletable (although you can always lose lives until they become completable again).

Thanks for this amazing investigation, DigitalDuck!

Are you sure about the statement quoted above? I haven't checked this out in any way, but judging by other instances of corruption that happen in MM games, I thought once it happens, it cannot be undone. Meaning: once some rogue cells are printed on the screen, they stay there.

However, I may be wrong on this, so this is just a question, not a suggestion that your statement was incorrect 🙂 .

[IRF]

13 minutes ago, jetsetdanny said:

Thanks for this amazing investigation, DigitalDuck!

Are you sure about the statement quoted above? I haven't checked this out in any way, but judging by other instances of corruption that happen in MM games, I thought once it happens, it cannot be undone. Meaning: once some rogue cells are printed on the screen, they stay there.

However, I may be wrong on this, so this is just a question, not a suggestion that your statement was incorrect 🙂 .

When Willy falls off the bottom of a cavern (or jumps up past the top), the corruption happens to the data of certain caverns, so you would have to reload the game file to reset it. (Same with the Attic Bug in JSW.)

The spare lives overspill is happening in the buffers, so it's not permanent. If you lose some lives, then it will start to become undone (the errant blocks will retreat from right to left across the screen.)

[IRF]

13 hours ago, DigitalDuck said:

It seems that it's still collectable when another attribute is printed over an item - this happens in Abandoned Uranium Workings. It also seems that the bug is consistent in what it puts on-screen. My main concern is that it isn't possible the first eight (at minimum) times you complete the cavern, and these are clearly different caverns to those intended due to modified terrain.

Ah, that item you're referring to is in an 'odd' column number, so nothing is printed there for a Willy sprite in its leftmost frame of animation. (Well, technically the value #00 is written there, but that's what was already there anyway as it's an air cell in a room with a black background, so nothing changes in that cell and the item remains collectable. Try setting the dancing lives to a different animation frame and I think you'll find that it's uncollectable.)

Conversely, the auto-collected item in Kong Beast is in an 'even' column, and it's actually one of the spare Willy's front foot which 'collects' it - the byte value for his feet in that position is #77, the first 7 represents his back foot, the second digit is his front foot, and that 7 is interpreted as white INK in the attribute buffer!

Edited February 26 by IRF

[IRF]

By the way, is there some temporary flickering of these blocks? I have a feeling that there would also be some overwriting of the actual screen attributes, as well as the attribute buffer, causing flickering (which is just a visual glitch not affecting gameplay). The stack may also be overwritten, which could in theory have more serious consequences (like the program crashing!) 

[IRF]

1 hour ago, IRF said:

Try setting the dancing lives to a different animation frame and I think you'll find that it's uncollectable.

Sorry, I just checked the data for the rest of Willy's frames of animation. That foot stays in the same place for the next two frames, so would still be manifested as white INK when printed onto the attribute buffer. It's only if you move the spare lives on to the last animation frame ('legs apart'), before entering the Kong cavern, that the item won't be auto-collected, but should instead be uncollectable.

Edited February 26 by IRF

[DigitalDuck]

1 hour ago, IRF said:

By the way, is there some temporary flickering of these blocks? I have a feeling that there would also be some overwriting of the actual screen attributes, as well as the attribute buffer, causing flickering (which is just a visual glitch not affecting gameplay). The stack may also be overwritten, which could in theory have more serious consequences (like the program crashing!) 

Yes, it's both the playing area and the buffer that's overwritten. When drawing a sprite it adds 256 to the memory address to go to the next pixel row, but naturally the screen attributes follow directly after the screen pixels so they're being drawn to. Even in the most extreme scenario lives are only drawn to pages 80-95 (memory addresses 0x5000 to 0x5FFF) which contain the lower third pixel data for the screen, attribute data for the screen, and the attribute buffers. I'm not sure where the stack is stored, but I don't think it's being overwritten here.

[IRF]

54 minutes ago, DigitalDuck said:

I'm not sure where the stack is stored, but I don't think it's being overwritten here.

 

Actually, you're right. In Jet Set Willy, the stack starts at the bottom of page #5B of memory (that page was originally designated as a printer buffer for use if your ZX Spectrum is hooked up to a ZX Printer, if I recall correctly? - which is obviously not a consideration when playing games like JSW/MM, so it's a good place to put the stack.)

I had assumed that this was also the case in Manic Miner - that the base of the stack would be placed at #5BFE-5BFF.  And hence at theoretical risk of eventually being overwritten by the bonus lives (if enough of them built up?  The errant blocks would have to be reaching the bottom right of the playing area for that to occur, so other things are likely to have gone catastrophically wrong long before that occurs!)

But apparently it's not even a theoretical consideration, because according to SkoolKid's MM disassembly, the base of the stack is near the end of the remnant source code which starts at #934C.  So the stack builds up from addresses #9CFE-9CFF.

(Incidentally, anyone working on a MM mod and finding a purpose for that available part of memory - #934C-9CFF - would be advised to steer clear of the last few bytes, lest the program overwrite the addresses stored on the stack during flow of execution, or vice versa!) 

Edited February 26 by IRF

[IRF]

Just for fun, have you tried POKING a value of #FF (255) for the remaining lives - the maximum amount that can be stored in a single byte, to see what happens? 😆

EDIT: After scrutinising the code, I predict that the temporary flickering (not affecting gameplay) may reach the second character-row of the playing area, but the blocks which Willy can interact with won't have reached that far yet.  And the spare lives wouldn't reach the bottom of the stack (even if it WAS held on page #5B on memory) until they were greatly in excess of 256 (too many to be held in one byte).

Edited February 26 by IRF

[MtM]

Right, I am going to say it, even if it's wrong - who is going to do this same experiment with JSW? 😉

 

Edit - I have loaded up the original JSW just to see what possibilities there are for this. But it doesn't look like there are any? I know the arrows etc in the original corrupt data, but wondering what could be done to purposefully corrupt it like Duck has done? Not sure it is possible really. The thoughts of creating platforms in some rooms seems good though.

 

Edited February 26 by MtM

[IRF]

1 hour ago, MtM said:

Right, I am going to say it, even if it's wrong - who is going to do this same experiment with JSW? 😉

No extra lives are awarded in JSW, so you would have to POKE a big number to the Remaining Lives variable to see what happens.