IRF

Regarding the above I've just noticed that, whilst it wasn't mentioned in the latest Changelog, Richard has added a note to that effect in the relevant page of his disassembly (and also towards the end of the preceding page): http://skoolkid.github.io/jetsetwilly/asm/8141.html http://skoolkid.github.io/jetsetwilly/asm/8100.html Thanks Richard! :)

I've just had a thought - if we were to try to come up with a 'fix' for the above, we'd have to be careful not to implement it in such a way that prevents Willy from walking down the ramp into The Swimming Pool (i.e. through the Water cells - which in this case really do justify that name!) Or for that matter, walking down the Ramp from West Wing Roof to West Wing.

Danny, did you pick up the document I forwarded via a PM (it fell at the end of a 'page' of messages so you may have missed it). If so, did it help you to formulate the appropriate words for your readme?

To answer my own question, I think it could just cause more problems than it solves! If the check for Fire cells was applied to the Empty Room Attribute Buffer, then it should still correctly pick up Fire cells within the room, but if Willy's sprite occupied the bottom two cell-rows (i.e. as he's falling off the bottom of the screen), then the check for Fire cells underneath him will probably wrap beyond the bottom of the screen to the Screen Buffer (for an occupied room) at #6000 (which contains the pixel patterns of all the room elements and all the entities within the room). Therefore the check for Fire cells will probably pick up the top pixel-row of the cell that lies in the uppermost cell-row directly above Willy. So if that cell happens to contain something (not necessarily a Fire cell!) whose first graphics byte (i.e. top row of pixels) matches the attribute byte for the Fire cells in that room, then the program will interpret that as if Willy has landed on a Fire cell, and kill him! Any room element (Earth/Water/Ramp cells) at the top of the screen could potentially cause such a match, giving rise to a 'misdiagnosis' that Willy has stood on a Fire cell! It could even occur if an (uncollected) item lies at the top of the screen, whose first pixel-row matches the colour-attribute of the Fire cells. (N.B. such a match does actually exist in Tree Root, although the items aren't at the top of that screen.) Or if a horizontal guardian happened to pass along the top of the screen, through the pertinent cell, such that the top pixel pattern of the portion of the guardian that instantaneously occupies that cell, matches the Fire cells' colour-attribute at the precise moment just before Willy drops off the bottom of the screen, then it could also trigger a positive check for a Fire cell 'beneath' him and kill him!

Oops, typo corrected! (I was getting ahead of myself, with a half-formed answer to my own question in my own head as I typed - on which more later!)

I notice that in his disassembly, Richard has managed to identify the precise cause of the bug (or quirky feature?) whereby a Fire cell at the top of the screen can kill Willy if he drops off the bottom directly underneath: http://skoolkit.ca/disassemblies/jet_set_willy/reference/bugs.html#longDistanceNasties I had got as far as surmising that it's something to do with the check for Fire cells, underneath the 2x2 square of cells occupied by Willy, somehow wrapping around from the bottom of the screen to the top. However, the 'missing link' in terms of the explanation is that the Attribute Buffer for the occupied room (i.e. occupied by guardians, items and Willy) at #5C00, is immediately followed in the code by the Attribute Buffer for the empty room (i.e. the room without guardians, items or Willy - but, crucially, WITH the Fire cells) at #5E00. Whilst it can be quite a useful bug in terms of preventing Infinite Death Scenarios, I wonder if hypothetically this could be fixed by pointing the check for Fire cells to the Empty Room Attribute Buffer at #5E00 instead of the Empty Room Screen Buffer Occupied Room Attribute Buffer at #5C00? Any thoughts?

Another suggestion for the disassembly: The POKE that fixes the 'uncollectable item' in Conservatory Roof (the rightmost item) does not fix the fact that Willy has to sacrifice a life in order to collect the leftmost item in that room. A simple single-POKE fix for this is to extend the green platform to the left of the conveyor by one cell leftwards: POKE 60269, 1 EDIT: Sorry, having playtested this you would also have to 'delay' the Red guardian by shifting its starting position rightwards by one cell, otherwise Willy couldn't jump over it in time without hitting a fire cell: POKE 60401, 21 Still, it only takes two POKES (on top of the Software Projects one that removes the rightmost fire cell) to make this screen completable without loss of life. However, see the following link for a more satisfactory visual fix which, by shifting all the fire cells and items along to the left by one cell (and rejigging a couple of platforms), manages to keep them all paired up (as per the original screen), whilst ensuring that all four items can be collected without losing a life: http://jswmm.co.uk/topic/65-conservatory-roof-changes/?p=4310 That would take quite a few POKES, although it should be within Richard's ten-POKE limit: four to shift the items individually, three to move the fire cells (room cell attributes are grouped in blocks of four per byte) and three to rearrange the water cells near the bottom (ditto). EDIT: Let's see, these should do it: POKE 42421, 30 POKE 42422, 24 POKE 42423, 27 POKE 42424, 21 POKE 60229, 195 POKE 60230, 12 POKE 60231, 48 POKE 60269, 4 POKE 60270, 16 POKE 60285, 1

Richard, I notice you've picked up the point about the Nightmare Room conveyor having its attribute and graphic data placed incorrectly in the code. The solution to which is to shift bytes 56780-56788 forward by one byte to 56781-56789. However, perhaps you could also make the point that if the byte that 'falls off the end' (from 56789) is rotated back to occupy 56780, then it also fixes the visual appearance of the ramp cells (filling in the 'air gap' at bottom of the ramp)?

In the original set-up, each note in the tune is played twice, but because the tune begins at a 'Music Note Index' value of 1, rather than Zero, the first note is heard at the very beginning, but for only half the duration - if you see what I mean? i.e. one instance of the first note at #865F, followed by two instances of the second note at #8660, two instances of the third note at #8661, etc. [Once the tune rendition has finished, the first note will play twice as the tune wraps round, so this 'glitch' will only affect the very start of the game.] However, if you've changed the code (as previously discussed) so that the tune plays at double the normal speed (i.e. the first note of the game is played when the Music Note Index is at a value of 1, the second note when the Music Note Index is at 2, etc), then I think the first actual note in the code ('Note Zero' as it were; the note represented by byte #865F) will be missed out entirely at the start of the game - unless you've initialised the Music Note Index to FF (in which case the M.N.I. is incremented by #8B43 to a value of 00 prior to a note being played). I hope that makes sense?

I believe that everything from #840C to #841E is redundant code.

Something's just occurred to me - because of the INC A instruction at #8B43, the first note of the in-game tune may be skipped at the very start of the game. This is something I've often wondered about, but I wasn't sure if it was my ears deceiving me! To prevent it from occurring, the Music Note Index at #85E1 could be initialised to FF instead of 00. Then on the first pass through the Main Loop, it will be incremented to zero, so the first note of the tune (or should we call it the '0th note'?) will be selected in the first instance.

Following on from my previous post, see the attached test file. There is one item in the game to collect (Bathroom tap). If you leave the tap, walk left to Top Landing and lose some lives by hitting the Swiss Army Knife, you'll notice that the tune pitch deterioration appears to be disabled. But if you collect the tap, then proceed to the Master Bed, then let Willy run to the toilet, you'll notice that at each stage (change of Game Mode), the pitch deteriorates! The command at #8B51 which loads up the number of lives remaining from #85CC to the A register, is instead picking up the Game Mode Indicator (#85DF). I've also removed the SUB and NEG commands, and added a couple more RLCA instructions (four in total now), as suggested in the previous post. Fewer RLCA's will yield a more subtle deterioration of the tune. If you wanted a more extreme deterioration, add more RLCA's. (EDIT: Actually, on that latter point, to be more byte-efficient I believe you could replace the RLCA's with RRCA's and have fewer than four. i.e. rotate the bits of A along in the opposite direction. 3xRRCA achieves the same thing as 5xRLCA, 2xRRCA is equivalent to 6xRLCA, etc.) pitchbygamemode.z80

I like the Cross Item you came up with, keeping the item near its original location. :)

It's a long-standing problem. Even the 'official' POKE released by Software Projects was a bit of a fudge, I think.

I've come up with the attached alternative layout for Conservatory Roof. It keeps the Fire cells and Items all paired up, retains four of each in more or less the original location to the original (under the 'glass roof), and all four Items can be collected without loss of life. (One requires a 'standing jump' on the Conveyor to avoid hitting a Fire cell.) I've also checked that there is no 'short-cut' enabled by jumping through the ramp, which would otherwise mean the player could avoid having to climb the Banyan Tree. Finally, Willy can drop down to The Orangery safely to either side of the lowest Water cell, without entering into an IDS. To be implemented in the Bug Fix 2016/17 Edition perhaps? (when we assemble all the other bug fixes that we've come up with over the last six months) The visual appearance of the Conservatory Roof Conveyor could also do with improvement, but I think layout-wise I've nailed it, in terms of being as true as possible to Matt Smith's original vision! Only 32 years after the game's release, as well!

I spotted the Earth cells 'behind' the conveyor in Esmeralda as I was studying the raw data for the room layout in the disassembly! (Whilst trying to figure out a POKE to add an extra Earth cell below the conveyor.)

Curiously, the order in which ramp and conveyor attributes are laid out is the opposite to the way in which their pixel patterns are drawn, meaning that if a ramp intersects a conveyor, the cell where they cross has the same pixel pattern (with animation) as the conveyor, but the colour-attribute of the ramp (and so the same underfoot behaviour as a ramp). EDIT: The above refers to what you see 'in-game'. In JSWED, the ramp pixel pattern (unanimated) is drawn, rather than the conveyor pixels. (Sorry Richard, I think I've veered off-topic!)

P.P.S. Another thought that was sparked by the previous one: The cells in Rescue Esmerelda containing ramps have byte value suggesting they are occupied by Water cells. Which of course, they are. This screen and others (most notably Out on a Limb) have multiple Water-Ramps, achieved by matching the attributes for Water and Ramp cells. This is something that the JSW disassembly doesn't mention. There is an entry covering Conveyor-Ramps aka Escalators (e.g. The Chapel - see 'Slippery Slopes' in the Trivia section), but no mention of the Water-Ramps as far as I am aware?

P.S. When coming up with the above POKE I noticed that, based on the value of the bytes for the appropriate point on the screen, the conveyor in Rescue Esmeralda seems to be overlaying Earth cells (i.e. 52774 has a value of 170, or 10101010 in binary,not just zero as is the case for most conveyors). So presumably Willy can't jump up through that conveyor - perhaps this gives the player a bit of protection against accidentally 'overshooting' and hitting Esmeralda when trying to collect the 'gate' items? I'd never noticed this before! (the conveyor pixel pattern and colour overrides the Earth cell graphics, so they aren't visible). Matthew Smith's original game can still throw up a few surprises!! Scrap that, the routine at 36203 is ordered such that conveyor attributes (and then ramp attributes) overwrite all the attributes that were previously laid out on the screen buffer, so Willy can jump through the conveyor in Rescue Esmeralda! (i.e. it doesn't display Earth cell-like properties, despite the above).

I think the fact that Willy can walk DOWN a ramp into an Earth cell (as in On Top of the House in the original game) is worth a mention in the JSW disassembly. It happens because the routine that checks for Earth blocks when he's trying to walk across a cell boundary, doesn't check for Earth blocks lying two cells below the top of his sprite when he is only occupying two cell-rows (see 36901 / 37012). Which is obviously a good thing when he's standing on two Earth cells (otherwise he wouldn't be able to walk along Earth platforms at all!), but it means that when he's got an Earth cell and a Ramp cell beneath him, the Ramp cell takes precedence when he's walking down. Also perhaps the fact that Willy can walk UP a ramp through an Earth cell above him is worth a mention (because there is no effective check for Earth cells above him, unless he's jumping). I can't think of an actual example of this in the original game, but whilst we're 'on top of the house', if you pop next door into Rescue Esmeralda, a single POKE will illustrate the point nicely. Simply take the single Earth block that sits under the conveyor and extend it downwards by one cell (POKE 52790, 8). Of course, this would make walking up the ramp in Rescue Esmeralda a one-way route, were it not for the 'Don't Mind Your Head' bug allowing Willy to walk back down the ramp, during which manoeuvre the same Earth block is at head-height on his left!

Ignore that statement in bold, I was having a senior moment - of course, he can drop through the crumbly platform on the left and jump up through the conveyor to access it from beneath! Thus he can make the item disappear and complete the screen!

As I said, I haven't tried it myself, I just have a memory of reading it somewhere (which doesn't in itself mean that it's true!) It's easily checked, especially with that POKE - which incidentally, will set the Screen Flash off (and increment the lives) every time an item is collected! N.B. Care might be needed in case the remaining lives display runs off the edge of the screen and causes corruption elsewhere? Anyway, even if the points are allocated, I still think the fact that the item doesn't disappear from the display is worthy of shifting to the Bugs section, and a POKE provided to shift it one cell lower.

I believe it should be possible to modify the code at #8B51-8B5B, such that the pitch of the tune doesn't deteriorate with loss of lives, but instead based on the value of the Game Mode Indicator at #85DF. The idea being that the tune reflects the fact that Willy gets more 'sick' the closer he gets to the toilet dash!! The SUB and NEG commands at #8B56-8B59 would not be necessary (unless you wanted the pitch to increase through the Game Modes), as the adjustment would be made based on a variable which increments throughout the game, whereas the number of lives of course decrements. However, I anticipate that one or two extra RLCA commands (on top of the existing two) could be useful to give the decrementation of the tune pitch a wider 'range' (given that the Game Mode Indicator only ever reaches a value of '3'). e.g. one extra RLCA (three in total) would mean that each Game Mode increment would yield a drop in pitch, equivalent to that which occurs when Willy loses two lives in original JSW. But since the SUB and NEG commands use two bytes each, whereas each RLCA only uses one byte, there should be a net saving in bytes from modifying the code in this way. P.S. This would also mean that the pitch deterioration would still be showcased in a walkthrough recording, even if the player had used 'rollback' to avoid apparently losing lives!

Good work, Richard! I have a couple of other suggestions for the next update (on top of the 'disrespectful Monk in The Chapel, which I mentioned in the previous thread): In the unused code section of the JSW disassembly: http://skoolkid.github.io/jetsetwilly/maps/unused.html You could also mention the unused Screen Flash routine, which is embedded in the Main Loop (1), but always jumped (unless you POKE the value of the Screen Flash Counter at #85CD to a non-zero value). It's a relic from Manic Miner, where it kicks in every time Willy gains 10000 points, I believe. And talking of points gained in Manic Miner, there's an entry in the Trivia section of the MM disassembly here: http://skoolkid.github.io/manicminer/reference/facts.html#thePersistentItem "The item below the portal in The Sixteenth Cavern does not disappear if Willy leaves it till last and collects it by falling on it from above. The reason for this is that the portal is opened as soon as Willy collects the item, and the screen is not refreshed before he moves on to the next cavern." Of course, he has to leave that item till last in order to be able to complete the screen! But that's not my substantive point... I think I read somewhere that, not only does the item not disappear when he collects it, but he doesn't acquire the usual 100 points from doing so! i.e. as soon as Willy enters the portal, the game moves on to count down the remaining air - which in itself updates the points count - but it bypasses the code that assigns 100 points per item collected. That probably isn't readily apparent noticeable when there's a lot of air left, and so the score goes up substantially anyway, but one way to check would be to complete the rest of the screen, then wait above the portal until the air has nearly expired, before dropping into the portal at the last minute. I should point out that I haven't actually checked this myself yet! But if indeed Willy can't acquire points from collecting this item (unless he collects it 'too early' which then means he's stuck, and has to sacrifice a life and start the screen again), then I think it should be classed as a 'Bug' rather than a 'Trivia' entry. Furthermore, it should be quite easy to fix by providing a single POKE to shift the item downwards by one cell-row. Then Willy will only collect it after he's dropped sufficiently far through the portal so as not to activate it straight away. Upon landing he will get the 100 points, the item will disappear and the portal will start flashing. Then he can simply back jump up into the portal and head on to the next cavern!

I've just noticed that Richard has made quite a few updates to his Jet Set Willy disassembly, and also to his Manic Miner one. Thanks for the credits, Richard - and also for the handy hint regarding the Solar Power Generator in MM! One thing I just thought of for the next update - you mentioned that the Saw in Cuckoo's Nest only uses four of the eight available frames of animation. However, there's also the 'disrespectful Monk' in The Chapel, who always faces away from the altar!