IRF

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)?

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...