IRF

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)

Andy (or whoever wishes to) - try this in Manic Miner: POKE 35502, 201 Then visit The Final Barrier (use Boot Cheat mode for ease of access). Observe! (and post a screenshot here if you get a chance? I haven't tried this yet and I don't currently have access to SPIN to be able to try it out. But I would predict that the results might be 'interesting'!)

Or perhaps you might have something to say over there in response to some of my recent posts? You might be particularly interested in a brand new quirky challenge that I think I've come up with..

A decadal milestone of sorts has been reached today - it is exactly ten years since Andrew Broad's Yahoo! Group reached its last millenial milestone: Post number 6000 was submitted on 21st December 2006. (See the link in the quote above.) Prior to that point, during the earlier history of the Yahoo! Group, such milestones were reached approximately once per year on average. So things seem to have slowed down considerably since that date. Now, I've tried my best over the past few months to push the Yahoo! Group towards the next target of Post number 7000, in the approach to today's anniversary. But alas, it's still about 18 posts short of that magic number...

Skoolkid helpfully provides a list of unused addresses: http://skoolkid.github.io/jetsetwilly/maps/unused.html :)

I wonder if what happened there (to cause the corruption) is that you ended up trying to fix the Cell-Graphics Bug twice, using two different methods at the same time? (i.e. Stuart Brady's fix - as reported in the 'Cell Graphics' thread; and Richard Dymond's fix - which is provided in his SkoolKit disassembly site under the heading 'Corrupted Conveyors'.)

If you relocate the part of the Conveyor Fix code that was located within Room 63's room data, to another vacant part of the code (there are plenty of gaps in the guardian graphics section, for example), then you should be able to populate Room 63 safely!

The 'conveyor corrections' IS the cells graphics bug fix? I think it calls an address in Room 63's range!