IRF

"Willy Comes Home" is the only JSW game gamma-released (so far! 😉) by Gary Pearce (Gawp!). 
It holds the distinction of being the first 'properly-edited' game using the JSW128 game engine. This is because "Jet Set Willy 128", the very first game ever released in this category, mostly served as a demonstration of the engine's features, with the majority of its rooms sourced from the original "JSW" and Richard Hallas's "Join the Jet-Set!". In fact, Gary began his editing work with "Jet Set Willy 128", and the block designs in many rooms clearly reveal their origins in one of its source games. He used sprites from the original "JSW", "MM" and "Join the Jet-Set!", and also created some new ones. The game boasts a large map that can be explored with relative ease. It uses Hacklevel 6 of the JSW128 game engine.
The game was released in March 2000, with a corrected version 1.1 following in April of the same year. However, despite the update, v. 1.1 was still incompletable due to a critical bug in the room "Harbour Hangover" (083): it was impossible to collect the rightmost item because of a Fire cell that prevented it.
There are also two additional problems in v. 1.1 of the game which would render the game bed-completable only even with this issue corrected. The first problem involves a hole in the floor of "Bathroom (with purple bath)" (033) - Willy would fall into it during the toilet run, descending through "The Chapel" (027) and repeatedly getting killed in "Ballroom West" (021), resulting in a very anticlimactic ending. The second one is that even with the hole problem fixed, upon reaching the toilet, Willy would get teleported to "A flash in the Pan" (201), since there is a teleporter, necessary for gameplay progression, that shares its location with the toilet. This ending does not seem correct, as the game file contains an edited sprite of Willy inside the toilet, suggesting that the game's author intended it for the traditional ending.
In June 2007, Robin Clive submitted a recording of "Willy Comes Home" to the RZX Archive. The recording was made using a modified game file, with the Harbour item problem fixed by removing the obstructing Fire cell and the Bathroom problem fixed by filling in the hole in the floor. However, Robin did not address the third problem described earlier and, as a result, at the end of the toilet run his playthrough ends in "A flash in the Pan" without reaching a proper conclusion. Robin never released his modified game file (however, an RZX recording can be used to play the game it was made from).
I recently tried to complete the game and discovered the problems discussed earlier. I also prepared a bugfixed, toilet-completable version of the game. The "Harbour Hangover" item problem was solved by adding a platform from which Willy can jump for the item in question (the original obstructing Fire cell remains in its place). The Bathroom hole problem was solved by adding some extra code that makes Willy jump during the toilet run (so that the original design of this room has not been modified), and the issue of teleportation near the toilet was resolved by adjusting the code to check for Willy's proximity to the toilet earlier.
The bugfixed version can be downloaded from the recently updated game's page on JSW Central. I am also attaching it here for your convenience should anyone be interested in obtaining it.
It can be completed without any loss of life. I have been able to complete it (in my third recording 😉) at 8:57 am in-game time, and I have to say I was very proud of making it in under two hours. My RZX walkthrough can be downloaded from the game's page on JSW Central. You can also watch a video of it on the JSW Central channel on YouTube.
I would like to encourage everyone to play the game. It is easy (especially when you play saving and reloading snapshots or using Rollback) and fun to explore. I'm sure you will enjoy it! 🙂 
Willy_Comes_Home_(bugfixed_version).zip

A few weeks ago Richard Hallas brought to my attention a JSW remake that was missing from the lists of games on JSW Central. It is called "Jet Set II" and it was created by Stewart Fordyce (Wizard Software) back in 1985.
I believe this remake remained obscure until October 2022, when it was added to ZXDB and posted on Spectrum Computing by R-Tape. In fact, Richard had spotted it on SC before he let me know about it.
"Jet Set II" has the same layout as the original JSW. Several rooms are completely modified - most notably, "THE FURNACE" (10) replaces "The Front Door", "JUMP IN THE MOTOR" (40) substitutes for "Dr Jones will never believe this", "Space   Invaders" (55) replaces "West Bedroom" and "Above the West Bedroom" (57) bears no resemblance to its original version despite sharing the same name. While most rooms have been altered to varying degrees, some remain unchanged, such as "On the Roof" [18] and "Master Bedroom" [35], the latter now named "GET OUT YOU CREAP".
Guardian paths and item locations remain unaltered, although some guardian sprites have been modified. The title-screen and in-game music are the same as in the original JSW, while the scrolling title message has been edited.
The player is instructed to "guide Willy around his brand new house", to "collect the objects to get some money in the bank" and then to "get to bed before 12:00 am".
I have now fully 'processed' the game (as per my standards). I played it to as near to completion as was possible, identified critical errors, created a bug-fixed version, played it to completion and RZX-recorded it, created a video of my walkthrough for the JSW Central YouTube channel and added the game to the list of games on JSW Central, creating an individual page for it, along with a complete screenshot gallery and download options.
The game's JSW Central page is here, and the YouTube video of my walkthrough is here.
The game as created by Stewart Fordyce was impossible to complete due to a critical bug in the room "Under the Drive" (45). It was impossible to jump over the magenta guardian after entering the room at the upper right, which resulted in Willy's repeated deaths. Since this is the only way out after passing through "Tree Root" (46), where two items need to be collected, this bug effectively made it impossible to collect these items and continue the gameplay, rendering the game incompletable.
An additional problem was that even with this issue corrected, the game would still only be bed-completable, as the wall in the middle of the Bathroom would prevent Willy from finalising the toilet run.
I fixed the "Under the Drive" problem by removing one Earth cell, which prevented Willy from making the same kind of jump over the guardian as in the original "Jet Set Willy". I also solved the Bathroom problem by adding some extra code which allows Willy to pass through the wall during the toilet run. The bug-fixed version can be downloaded from the game's JSW Central page. I was able to complete it, with the loss of one life, at 7:56 in-game time (just like in the original JSW, a life has to be sacrificed to collect the leftmost item in "Conservatory Roof" [43]).
All in all, I would definitely not call "Jet Set II" a quality release by today's standards. I even wondered whether to include it in the "New games" category or rather the "Advanced modifications of the original JSW" section. Finally, I opted for the former. I do think "Jet Set II" has historical value, going all the way back to the "real hardware" era. And, if someone wants to spend an hour or two roaming around Willy's somewhat modified mansion - it's always a pleasure, and it's free, too 🙂 .
If anyone has any more info about Stewart Fordyce or the game itself, please let me know about it (here or by e-mail) and I will be happy to update the information on JSW Central.

I concur - Top hats (or mining helmets) off to Andy!

Yes, both top hats AND mining helmets!!! 😄

I concur - Top hats (or mining helmets) off to Andy!

A big THANKS and hats off to Andy (Spider) for fixing the site! He did it all by himself, both providing the upgraded software and performing the update. It feels good to be back. Thanks again, Andy! 👍 🙏  👏 🍾

By comparing Willy's sprite data with the attribute byte values assigned to the various block types in the cavern data, I've discovered a few effects that I think will arise within the Manic Miner game engine.
 
If you have more than 34 remaining lives and if the spare lives on the status bar are set to their rightmost frame of animation.  Willy's back foot in that frame has a byte value of #03, which matches a couple of magenta INK on black PAPER blocks in the game:
- In 'Abandoned Uranium Workings', some of the errant blocks (in 'even' columns) across the middle of the cavern will act as conveyor cells (no animation, but they will drag Willy rightwards).  This effect could be quite erratic if the in-game music is left on, meaning that the spare lives pass through that animation frame and the conveyor effect periodically stops and starts.  This should affect the new platform directly underneath the cavern's sole crumbly platform - that is in fact the very same new platform which led @DigitalDuck to improve his score here, which gave rise to this discussion!  N.B. No POKE is needed to observe this effect - just set the remaining lives to the appropriate frame;
- In 'Return of the Alien Kong Beast', the mid-height Water cell platform patrolled by the right-most 'rolling rock' guardian will, in theory, become crumbly.  Unfortunately, Willy can't access that part of the cavern to stand on that platform and cause its pixels to crumble away, because of the aforementioned blockage on the left-hand side of the cavern (as pointed out by DigitalDuck).  There is a single-cell platform occupying the same character row towards the left of the cavern (just below/to the right of the leftmost banana item), which is reachable during game play, but unfortunately that block sits in an 'odd' column, so the overwritten attribute (corresponding to a different part of Willy's sprite) doesn't match the crumbly cell attribute, and so no crumbling of pixels will occur if Willy stands on it even if it has been corrupted by a rogue attribute.  However, if that platform were extended by one more block (either left or right will do the trick), then the new extension to that platform would crumble when stood upon: POKE #DD02,#43 or POKE #DD04,#43 (in decimal: POKE 56578,67 or POKE 56580,67) - apply before entering the cavern.
 
Meanwhile, if you have 36 or more remaining lives and if the spare lives on the status bar are set to either their second or third frame of animation, then I believe the attribute value #06 (corresponding to the next pixel-row up in Willy's sprite) will be written across alternate cells of the top character row of the caverns.  This could also have gameplay consequences:
- The value #06 is assigned in 'The Menagerie' to an (unused) Fire cell type (the yellow bush that is encountered in other caverns), so as the number of extra lives continue to tally up, the top three items will be either embedded in or sandwiched between Fire cells, making them uncollectable without being killed (unless you move the animation of the remaining lives on to the first or last frame);
- Similarly, 'Processing Plant' would be incompletable once the errant Fire blocks reach across to the portal (and probably before that - I don't think it's safe to drop down from the starting point in the cavern without first making a jump that means Willy's head passes through the top character row);
- And the route options in 'The Warehouse' would be more restricted (for instance, you couldn't jump over the first Fire cell to Willy's right upon entering the cavern, without hitting one of the newly-created overhead Fire cells).
 
P.S. Whilst researching this post, I discovered for the first time that Matthew's original design for 'The Sixteenth Cavern' may have incorporated a switch!? (The switch graphic from the Kong caverns is present, unused, in the 16th cavern data.)

Just for fun: if you collect the bottom item in Skylab Landing Bay while you're on 33 lives and *99xx points, you're killed by the extra life you're awarded for collecting the item.
MM-extralife_VP8.webm

By comparing Willy's sprite data with the attribute byte values assigned to the various block types in the cavern data, I've discovered a few effects that I think will arise within the Manic Miner game engine.
 
If you have more than 34 remaining lives and if the spare lives on the status bar are set to their rightmost frame of animation.  Willy's back foot in that frame has a byte value of #03, which matches a couple of magenta INK on black PAPER blocks in the game:
- In 'Abandoned Uranium Workings', some of the errant blocks (in 'even' columns) across the middle of the cavern will act as conveyor cells (no animation, but they will drag Willy rightwards).  This effect could be quite erratic if the in-game music is left on, meaning that the spare lives pass through that animation frame and the conveyor effect periodically stops and starts.  This should affect the new platform directly underneath the cavern's sole crumbly platform - that is in fact the very same new platform which led @DigitalDuck to improve his score here, which gave rise to this discussion!  N.B. No POKE is needed to observe this effect - just set the remaining lives to the appropriate frame;
- In 'Return of the Alien Kong Beast', the mid-height Water cell platform patrolled by the right-most 'rolling rock' guardian will, in theory, become crumbly.  Unfortunately, Willy can't access that part of the cavern to stand on that platform and cause its pixels to crumble away, because of the aforementioned blockage on the left-hand side of the cavern (as pointed out by DigitalDuck).  There is a single-cell platform occupying the same character row towards the left of the cavern (just below/to the right of the leftmost banana item), which is reachable during game play, but unfortunately that block sits in an 'odd' column, so the overwritten attribute (corresponding to a different part of Willy's sprite) doesn't match the crumbly cell attribute, and so no crumbling of pixels will occur if Willy stands on it even if it has been corrupted by a rogue attribute.  However, if that platform were extended by one more block (either left or right will do the trick), then the new extension to that platform would crumble when stood upon: POKE #DD02,#43 or POKE #DD04,#43 (in decimal: POKE 56578,67 or POKE 56580,67) - apply before entering the cavern.
 
Meanwhile, if you have 36 or more remaining lives and if the spare lives on the status bar are set to either their second or third frame of animation, then I believe the attribute value #06 (corresponding to the next pixel-row up in Willy's sprite) will be written across alternate cells of the top character row of the caverns.  This could also have gameplay consequences:
- The value #06 is assigned in 'The Menagerie' to an (unused) Fire cell type (the yellow bush that is encountered in other caverns), so as the number of extra lives continue to tally up, the top three items will be either embedded in or sandwiched between Fire cells, making them uncollectable without being killed (unless you move the animation of the remaining lives on to the first or last frame);
- Similarly, 'Processing Plant' would be incompletable once the errant Fire blocks reach across to the portal (and probably before that - I don't think it's safe to drop down from the starting point in the cavern without first making a jump that means Willy's head passes through the top character row);
- And the route options in 'The Warehouse' would be more restricted (for instance, you couldn't jump over the first Fire cell to Willy's right upon entering the cavern, without hitting one of the newly-created overhead Fire cells).
 
P.S. Whilst researching this post, I discovered for the first time that Matthew's original design for 'The Sixteenth Cavern' may have incorporated a switch!? (The switch graphic from the Kong caverns is present, unused, in the 16th cavern data.)

Thank you for your thoughts. I believe the answer is 'no' to both questions.
I've checked the rooms in question in JSWED, changing the attributes of all cells to certain default colours I always use for these occasions (blue on blue for Earth, green on green for Water, etc.), which rules out any hidden platforms.
I also checked the guardians. I believe there are no switches in the game. I am pretty sure there aren't any custom code modifications, either - my understanding is that the game was designed using JSWED's GUI without any 'fancy' stuff.

I just tried the above experiment. (The idea behind it being to match the crumbly attribute in Eugene's Lair to one of the bit maps for a part of Willy's sprite.) 
When Willy stands on the corrupted conveyor, the conveyor's pixels start to crumble downwards whilst they're also animating rightwards! It's more interesting if you proceed along the conveyor from right to left, rather than vice versa. (So the pixels keep on coming from the left, otherwise they all disappear quite quickly.)
Also, try leaving the music on with the spare lives dancing - the errant blocks change colour in time with the music, and if Willy is standing on the right hand end of the conveyor, then the downwards crumbly-conveyor animation keeps stopping and starting depending on the animation frame of the spare lives!
(A couple of other observations: the conveyor no longer drags Willy along, even though it is still animated to look like it should. And the ever head stalactite is no longer lethal to Willy.)

I suppose there is an ecological analogy to be drawn - overpopulation of some species (not generally turtles though!) can be damaging to the ecosystem once natural predators of those species are eliminated from a habitat.

"Terry The Turtle" is the game to try it "the natural way", i.e. without any POKEs.
You start out with 7 lives which are visible on the screen. As you gain extra lives, 4 more become visible as little turtles on the screen, just like the original 7. The next 3 extra lives are not marked in any visible way, and then with the 15th life the leftmost little turtle at the bottom of the screen, symbolising a life, starts to flicker. Then, with the following extra lives, the next turtles at the bottom of the screen start to flicker. When the number of lives exceeds 28, it affects the display of the room names (the letters disappear starting with the leftmost one; the effect is irreversible - even if the number of your lives goes down below 28 again, the affected letters in room names in new rooms you enter are not visible). With even more lives the game is slowed down or it can crash or become unplayable in some other way (e.g. because of 'rogue' cells blocking your way).
As the author of the game, Steve Dixon (Jammajup), explains, "if you are good at these types of games and constantly use the emulator save state you can collect so many lives you can slow down or even crash the game!" Indeed, this is a serious problem and in order to eliminate it, while recording the RZX walkthroughs of the four versions of the game (three of which still need to be improved - please see this thread for details), I deliberately killed Terry many times during each walkthrough, so as not to have more than 28 lives at any point in the game. The elimination of the excessive number of lives had to take place, much as I dislike serial suicides 😉 . However, if someone is interested, you could experiment with the extra lives and the effects their excess produces.
 

Sendy's "Manic Person" has the stack address changed (in both versions). It uses the spare bytes related to unused guardian data at #FAF3 - #FAFF. To be precise, the instruction at #8401 - #8403 places the stack at #FAFE. So when there's one address on the stack, it occupies the last two bytes of this spare space (i.e. #FAFE and #FAFF). I don't quite understand why it works this way, but then the following addresses are occupied going 'backwards' (i.e. the next occupied pair of addresses will be #FAFC - #FAFD, then #FAFA - #FAFB and so on). 
When working on the 'postproduction' of "Manic Person" (adding some special effects and loads of music), I was a little worried that a stack overwflow could occur, since the available space allocated to the stack is limited. However, after playtesting the game by completing it twice (two sets of caverns), there were still four or six spare bytes in the allocated space (00s, not overwritten by the program). It was actually the same amount as after completing the game for the first time (one set of caverns). So I decided it was safe to leave the stack there, as I couldn't think of any scenario in which it would occupy (overwrite) more space.
The change was done in order to use the space at #934C - #9CFF for other purposes, of course.

It sounds like Invalid Arrows are exactly what you're looking for.

Right, I am going to say it, even if it's wrong - who is going to do this same experiment with JSW? 😉
 
Edit - I have loaded up the original JSW just to see what possibilities there are for this. But it doesn't look like there are any? I know the arrows etc in the original corrupt data, but wondering what could be done to purposefully corrupt it like Duck has done? Not sure it is possible really. The thoughts of creating platforms in some rooms seems good though.
 

Actually, you're right. In Jet Set Willy, the stack starts at the bottom of page #5B of memory (that page was originally designated as a printer buffer for use if your ZX Spectrum is hooked up to a ZX Printer, if I recall correctly? - which is obviously not a consideration when playing games like JSW/MM, so it's a good place to put the stack.)
I had assumed that this was also the case in Manic Miner - that the base of the stack would be placed at #5BFE-5BFF.  And hence at theoretical risk of eventually being overwritten by the bonus lives (if enough of them built up?  The errant blocks would have to be reaching the bottom right of the playing area for that to occur, so other things are likely to have gone catastrophically wrong long before that occurs!)
But apparently it's not even a theoretical consideration, because according to SkoolKid's MM disassembly, the base of the stack is near the end of the remnant source code which starts at #934C.  So the stack builds up from addresses #9CFE-9CFF.
(Incidentally, anyone working on a MM mod and finding a purpose for that available part of memory - #934C-9CFF - would be advised to steer clear of the last few bytes, lest the program overwrite the addresses stored on the stack during flow of execution, or vice versa!) 

Ah, that item you're referring to is in an 'odd' column number, so nothing is printed there for a Willy sprite in its leftmost frame of animation. (Well, technically the value #00 is written there, but that's what was already there anyway as it's an air cell in a room with a black background, so nothing changes in that cell and the item remains collectable. Try setting the dancing lives to a different animation frame and I think you'll find that it's uncollectable.)
Conversely, the auto-collected item in Kong Beast is in an 'even' column, and it's actually one of the spare Willy's front foot which 'collects' it - the byte value for his feet in that position is #77, the first 7 represents his back foot, the second digit is his front foot, and that 7 is interpreted as white INK in the attribute buffer!

When Willy falls off the bottom of a cavern (or jumps up past the top), the corruption happens to the data of certain caverns, so you would have to reload the game file to reset it. (Same with the Attic Bug in JSW.)
The spare lives overspill is happening in the buffers, so it's not permanent. If you lose some lives, then it will start to become undone (the errant blocks will retreat from right to left across the screen.)

Yes, it's both the playing area and the buffer that's overwritten. When drawing a sprite it adds 256 to the memory address to go to the next pixel row, but naturally the screen attributes follow directly after the screen pixels so they're being drawn to. Even in the most extreme scenario lives are only drawn to pages 80-95 (memory addresses 0x5000 to 0x5FFF) which contain the lower third pixel data for the screen, attribute data for the screen, and the attribute buffers. I'm not sure where the stack is stored, but I don't think it's being overwritten here.

So you could envisage a scenario where progress relies on turning the music back on to make a block change from a lethal Fire cell to a 'standonable' floor block! The on/off status of the in-game music being an inherent part of the gameplay would be another novelty!

Absolutely - unfortunately this scenario doesn't seem to exist in the vanilla game, but with the right sprites and colours you could have a situation where it cycles between floor, wall, air, and nasty (or the four elements, water, earth, air, and fire), and require the Willy life sprite to be in a certain state to make the level passable (perhaps even requiring floor at some points, air at others, and wall at yet others, so you have to "edit" the level as you play).

True! It occurred to me just after I posed the question that, whilst perhaps slightly novel, it wouldn't present any additional difficulty to the cavern, because the player would (for a 'standard' Kong-style cavern) have to pass through there anyway.
However, musing on it a bit further, I think I have thought of a possible cunning use for it... I feel another quirky one-cavern puzzle might be in the works...

Not shown in the video because I just wanted to get something out there quickly, but what's actually drawn on the screen depends on the sprite shown for Willy's lives; as I have the music turned off, it's not cycling. The state I have the sprites paused in is the only state in which items are auto-collected. In all cases at least one of the two blocks drawn is a floor block. I suspect the black cells are actually air tiles, hence the item being collectable; these same black tiles are nasties in Skylab Landing Bay.
 
I actually discovered this a while ago with lives POKEs, this was just my first time seeing if it can occur during normal gameplay. You can experiment yourself with POKE 33879,n. After 48 lives, they start being drawn over the level name and air counter instead.
There's a limit to how many lives you can have before each level becomes incompletable (although you can always lose lives until they become completable again). I've split them into three groups:
 
Early blockers:
Central Cavern - at 39 lives, you cannot jump over the robot without landing on the extended platform, which blocks your fall to below. Interestingly, it becomes possible again at exactly 46 lives only, as this allows you to walk to the right and drop down that way (similar to what the GBA/PC version allows you to do), but at 47 lives that way becomes impassable too.
Miner Willy meets the Kong Beast - at 40 lives, there is no way of getting through the opening after pressing the switch to collect the last banana.
Endorian Forest - at 40 lives, the middle trunk and extended platform seal you in the starting section.
Return of the Alien Kong Beast - 40 lives, same as Miner Willy meets the Kong Beast.
Skylab Landing Bay - at 34 lives, the nasties block a mandatory path.
The Final Barrier - at 46 lives, there is no way of getting out of the top-right area after collecting the keys there.
 
Standard blockers:
At 47 lives, the "platform" extends covering the entire play area (minus the last two cells, but one of those is always a wall, and Willy can't fit through a gap of one cell). For The Cold Room, The Menagerie, Eugene's Lair, Processing Plant, and The Warehouse, 47 lives is the point at which they can no longer be completed as the entire screen is blocked and cannot be traversed from top to bottom.
 
No blockers:
These come in two forms: in Abandoned Uranium Workings, Wacky Amoebatrons, The Bank, The Sixteenth Cavern, Amoebatron's Revenge, and Solar Power Generator, you start in the bottom half of the screen and exit at the top. As a result, platforms stretching across the screen don't inhibit progress at all. You do normally need to revisit the bottom half of the screen in Solar Power Generator, but the platform extends to make that unnecessary long before it's made impossible.
The second form is in The Vat, Attack of the Mutant Telephones, and Ore Refinery. While all three of these levels require going from top to bottom to top (or bottom to top to bottom in the case of Ore Refinery), they also have platforms very near to the top of the screen, requiring wall tiles to prevent you from jumping outside of the screen boundaries. These wall tiles are replaced with floor tiles, allowing you to jump through the screen vertically and access the other half of the screen.
All of these levels can be completed regardless of the number of lives you have.
 
Whether it should be allowed or not is already contentious enough with what I've already shown - I think we can safely say that if cheats are required then it definitely shouldn't count, so anything with extensive corruption is out. I believe this also means that the maximum attainable life count in the game is 38 (Skylabs limiting to 34 plus four extra lives attainable in one loop).

I don't recall anything like this.
However, functionally this wouldn't be different from what usually happens - if the wall that collapses after the first switch is tripped blocks access to a part of the room where some items are, these items are only collectable after the first switch has been tripped (because prior to that they are unreachable).