IRF

I suppose it's more in keeping with the original game design, even if the time constraint is extremely relaxed!

Here - try changing the Air INK colour to white in Solar Power Generator and see what happens (apart from all the items getting auto-collected). Poor Willy - heh heh! :lol:

Straight vrom ze horses mouth: http://www.jdawiseman.com/papers/games/jsw2/jsw2_programmer_comments.html#Derrick_Rowson_20130810 "a pseudo german influence"

Are you referring to 'Drinking Vater'? I always assumed that was a deliberate play on words (adopting a 'cod-German accent'), rather than an accidental typo?

I've had an idea which might facilitate the above; I'll do a bit of experimentation when I can find the time...

Yes - I've come up with a fix which stops Willy from walking leftwards through an Earth cell at head-height, yet which still allows him to jump leftwards through an Earth cell at head-height (thus retaining some quirky manoeuvres, and also my patch doesn't prevent Willy from completing The Wine Cellar as the simple fix does). As a bonus, I've also enabled the same quirky features whilst jumping (but not walking) rightwards.

Random observation: if you design a game such that Willy has no spare lives at the start of each game, then POKE 35899, 0 won't protect him!!

There are two ways around that: (1) Simply replace the Earth cell in question with a Water cell; that would arguably be more in keeping with the aesthetics of the room than is the Earth cell (i.e. there are other instances of Water cells adjacent to the side walls of the room, whereas there is only a single random example of an Earth cell that protrudes beyond the perimeter walls/ceiling/floor); (2) Rely on the player being able to perform a well-timed jump through the Earth block as per the attached .rzx recording. You only get one shot at it though; if you don't make a pixel-perfect jump then the conveyor stops you going back to try again, and you'd have to wait for the green Monk to come along and extinguish a life before Willy is reincarnated at the bottom-left (with the item collected). Dr Andrew Broad's mirror-imaged version of JSW ("ylliW teS teJ") requires the player to make this very manoeuvre (either that or sacrifice a life). However, I don't think that it's something which you should expect the average player of the original JSW to be able to pull off, and so I would go for option (1) above. ****** Incidentally, after I performed the quirky jump in the recording, observe the way in which I got Willy to jump into the wall at the bottom-left via another quirky jump. (The fix only stops Willy from walking through an Earth cell at head height, but he can still jump through them!) However, you should also notice that he can't progress beyond a depth of one Earth cell into the wall, because of the implementation of the fix. Whereas in the original JSW, without the head-height Earth cell fix in place, after performing the same manoeuvre it is possible for Willy to carry on walking through the wall - emerging at the bottom-right of The Wine Cellar (where, if you don't keep walking, he gets stuck on the conveyor in that room, and you have to abandon the game!) Earth cell in Forgotten Abbey.rzx

I think I should correct myself there - that doesn't sound right! If a cell's value in the attribute buffer is set to match the current room's Ramp attribute byte, then the pixel pattern for Ramp should also be drawn to the corresponding address in the screen buffer - at least initially. However, in subsequent time-frames, the first and third graphic bytes of the cell where the Ramp and Conveyor intersect, will be overwritten by the first and third pixel-row of the Conveyor's cell-graphic, due to the application of the 'Move the Conveyor' routine. Therefore the cell will take on a 'hybrid' appearance, assuming the Conveyor pattern in the first and third pixel-rows, but retaining the Ramp pattern in the second, and the fourth to eighth pixel-rows. The exception would be if the Ramp intersected at the leftmost cell of the Conveyor, in which case the entire Ramp should be visually unaffected (apart from displaying animation in the pertinent Ramp cell), but the first and third graphic byte of the Ramp will overwrite the first and third pixel-rows along the entire length of the Conveyor! (With all other pixel-rows of the Conveyor being unaffected.) That's because the 'Move the Conveyor' routine picks up the appropriate graphics from the cell at the pre-defined left-hand end of the Conveyor (even if that cell has since been overwritten, because Ramp attributes are distributed across the attribute buffer after Conveyor attributes), and then the routine copies those rotated graphic bytes rightwards across the rest of the predefined Conveyor length.

I never thought of those possibilities - good thinking!

Two bytes (#8EB4-5) can be freed up in the 'Move Willy(1)' routine by inserting a relative jump forward by four bytes at #8EB2 (destination #8EB8). Replace four bytes at #8D67-8D6A with three bytes: RET Z JR #8D4D EDIT: That's no more efficient in terms of total bytes used than replacing the absolute JP with a relative JR (an alternative which doesn't require the RET to be moved). Replace the LD A, (HL) at #943E with LD A, D and then NOP out #943F (frees up one byte). (Credit goes to J G Harston for that one.)

I don't think this has been explicitly mentioned on Andrew Broad's list of quirky features, or in his Advanced JSW/MM Trainer documentation... In JSW, Willy cannot gain access to*, by jumping**, a platform that is located in cell-row 2 of a room. This is because whenever he jumps, he is raised up by two and a half cell-rows, so either he doesn't achieve a sufficient height if he jumps from a platform in cell-row 5, or else he breaches the top of the room and moves up into the next room if he jumps from a platform in cell-row 4. (*In order to be able to stand on it. **Of course, he can access such a platform by walking up a Ramp or climbing up a Rope, or dropping down onto it from the room above.) This could give rise to interesting Promised Land/Forbidden Holy Ground effects. e.g. if such a platform leads to an otherwise-inaccessible sideways exit from the top corner of a room, and the room above has a solid floor (so there's no possibility of falling down onto the high-level platform). However, it might be possible to access such a platform if the Superjump feature could be properly configured (over and above the fix which John Elliott devised to stop Willy from falling through floors once he has reached the natural end of his jump cycle, but which still allows him to fall through standonable cells during the early part of his descent from the apex of his jump).

The split screen colour effect is weird, it's not even half and half (eight rows black, eight rows not) but 5 and 11.

Some other minor things that we 'fixed' in TNE - the capitalisation and centralisation of some of the room names. Some of them seemed to have been a bit of a rushed job in the original JSW release (e.g. "A bit of tree" instead of "A Bit of Tree") We also moved the room names down a row on the status bar, which looks tidier. Arguably, the current room name should disappear before the Game Over screen is drawn too.

We doubled the speed of the digital clock in The Nightmare Edition, it's quite easy once you know how. Answer below, with a spoiler box inserted in case you want to try and figure it out for yourself: :)

One other minor bug (not documented by SkoolKid) - the very first note of the in-game tune is missed out at the start of the game. The program keeps track of where it's up to with the tune, via the Music Note Index (#85E1), which is incremented during every pass through the Main Loop (see #8B43). However, #85E1 is incremented before its value is used to determine which note to play, so the first note is missed out until one rendition of the whole tune has been played. The value of #85E1 is initialised to '00' at #87CE. If it is initialised to 'FF' instead, then the first note of the tune is picked up at the beginning of each game.

Actually this is my final suggestion. I've scoured both the 'Bugs' and 'Trivia' lists in SkoolKid's disassembly and there is one more thing for which POKES are readily available - the 'Maria's dodgy depth perception': http://skoolkid.github.io/jetsetwilly/reference/facts.html#mariasDodgyDepthPerception Let us know if that's something you would like to fix, and I'll dig out the POKES (for which the credit goes to Stuart Brady of FUSE).

Final suggestion for tonight: are you editing the game in John Elliott's JSWED? If so, I strongly recommend that you implement the Adjacent Ropes (New) patch (just tick the box on the Menu screen when you first open the file in JSWED, and save). It fixes this bug: http://skoolkid.github.io/jetsetwilly/reference/facts.html#theEncroachingRope

Oh, and have you implemented the POKES that fix this? http://skoolkid.github.io/jetsetwilly/reference/facts.html#asYouWere It's quite simple, just reset the values of #85D0 and #85D2 to zero during the course of the 'Display the title screen' routine, along with all the other variables that are initialised at the start of that routine. Then Willy will always be sitting at the back of the bath facing the tap at the start of every game, no matter what his stance was when the previous game ended! In fact, it can be done without calling up code from elsewhere, if you slot the commands in in place of the ones that reset the unused Screen Flash Counter and the Inactivity Timer (assuming that you've deactivated the Auto Pause function and the Screen Flash routine remains unused). I.e. insert 'D0' at #87D2 and 'D2' at #87DB.

One other thing which I've picked up, looking at that list of bugs. SkoolKid's fix for the conveyor and the ramp in The Nightmare Room rotates all eight graphic bytes for the conveyor downwards by one byte, and replaces the conveyor attribute byte with the final graphic byte of the ramp cells. Then rotates the byte that falls off the end of the conveyor graphic definition to fill in the gap at the bottom of the ramp cells. However, I came up with a slightly alternative version, where only the first four conveyor graphic bytes are moved along, the bottom four pixel-rows of the conveyor are unchanged, and the fourth pixel-row's byte (as set out in the original game code) is used to fill in the base of the ramp. The conveyor cell is almost identical in both variants (the only difference being in the fifth pixel-row), but I think that the ramp looks better in the version that I came up with. Have a look at the attached screenshot which I created (based on The Nightmare Edition, but it allows a useful comparison), and the images from the disassembly (as copied and pasted below), and see what you think? Very corrupted conveyor You might be thinking that the fix given above for the corrupted conveyors bug does not do much for the appearance of the conveyor in The Nightmare Room. Perhaps that's because the real problem with this conveyor is that its attribute byte and graphic data - which should occupy addresses DDCD-DDD5 - appear to have been shifted by one byte back to DDCC-DDD4 (overwriting the eighth graphic byte of the ramp tile). If they are shifted along to the right spot, the conveyor takes on a much more reasonable appearance: http://skoolkid.github.io/jetsetwilly/images/scr/conveyor29_before.gif http://skoolkid.github.io/jetsetwilly/images/scr/conveyor29_after2.gif Before After In addition, if the byte at DDD5 (0x55) is shifted back round to DDCC it seems to fix the appearance of the ramp tile (by filling the gap at the bottom): http://skoolkid.github.io/jetsetwilly/images/scr/ramp29_before.png http://skoolkid.github.io/jetsetwilly/images/scr/ramp29_after.png Before After

I think that Matt Smith got the operand of a COMPARE operation out by one byte, and if a certain value is picked up then the routine is sent slightly out of range. The codes are stored at #9E00 to #9EB2, but a SUBTRACT command overshoots and points the routine at the address #9EFF (i.e. it points one byte below #9E00, but the low byte wraps around whilst the high byte still holds the value #9E.)

The same POKE fixes both bugs. i.e. instead of picking up an invalid address, the same value of the system variable that generates a random grid location will point to R9. At least, that's my understanding. (Although I haven't yet got my head around exactly how the routine generates a random number?)

Oh go on, you might as well fix it for completeness, using POKE 34556,180. Especially since the same POKE also prevents the invalid grid location from being called, as I referred to above!

You may as well insert the POKE that fixes the 'invalid grid location', even if you've hacked the code entry routine so that any code will do. It's only one POKE: http://skoolkid.github.io/jetsetwilly/reference/bugs.html#invalidGridLocation