IRF

By the way, congratulations Danny on recently passing the 1000-posts milestone!

I've just rediscovered an earlier post (discussing the forthcoming 'Jet Set Mini' project), which describes a similar kind of behaviour (with a twist). This should give another clue as to how I managed to achieve the jump off the top of the screen in the above: 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.

I can't recall which room it is where the guardian disappears into the conveyor without colliding?

1. I'm not sure regarding the emulator question, perhaps they're all okay? Maybe you play "in an emulator on a PC"? 2. A pixel (singular) collides; whereas pixels (plural) collide. So it's fine in the form that you quoted above. Incidentally, which room is it that you're referring to there?

I'd go for the plural 'formats'. I don't think it needs the article. I'm not 100% sure, but considering a more 'familiar' example: "Create a document in Word format", I don't think in that case you'd say "the Word format".

At least one of the routine pages in the Manic Miner disassembly ends with a comment: "This routine continues into [the next routine]." Perhaps a similar approach could be taken with the 'Start the game' entry in the JSW disassembly? i.e. if the 'Start the game' page just covered addresses #88FC to #8911, ending with a comment like the above, then have a separate page that begins at address #8912, called 'Room set-up routine' or something to that effect? As things stand, every time that Willy exits a room or loses a life during the game, the program is directed to a page which, on the face of it, is called 'Start the game'. Whilst the program is directed to the later entry point in those circumstances - and the hyperlinks in the disassembly also point to that later entry point (#8912) - I still believe that it would be clearer if the 'Room setup' entry point marked the beginning of a separate page of the disassembly (which would then have a distinct entry in the Routines Menu).

Yes, I would say "ends with a RET".

I would say either "the reason for" or "the cause of". And I'm not sure about the 'yet', as you're considering a future occurrence, whereas 'yet' implies a 'present tense', if you see what I mean? Perhaps "When it ends, the game does not go directly to the title screen, but to..."

How about: "allowed the game engine to use 7-bit (or, in theory, even 8-bit) room numbers, instead of 6-bit ones"? Also, if you're quoting the bit from JG Harston's page, perhaps you could correct the typo thus: Room numbers Memory 0 - 63 &C000 - &FFFF 64 - 127 &8000 - &BFFF 128 - [191] &4000 - &7FFF 192 - 255 &0000 - &3FFF With the square brackets signifying that you're correcting an error in the original source article. Then you'd be neither stating an inaccurate fact, nor misquoting the original article.

You might get away with creating a Room Number 155 (occupying the memory range #5B00-5BFF), if you didn't have any guardians in the room (i.e. just an 'FF' terminator byte at #5BF0, followed by 15 NOPped out bytes from #5BF1-5BFF). The bottom end of that 'page' of memory is the beginning of the stack, so Return addresses from CALL commands and register-pair values placed there by PUSH commands would occupy the area where the Guardian Specifications would otherwise sit. Depending how much the stack is utilised during the game*, the rest of the room's data might be left alone? (The stack entries would get copied to the end of the Room Buffer upon Willy's entry to Room 155, but with no adverse effect on the running of the game if they are preceded by the 'FF' Guardian List Terminator byte.) However, I don't think that any items could be displayed in a room in the range 128-255, unless the Draw the Items code were to undergo further modification. As things stand, Bit 7 of the first byte for each item's definition stores part of its y-coordinate, which is discounted (reset) for the purposes of comparing each item's room number with the current room number at #93DF. * Obviously the stack as an entity is used a lot, but if values get PUSHED on and then POPPED back off, then you don't progress 'up' the stack as a result; so what I really mean is how many consecutive entries (which fill up two bytes each time) get put there, starting at the bottom (#FBFE-FBFF) - i.e. consecutive PUSH commands, sub-routines called from sub-routines (generating multiple RETURN addresses on the stack), that kind of thing. Any more than six of those, on top of the two-byte entry which defines the game's starting point (namely #869F, or #87CA if the 'code entry routines' have been expunged), and you'll reach the location of (and overwrite) the room's Guardian Terminator byte at #5BF0. Which could lead to corruption of the whole game file, a la 'The Attic Bug'! Perhaps one were to insert the value 'FF' at #5BF0 in a test file, and then PEEKed at the value of that byte during the course of a game, then one could verify that it isn't ever modified from its initial value throughout the game, and so anything from that point upwards in 'memory page #FB' could safely be used to define a Room 155? But for the sake of a single room with no guardians and no items, there's probably no point other than as an 'academic exercise'!? EDIT: The memory range #5B00-5BFF is also apparently used as the 'Printer Buffer' - I presume that harks back to days of yore when you physically plugged a Spectrum into a Dot Matrix Printer or suchlike, and that alternative function wouldn't affect the values in that range, in this context?

I would argue that the statement, as quoted above, is certainly true. The fact that you might also be able to use 8-bit room numbers does not negate the truth of the statement that the change allows 7-bit room numbers. And it is questionable whether 8-bit room numbers are possible in practice. The change from OR to XOR may open up the possibility, but other factors (i.e. the use of the lower memory for other purposes) preclude room numbers beyond 127. So for simplicity, I would stick with what you have put. :)

The reason I'm confident is that the items cycle through 8 colours, whilst the trajectory of each flying block passes through 256 cells (32 rows x 8 columns, in the top or bottom half of the screen - rather like a Constant Arrow in fact!), and 256 is exactly divisible by 8. It amounts to this: if there isn't a fatal collision when the flying blocks pass through the items' locations first time round, then it shouldn't ever happen. In contrast, I would wager that, in the rooms where you noticed the fatal collision happening, it occurred the first time that the flying block passed through the item in question, rather than in a subsequent 'game minute'? I would also surmise that you could have avoided it happening - if you had wanted to pursue inserting the flying block effect into a room where you'd had the 'collision' problem - by moving the item one cell to the left or to the right [editing the hex code to do so], so that the collision [or rather, non-collision] occurred one 'tick' earlier or later, when the Item's colour had moved on from, or had yet to reach, White. Either that, or you could have transposed the item's two entries in the Item Table with the adjacent pair of entries in the Table. (Although if the second item were also located within the same room - and of course multiple items within a room often [though not always] occupy adjacent slots in the Item Table - then there's a 1 in 8 chance that it would have caused the blocks to collide with that item instead!)

I think you're only using 7-bit room numbers in practice, as any room number that is 128 or greater (i.e. extending into the highest bit) would be contained in the ROM (Rooms 192-255) or the 'contended RAM' where the buffers sit (Rooms 128-191 ... N.B. There's a typo in Jonathan's table where he states Rooms 128-192 for this memory range). So perhaps you're theoretically able to have an 8-bit room number, but it isn't possible in practice? i wonder if Andy can add anything useful to the debate?

I believe that if it doesn't occur during one 'game-minute' (i.e. 256 ticks/time-frames), then it won't ever happen. However, it's probably worth checking that that's the case in the final file, if you've shifted items around since last time you checked, because the colour of an item in a given 'tick' is dependent on the value of the tick counter (#85CB) and the item's position in the Item Table. And if, for example, you've deleted and reinserted an item that sits further down in the Item Table (#A400-#A5FF), then all the items may have been 'nudged down' the table by JSWED, which might affect the relationship between the location of the killer blocks and the 'colour phase' of the items. EDIT: I should perhaps point out, for the wider readership(?), that this is only a potential concern if you have the 'Eight Colour-Cycling Items' Patch in place, otherwise the items are never White!

That would be because the Items are drawn before the Patch Vector (which causes the flying blocks) has been enacted. Items are collected if, when the program comes to draw them, there is White Ink present in the cell where they are due to be drawn. So if there's a White arrow already drawn there, it will collect the item. At that point the killer blocks (I can't recall if they are White in any case?) haven't been drawn yet. The arrow routine won't trigger a fatality by coinciding with a White item because the regular arrows are drawn before the items. Conversely, the killer-block code which replicates the arrow routine, comes after the item-drawing code, so i guess they can potentially kill Willy if a killer block coincides with a White item in a given time-frame. (By the way, does this ever happen in WNM-SE, or are the locations of the items such that they are never White when a killer block reaches them? If that's not the case, I believe it could be made to be so by rearranging a few of the items within the Item Table.)

One of Geoff Eddy's patch vectors sends 'flying killer blocks' across the screen - am I right in thinking that these are effectively arrows, as far as the collision detection is concerned, and that they would be fatal to Willy if they hit anything with White Ink (e.g. ramps, for which White is the most common Ink colour)?

The former, I would phrase: "changes to the upper left of that room". The latter, any of these would be best, I think: "stuck in", or "stuck inside", or "stuck within".

Yes, although the value (of the Rope Status Indicator) at which the adjustment occurs is actually 14 or less (reset to 15) in the recording that I uploaded, not 11 or less (because I applied the POKES that you provided previously). Which makes the effect even more noticeable! Also, just before Willy is relocated downwards, he is briefly (for one time-frame) relocated upwards slightly, because his sprite is centred on his point of contact with the rope - which happened to be his head. EDIT: Actually, that latter effect is probably a fairly common occurrence whenever Willy gets onto a rope - his y-coordinate is adjusted up or down by up to one cell-height. Whereas the downwards adjustment you can see in the recording is quite large in magnitude (several cell-rows of sudden vertical displacement), and therefore much more noticeable as a result. Then I shall leave you to ponder for a while longer! Here's a clue though: I did something different, in terms of key presses, between the two occasions...

Richard, regarding the above... Whilst you and I reached the same conclusion, via different methods, it seems that we were actually both wrong! Please see the short .rzx recording attached to this post. It was based on a file in which I had applied both of the POKES that you provided in this entry of your disassembly: http://skoolkid.github.io/jetsetwilly/reference/bugs.html#fromTopToBottom Daniel (jetsetdanny) alerted me to the possibility of carrying out this manoeuvre. I managed to achieve it second time round in the attached recording. However, in the first instance, you can see that Willy makes a pair of rapid, quirky 'up and then down' jumps jerky relocations (which may help to provide enlightenment as to what is going on?) In a later post, I will comment on the reason why it is possible to 'defy' our analysis in this way, and I shall also provide a further code 'tweak' that should resolve this 'bug' once and for all! (Unless you manage to get there first?) Double Jump Rope Test.rzx

And of course, the precise manifestation of the Invalid Arrow's 'side effect' (colour-attribute blocks, a temporary pixel trail, or a permanent pixel trail) depends on the exact pixel-row position of the Invalid Arrow (within each cell-row, and in the top or bottom half of the screen).

One point that I didn't mention - it may be obvious but anyway - in the case of a 'Constant Invalid Arrow', the effects would occur throughout all eight cell-rows of either the upper or lower half of the playing area (being the opposite half to where the arrow is located).

I think the sound is supposed to represent the Arrow being 'fired', perhaps it should occur just as the Arrow enters the side of the screen - of course, that would mean it should be sounded eight times in each 256-tick cycle, rather than once in each cycle! i.e. Trigger the effect every time the Arrow occupies cell-column #00 if it's a left-to-right Arrow, or cell-column #1F if it's a right-to-left type. Actually, there's only one tick difference between those two, which isn't worth splitting hairs about. So you could just do a AND #1F on the Arrow's x-coordinate (stored at IX+$04 in the Guardian Buffer), in place of the command at #924C (you could also remove the commands at #9240 and #9247), then the JR NZ at #924D would ensure that the sound effect occurred each time the Arrow wrapped round the edge of the screen (just after it appears flying rightwards; just before it appears travelling leftwards). Those code changes would all have to be put back to normal in rooms with normal Arrows, though! One other point, I referred earlier to the Arrow moving one cell-row down the screen each time it reappears. However, that only applies to a left-to-right Arrow; for a right-to-left it would move up by one cell-row each time it wrapped around.

One other point - it wouldn't really make sense to have the 'Arrow Warning' sound at a random point when the Arrow is constantly firing?!

Indeed, I had your earlier comment in mind when I named the test file! If a 'Constant Arrow' starts off as Valid (because it's been inserted in a pixel-row other than the top or bottom one within a cell-row), then it will remain Valid throughout the 256-tick game cycle (and vice versa - which could be fun!) Yes, it's a game engine change that would affect all Arrows in the game. But you could make the intervention in the code via a Patch Vector, with the correct code restored by default in rooms where you don't want the effect.

I wasn't quite right with the above - the Arrow descends through each cell-row in turn down either the top half or the bottom half of the screen (depending on whether its allocated y-coordinate in the room's guardian specification data is in the top or bottom half), but stays within the same pixel-row within each cell-row. Therefore the Arrow in such circumstances will either be Invalid, or not, each time it appears. See the attached 'Constant Arrow' test file, with the aforementioned bytes NOPped out. Constant Arrow Test.z80