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!)

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.)

I suppose to have truly fixed the clock properly, the display should change from 11:59pm to 12:00am (i.e. midnight) just as the foot is coming down to squish Willy on the Game Over screen.

You mean the game shouldn't run on till 1am?

Ending the game at noon im TNE meant that we never got round to resolving the am/pm thing. I'd be interested to see what you come up with!

Some thoughts - I hope they are of assistance... Surely the values #09 and #BE only come into consideration, because they are the Z80 op-codes for two of the instructions that are inserted by SkoolKid's POKES? Now, if you insert the POKES at the addresses which SkoolKid suggests, it just so happens that they overwrite the operand of an (unused) Call instruction - but I don't think that Call command (at 65317 / #FF25) is ever executed, and I don't believe that #BE09 [bear in mind here that low bytes come before high bytes in 'Little-endian logic'] was ever intended as a destination address!

I'm not sure, but #BE09 is mid-way through the guardian graphics data, so I'm not sure what the purpose of Calling that address is?

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

I think you could do without this one (it doesn't appear to do anything; the destination of the earlier jump is 42641): POKE 42640,220 Which would take it down to 12 POKES in total. The reason SkoolKid was able to bring the number down to 10 POKES, is because he made use of an existing relative jump within the remnant TRDOS code, which happened to have the same destination (three bytes backwards) as the one that you've used above. ****** Also note that Stuart Brady (Zub)'s Cell Graphics Bug POKES achieve the same thing. i.e. they fix the same bug - which happens to only affect conveyors in original JSW, but the bug can in theory affect most cell types, so whilst Stuart's fix uses a greater number of POKES, his description: 'Cell Graphics Bug' is more generic and more informative than SkoolKid's: 'Corrupted Conveyors'. Furthermore, the two bug fix methodologies are slightly different. Mickey, I believe that you might have run into additional trouble in your 'As Manufacturer Intended...' project, by trying to implement both bug fixes at the same time? (Perhaps because you hadn't appreciated the fact that the two were designed to fix the same problem.) If that was the case, then one set of POKES (which work in the same area of the code) may have ended up partially overwriting the other - causing a crash!!

Is it possible in some cases that there never was a loader in the first place, but the game was built by editing a screenshot from an earlier game?

Ditto!

I suppose so. However, in 'Mini' I think* I've added a command at the start of the Game Over routine which blanks out the room name line. (*I'll check when I resume work on the project - hopefully in the coming few days!)

Your announcement of the 30 Year Quiz on Yahoo is message number 7007 - the digit '7' thus playing a double role, on the day before 2017 commences!

Admittedly, I've only observed it thus far as a static screenshot, not as a dynamic screen effect. It probably doesn't look as odd when you're playing the game! In a similar vein, I was never a fan of the previous room name remaining in situ during the Game Over sequence in the original JSW, although I guess that's a matter of taste.

Sorry, of course that should have read "below the plinth"!

Congratulations Danny! One minor thing has struck me, looking at the screenshots - the quiz questions seem to span across the bottom row(s) of the middle third of the screen and the top row(s) of the bottom third. This causes a slightly odd effect on the Game Over screens whereby the end of the previous question is still present above the 'plinth', whilst the start of the question has been overwritten. It might have looked better if, at the onset of the Game Over routine, the upper character row(s) of the bottom third of the screen had been overwritten with blank characters (or else had INK set to Black in order to match the PAPER colour, thereby making the remaining text of the question invisible), but I suppose it's too late to do anything about it now? Anyway, I'm being picky (and I don't really have a right to be, considering I haven't found time to engage with the project prior to this point) - congratulations again on this latest JSW milestone!

Also, I did wonder whether 'level' could be interpreted as 'platform'? e.g. the Pair of Atlases rolls across the upper level of The Bathroom in the starting room of original JSW.

No problem! Incidentally, I ended up deleting the odd few messages in the run-up, on occasions where I'd posted in haste and made an error, then gone back and corrected it (since there's no 'Edit' function). That wasn't a deliberate tactic to reach the milestone, but it might have helped us get there a bit quicker. Then again, I dare say it would have happened a fair few times over the years, before I bust onto the scene!

Sounds fair enough to me. :) Maybe levels (caverns), just to avoid ambiguity?

Actually, my last post has brought J.G.Harston out of the woodwork! So now it's on 6999...

It's at post number 6998 now, but I've run out of things to say for the moment! Danny, if you post your announcement about the Quiz in the next couple of days, then I shall let Andrew have the honour of submitting post 7000 at the time of his choosing!

Over on the Yahoo! site it's now only 5 posts shy of the magic number... Perhaps it'll reach the milestone before New Year?

In a similar vein, when it comes to drawing the guardian sprites, I think it would have been more elegant (and would perhaps have made it easier to understand how it works), if the first three bytes of the guardian definition were loaded up in their numerical, 'indexed' order at #9211: http://skoolkid.github.io/jetsetwilly/asm/91BE.html#9211 i.e. In turn: - Load up the guardian's current Animation Frame; - AND with the Animation Frame Mask; - OR with the Base Sprite Index. Which is mathematically identical to what the code actually does, as A AND B is equal to B AND A. EDIT: To clarify, what the code actually does is: - Load up the guardian's Animation Frame Mask; - AND with its current Animation Frame; - OR with the Base Sprite Index. As I said, it amounts to the same thing, but if you think in terms of the Animation Frame Mask being a filter (to select the correct number/sequence of frames to cycle through), I think it's more rational to load up the current frame first, and then AND the Frame Mask, rather than vice versa. (Then in either case, ORing with the Base Sprite from the Guardian Specification selects the correct start sprite-frame.)

Happy Christmas to the jswmm community!

If there are any guardians in the top half of the screen, then they'll probably collide with the scenery and kill poor Willy in the process! :lol: