IRF

One more thought on the above - if the number of colours that the items cycle through is 7, then because that isn't an exact divisor of 256, Geoff Eddy's 'flying killer blocks' might eventually collide with one of the items (fatally) at a time when it happens to be White! This could be as late as 7 in-game minutes after Willy's entry to a room which has that PV enabled!

The havoc caused by the Attic Bug (with the POKEs in place to prevent Infinite Death Scenarios) is a classic case of The Butterfly Effect... https://en.wikipedia.org/wiki/Butterfly_effect

UPDATE: The disassembly seems to be of Geoff Mode 2. The Patch Vector disassemblies of Geoff's first three games refer to addresses in Geoff Mode 1, so they don't tally with the disassembly in some cases. However, the PV disassemblies for ZX Willy the Bug Slayer do tally with the Geoff Mode disassembly. e.g. Bug Slayer Room 31's PV calls up the 'Print a Room Element' code (in the same way that Rooms 10 and 53 of Willy Takes a Trip do), but this time from #8D96.

I would also add that in relation to the point above in blue, if you didn't try and shift Willy along the rope, then he sat there quite happily at the 'impermissible' height! (i.e. at a rope segment in the range 1 to 15 - N.B. Richard's POKES were also in place in the scenario being described.) EDIT: In this scenario, you can also turn Willy round to face in the opposite direction without triggering the sudden shift downwards - as long as you don't move him into a different frame of animation! Unfortunately, at the moment I can't share the working file in which I observed the above, but I'll try to recreate the phenomenon in a test file later. As promised above, I've recreated the effect that I was referring to, and I've recorded a .rzx file (see attached). Preamble: I've implemented Richard's POKEs that prevent Willy climbing above Rope Segment 15, changed the initial swing direction of the Ropes, drained the Swimming Pool of water, and set the Swimming Pool's Up Exit to itself. Here's a running commentary of the (short) recording: Starting in The Orangery, Willy drops down and lands on the Rope, at a segment that is higher than the permissible minimum value of 15. There he remains, swinging merrily; he can turn round and face the opposite way without moving (i.e. by pressing the Movement Key in opposition to his facing direction). But when I tried to get him to move along the rope (by pressing the Movement Key that corresponds with the direction he is facing), he jerks suddenly downwards, straight to Rope Segment 15 (as previously discussed). I then repeated the earlier trick of getting him to jump off the top of the screen, in defiance of our earlier analyses. After reaching the top of the screen, he emerges at the bottom (in the empty pool). Finally, I demonstrated another little quirky set of behaviours, which I believe are related to the effects above: - If you stand Willy underneath the Rope's central 'position of equilibrium', and make him jump sideways in the same direction that the Rope is swinging, just as the Rope passes over his head, then Willy doesn't catch onto the Rope, but he bounces off it (the rest of his jump is curtailed and he falls straight downwards); [There are then a couple of 'false starts' in the recording, where Willy jumped but missed the Rope] - If you start at the same position and make Willy jump sideways in the opposite direction to the way that the Rope is swinging, as the Rope passes overhead, then Willy is caught by the Rope - and in fact he moves up a segment (even if you haven't kept a movement key depressed after making the jump) - it then takes two nudges of the appropriate movement key [to climb downwards, you press the same direction as the Rope is swinging] to make him fall off the end of the Rope; - If Willy jumps straight upwards as the Rope passes over his head in the central position, such that he collides with the bottom of the Rope, then he is caught by the lowest segment (as evidenced by the fact that it only takes one nudge of the 'climb downwards' movement key, to make him fall off the end of it). P.S. The Adjacent Ropes Patch is in place, so this is all 'standard' Rope behaviour! [EDIT: Note to Danny: I've just come across an old message of yours on the Yahoo site; from my reading of it, it seems like you may have been encountering the problem of 'bouncing off the end of a Rope'? https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/conversations/topics/6355] More Rope Effects.rzx

This is a useful link: http://www.worldofspectrum.org/faq/reference/z80reference.htm In particular, one aspect of the section discussing doubly-shifted opcodes was very illuminating: http://www.worldofspectrum.org/faq/reference/z80reference.htm#DDFDOpcodes To me, the element that I have highlighted in italics in the above quote, is counter-intuitive.

Further to the above, it's just occurred to me that if there was a CALL (HL) command in the Z80 armoury, then that could replace the JP (HL), thereby allowing the Main Patch Vector code (i.e. the 5 byte subroutine that directs the program to the address stored at Offsets #EE-EF for the current room) to be inserted directly into the Main Loop. (EDIT: Any room that doesn't have an associated PV routine could be catered for by pointing its Offsets #EE-#EF at ANY existing 'C9' Return command in the code.) However, it's a moot point, as I don't believe there's such thing as a CALL (HL) command!

Manic Miner disassembly, #8E5F is described as "Save the INK colour in the attribute buffer temporarily" (for vertical guardians, etc) - technically, the BRIGHT value of guardians is also stored by this command. (See three of the vertical guardians in 'The Warehouse', for example.) EDIT: Although the 'Angry Eugene' code that flows straight into #8E5F does discount the BRIGHTNESS bit (via an AND #07 at #9E5D).

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