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

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:

I was just curious as to what it would draw up there! I'm pleased to report that it's pretty much what I expected. :) In the normal course of the game, this stuff is drawn 'behind the scenes' before the picture from the Title Screen is superimposed. The black background is present and correct towards the upper-right (where the Blinking Eye passes through, and two items and the portal are located). That's because the attribute byte for Air is located there, and of course Air cells are Inkless. In contrast, the 'grassy' parts of the top third of the screen have been assigned with the attribute bytes of Earth cells, and so the pixel pattern of Earth cells have been drawn in those locations by the 'Draw the current cavern' routine, instead of the Inkless grass which you normally see in the final product. There are a few instances akin to the 'Cell-Graphics Bug', where the attribute byte in the top third of the screen matches one of the graphic bytes within the room element data (#FE20-#FE67). If you look at the 'foliage' of the tree, it is drawn using most of the Earth cell graphics. But the top pixel-row of the 'bricks' is missing (that was the one which matched the defined attribute byte at those locations), and the lowest pixel-row is a graphical interpretation of the attribute byte for Conveyor cells. Also, the window of Willy's house is drawn using the bottom half of the Fire cells which are used in The Final Barrier (i.e. the green 'spiders', although they're black and white in this case), and these are followed by the attribute byte and then the top three pixel rows of the 'unused' Fire cells for this cavern (which are defined at #FE56-#FE5E as stalactites with the same form as the ones in the Kong Beast rooms, but with red INK on blue PAPER assigned as the attributes if only they had been used in the layout - although again, the part that is drawn where the house windows should be retains the proper colours for the windows: black and white). Finally, for the majority of the top third of the screen, the defined attributes don't match any of the bytes within the room element data (neither attributes nor graphic bytes). Therefore, by default - after the CPIR loop has searched through the range #FE20 to #FE67 and failed to find a match - the 'Draw the current cavern' routine picks up the next eight bytes that follow on after the room element data. If you look carefully at the apparently random pixel pattern that fills much of the top of the screen - such as the blue [technically, cyan] sky, or the tree trunk, or the rest of Willy's house, or his car - you can make out the following binary pattern in each cell: 11010000 00000000 00000001 00000000 10111011 01011101 00000000 00000001 Which in hexadecimal is: D0 00 01 00 BB 5D 00 01 And that happens to match the eight bytes from #FE68 to #FE6F: The next seven bytes are copied to 8068-806E and specify Miner Willy's initial location and appearance in the cavern. FE68 DEFB $D0 Pixel y-coordinate * 2 (see 8068) FE69 DEFB $00 Animation frame (see 8069) FE6A DEFB $01 Direction and movement flags: facing left (see 806A) FE6B DEFB $00 Airborne status indicator (see 806B) FE6C DEFW $5DBB Location in the attribute buffer at 5C00: (13,27) (see 806C) FE6E DEFB $00 Jumping animation counter (see 806E) The next four bytes are copied to 806F and specify the direction, location and length of the conveyor. FE6F DEFB $01 Direction (right)