IRF

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!

I don't suppose you left some of the POKES in place after your abandoned attempt? It might explain why overwriting the code at Room 63 causes problems.

I wondered if you had something like the 'bad Pause-Bug fix' in place. See here for info: http://www.oocities.org/andrewbroad/spectrum/willy/bugs.html#pause_bug Or the Cell-Graphic bug fix provided by Skoolkit also uses addresses in Room 63's range: http://skoolkid.github.io/jetsetwilly/reference/bugs.html#corruptedConveyors

Have you used the memory there for a bug fix?

I'm not sure why that happened? You should be able to move items around safely enough. All that changes is the order in which they are arranged in the game code. (Which can change the colour in which they are displayed, during a given moment in time, but that's barely discernible.)

Looks good! Regarding moving Esmerelda, that shouldn't pose any problems in this specific case, as it's the only instance of a guardian of the same class in the game. :) However, in general, if you're changing the parameters of guardians then you have to be careful as it can affect other guardians of the same class elsewhere within the mansion. :ph34r:

Andy's solution in the 'Bug Fix Edition' (adding a roof to block the exit) seems a lot less convoluted, and closer to 'as manufacturer intended' if that's the remit?

But what if the player wants to pause the game themselves?

J.G. Harston came up with a cunning, yet easily inserted solution for that: http://mdfs.net/Software/JSW/JGH/Docs/Pause.htm (Scroll down to the bottom: Bugfix 2)

See this thread: http://jswmm.co.uk/topic/184-guardian-aura-bug-fix/

Yes I'd say it is a bug or perhaps an 'omission'!

If you study the code that causes the tune deterioration, I don't think it could have been an accident...?

I definitely think the conveyor-ramps were intended as a feature, rather than a bug. Otherwise we might start questioning the use of multiple water-ramps in the likes of Out on a Limb, too.

Sorry, I should have clarified: we also changed the colour of the conveyor in Conservatory Roof to green, to match the ambience of that room - which should also prevent the matching attribute problem that you've identified from occurring..

We used that very conveyor in Conservatory Roof in The Nightmare Edition!

Yes, I thought that was a bit off.

Then there's the fix to prevent the illogical exit from 'Rescue Esmerelda' to 'Ballroom East'.

No, I tried it - he walks forwards towards the altar and backwards away from the altar! (i.e. facing the same way throughout) I don't think it's possible to get a guardian to walk backwards in both directions without swapping the left- and right-facing sprites around?