IRF

Richard, for this section of the JSW disassembly: http://skoolkid.github.io/jetsetwilly/asm/8D33.html regarding the RETURN command at #8D6A, I think it would be helpful to the reader if you added a note adjacent, something to the effect that: The first time this RET command is reached, it returns the program back to $8D42 (in order to draw the tiles for the bottom half of the room to the screen buffer at 7000). The second time this RET command is reached, it returns the program to the

Thanks Andy!

Andy, I've just noticed (for the first time(!) the 'Manic Miner Updated' version in the 'Downloads' section. A couple of queries: Does that mean that the 'Screen Flash' effect no longer takes place when the player accumulates 10,000 points? Or does that still occur, but without an extra life being granted? How exactly did you achieve the slowing down of the scrolling message?

I was only joking about the apple!

What about using the 'apple' item shape from the Watch Tower - roast pork and apple sauce go well together!

It looks like the Pig is about to get skewered!

A JSW game based on the life of H from Steps would be about as random as, say, a game centred on an obscure character from an Antipodean soap opera...

"Andrew Broad's Blackstar" has a certain ring to it...

Bingo!!! You may not have noticed it, but there was a careful use of italics in this part of my previous post: My posing the question as to WHY this makes a difference to Willy's behaviour, was aimed more at the likes of Richard, who perhaps has more in-depth knowledge of the rope-drawing code? Incidentally, it's got nothing to do with the Adjacent Ropes Bug - John Elliott's patch for that is in place in the 'No Top to Bottom' file, and in any case there's an arrow in between the two ropes in The Beach's guardian list. Anyway, thanks for taking up my challenge, Danny!

Sorry, I thought (assumed on the basis that you said you hadn't read the spoiler) that you'd only tried in On the Roof. Have you also wandered next door and tried (successfully) in The Beach (I made a short-cut between those two rooms to make it easier to investigate)? If you haven't been there, then you should be puzzled as to why Willy behaves differently on two identical ropes (of the same guardian class, and perhaps I should have made it explicit that The Beach's Up Exit is also set to itself), without any kind of Patch Vector involved?! However, if you've been to The Beach in that file, you'll have noticed something different about that room, and whilst I haven't yet provided a full explanation, it should give you a pretty big clue! EDIT: i.e. It is The Beach that is the exceptional room in this file, not On the Roof.

Now read the spoiler, and try again! No Patch Vectors, or other changes to the game engine, were involved!

Richard, the 'From Top to Bottom' Rope Bug just got even more interesting again! I think I have managed to come up with a code change which precludes Willy escaping 'from the top to the bottom' of a room that has a rope and the Up Exit set to itself. On top of the POKES provided in the disassembly, which reset the values at #9396 and #939A in the Rope-drawing code from 12 to 15 ('#0C' to '#0F' in hex), I have changed the value of a single byte. (Actually, for consistency I changed two bytes, from the same old value to the same new value, but only one of the two is directly relevant to the matter at hand.) My initial attempt at a new value for the pertinent address proved to be insufficient for the task, but I managed to identify why, and then resolved that by tweaking the new value accordingly. This may seem a bit cryptic at the moment, and I promise that I will reveal all soon. But before I provide a full explanation, I would like to invite, nay challenge (if not defy ;) ) jetsetdanny - and anyone else who might care to try - to confound me, by opening up the attached file and succeed in jumping off the top of the starting room (On the Roof), via the rope!! And then, once you have (hopefully!) failed to do so, please read the spoiler box below for an even more peculiar revelation... No Top to Bottom.z80

So ramps are drawn as a sloping surface (in terms of the pixel pattern within each ramp cell), but are treated - from a 'physics' point of view - as a series of discrete floor cell steps?

Incidentally, the first character of the scrolling message at #9400 has also been altered in that 'Manic Miner Corrupted' file (from a full-stop into a 'tilda'), because the message immediately follows on from the base of the stack at #9CFE-FF, which is also overwritten. (Luckily that doesn't seem to affect the contents of the stack, such as Return addresses, etc, which are placed at #9CFC-FD and upwards.)

A bit of further analysis of the above... When Willy wraps beyond the top/bottom of the screen, it is the third pixel-row of the part of his sprite that wraps around, which is responsible for the graphical corruption of the screen 'Miner Willy Meets the Kong Beast'. Two adjacent cells are affected, corresponding to the two halves of his sprite. In the previous example, the corruption of 'Miner Willy Meets the Kong Beast' was caused by Willy jumping up (in The Warehouse, if I recall correctly) and his head extending above the top of the screen. (Though in reality, his head was drawn at the bottom, and his legs extended beyond the bottom of the screen, as far as the Willy-drawing code is concerned - he is drawn from top to bottom.) Because of the relatively limited extent to which his sprite wrapped around on that occasion, there was a greater chance of a pixel-pattern being observable in the room cells where the rogue attributes were drawn. But if Willy drops through the floor, then he does so in four stages (half a cell-row at a time), before reappearing at the top of the screen. In each time-frame when he is wrapped around, the pair of his sprite's graphic-bytes that are currently three pixel-rows below the bottom, are over-written onto the 'point of corruption' pair of room cells, via an OR command. This means that by the time Willy has passed through the bottom completely (and starts to be drawn in his entirety at the top of the screen), it is more likely that at least one solid, Bright White square (representing a colour-attribute of #FF) will be written to the screen - because all eight pixels of the corresponding pixel-row will have been filled in at some point during the four-stage process of falling-off-the-bottom. (Especially so if he is falling in his 'legs-apart' frame of animation.) However, if you carefully study Willy's sprite data, alongside the room-cell data for 'Miner Willy Meets the Kong Beast', select the right frame of animation, get him to fall through the floor and then abandon the game at the right moment, then restart the game and revisit the screen, you can get this quirky corruption to 'behave' to a certain extent. Please see the attached .rzx recording. I managed to get Willy to fall through a hole in the floor in his right-facing Animation Frame 1, but then abandoned the game after only his feet (four pixel-rows, or half a cell-row of his sprite) had fallen through the bottom. His 'legs together' frame meant that the left-hand half of his sprite wrote '#06' to one of the locations in the screen's attribute data - which is the same as the colour-attribute of the 'Switch' in this cavern - whilst the right-hand half of his sprite had no infilled pixels (i.e. a value of '#00'), so it caused no overwriting of the adjacent cell to the right. You can see that when I restarted the game and teleported (using the WRITETYPER equivalent) to the Kong Beast screen again, a Switch had magically appeared halfway down the screen... Note that the new Switch wasn't there at the start of the recording; it has been created by the process of Willy falling off the bottom of the screen in the previous game. Note also that it doesn't act as a Switch for the purpose of opening up the doorway between the two halves of the screen, or making the Kong Beast fall. It does act like a Water cell though; Willy can jump through it, but he can also stand on it. I then went on to fall through the bottom of the cavern completely, and then after losing a life - causing the screen to be refreshed - the Switch had been replaced by a solid White block (which also acts as a Water cell). Magic Switch.rzx

My message about the quirky features of Adjacent Ropes should seem like a doddle to get through in comparison... In the Manic Miner corruption, I didn't even go into the detail of which of Willy's sprite's graphic bytes, when OR'ed with each other, gave rise to the values that ended up written as attributes (although I think I've figured that out too!) EDIT: Although I have done that now..

From Rufus Standish's review: "Quirkafleeg is a reference to Gilbert Shelton

Well, I could have used my 2000th post just to say thanks here, but instead I opted for a more obscure, esoteric and brain-frazzling essay, over in one of SkoolKid's disassembly threads! (Clearing up another little mystery in the process!)

Further to the above, whilst the left-hand 'errant' block appears as a solid White block (because both INK and PAPER are set to White), if you capture a screenshot at the point of Willy's death (when all filled-in pixels on the playing area progress through the spectrum of colours, whilst all non-filled-in pixels are rendered in Black), you can see that there is a pixel pattern 'behind the scenes' in that cell. Please see the attached screenshot 'MM Room 7 Corruption 3' (which captures the 'Cyan' phase of Willy's 'death throes'). If you look at the left-hand rogue block (which lies above the left-hand edge of the conveyor, seven rows above), its pixel pattern doesn't match any of the pixel patterns of the various room elements for 'Miner Willy Meets the Kong Beast'. (N.B. For comparison, I've also reattached here the earlier screenshot 'MM Room 7 Corruption 2', which was taken during normal play and so the same cell appears in solid White, with no pixel pattern visible.) At the time when I previously reported on this issue, I was slightly puzzled as to where the mysterious pixel pattern came from. But I've now figured it out! Because the attribute value '#3F' doesn't match any of the attributes or graphics bytes for this room's cell types (i.e. none of the bytes in the range #CE20-#CE67), the CPIR loop at #8A96 progresses all the way to B=0 without finding a match. At that point, HL has been incremented to #CE68 by the CPIR loop, and so by default the cell's graphics are drawn using the next eight bytes in that room's definition. As the MM disassembly states, the next seven bytes [after the tile data] specify Miner Willy's initial location and appearance in the cavern: CE68 DEFB $D0 Pixel y-coordinate * 2 - #D0 = 11010000 in binary, top pixel-row has Bits 4 and 6-7 set CE69 DEFB $00 Animation frame - blank pixel-row CE6A DEFB $00 Direction and movement flags: facing right - blank pixel-row CE6B DEFB $00 Airborne status indicator - blank pixel-row CE6C DEFW $5DA2 Location in the attribute buffer at 5C00: (13,2) - of course, these are reversed in the code, so #A2 = 10100010 appears above #5D = 01011101 CE6E DEFB $00 Jumping animation counter - blank pixel-row Then the eighth graphics byte (bottom pixel-row), which just has a single pixel filled-in at the far right (i.e. Bit 0 set) corresponds to the next room definition byte at #CE68, which is actually meant to specify the direction of the conveyor in the room (value 01=right)! P.S. I believe that the above effect would still have happened with Stuart Brady's Cell-Graphics Bug Fix in place, as the room-drawing routine would still end up (albeit via a different method) with HL pointing at the same address (#CE68), in the absence of a match with the eight possible cell attribute values. Whereas SkoolKid's alternative Cell-Graphics Bug Fix works differently (actually, he only provides one for JSW http://skoolkid.github.io/jetsetwilly/reference/bugs.html#corruptedConveyors, but if the same principle were applied to Manic Miner - even though the bug doesn't actually manifest itself in original MM); I believe that the modified routine would keep on searching through the code, skipping forward by 9 bytes each time, until it eventually finds a match, and then select the next eight bytes to use as graphics bytes for such a 'rogue' cell. Although I've no idea what would happen if it reached address #FFFF without finding a match?! (Any thoughts on this matter, Richard?) P.P.S. In Jet Set Willy, in theory the eight bytes after the room cell data (#80A0 to #80D5) could also be picked up as graphics bytes in a similar way - in that case it would be the Conveyor and Ramp definition bytes (4 bytes each) at #80D6-#80DD in the Room Buffer that would be selected. However, I don't think that would actually occur in practice within JSW, because the code that distributes attribute bytes across the screen works quite differently, such that I don't think you'd ever end up with an 'errant' attribute value written to the Empty Room Attribute Buffer at the point when the screen is drawn (i.e. during running of the Room Set-up routine). Now, Invalid Arrows (or Vertical Wraparound Guardians) can cause odd attribute values, which don't match any of the six cell types, to be written to the Empty Room Attribute Buffer. However, this only occurs during the Main Loop, and so while it can alter Willy's (attribute-based) interactions with the affected cells, it doesn't affect how they are drawn (i.e. background cells are left as solid coloured squares - which behave as Water cells by default if they don't match one of the other cell types - and any existing pixel pattern in a non-Air cell, whose attribute is altered by an Invalid Arrow, is left unchanged).

Further to the above, I've just noticed that if the redundant LD E, C instruction that (used to be) at #8D4D is consolidated away, rather than just being NOPped out, then the relative jump that (used to be) at #8D67 should have its operand adjusted accordingly (from '20 DD' to 20 DE'), so that it loops back to the LD A, (IX+$00) command that (was formerly) at #8D4E.

I believe all the screens in JSW2 have Black backgrounds anyway?

Off the top of my head: assign the previous INK colour for the host cell for the item under consideration to the A register. Increment A, then AND 07 [to select the INK Bits only]. Then do a 'CP' - whose operand is the value of #80A0 from the current Room Layout Buffer, subject to an AND 38, then RRCAx3 [i.e. pick up the PAPER colour of the current room's Air cells and shift it into Bits 0-2]. Follow that by a JR NZ that leapfrogs another INC A (so if there's a colour match, that colour is skipped), topped off with another AND 07 for good measure. (You would need to initialise each item's colour for the first tick in the room, so that in a multi-item room they don't all constantly match. In original JSW, that's achieved based on the tick counter added to each item's position in the Item Table; you might require another check to ensure that an item doesn't start off matching the background colour.)

In which case, a more complicated intervention must be taking place in JSW2. As I recall, you inquired as to whether it could be done by a simple 'tweak', as by that stage in WNM's development you didn't have the spare bytes for a more detailed bit of code. Of course, seven-colour cycling items would always 'disappear' (for one tick in every seven) on any rooms with non-Black backgrounds.

Out of interest Danny, is this the reason why you recently made an enquiry (picking up an earlier idea of mine) about the possibility of restricting the items to flashing in six colours only (excluding Black and White)?