IRF

You're quite right! However, I was talking in the context of having recently been exploring your game Manic Jet Set Willy, not with a view to completing the game, but just checking out all the individual rooms. It did help me to access Under the Drive in that context - after the Forgotten Abbey I had dropped down into Entrance to Hades out of curiosity, then after dropping through the new, empty room below that, I ended up at the top of Security Guard. Rather than go all the way round again, I used the shortcut of falling through one of the guards to resume my subterranean journey. Incidentally, is there an invisible item in the empty room above Rescue Esmerelda in MJSW? (Or possibly visible in theory, but you never see it because Willy collects it immediately upon entry in the one place above Esmerelda where the room can be entered?)

The most glaring example of that is that it is MUCH easier to access 'Under the Drive' / 'Tree Root' thanks to the immunity - just drop down through one of the Security Guards (twice, first time will kill you but you can survive the second time if you do it fast enough).

The wording of the txt file explaining the bug fix looks fine to me Danny. 😀

I've noticed the problem you mentioned with the Jump key being 'stuck' before, can't remember which emulator I was using at the time. I've a feeling that resetting the game by pressing SHIFT+SPACE didn't always resolve the issue (though I could be misremembering that)?

Actually, the above isn't quite true. Having looked again at SkoolKid's disassembly, the second test for whether to start the game (during the scrolling message) only tests the ENTER key, not the joystick Fire button. So with a joystick plugged in, the Fire button won't work to start the game, you would have to press ENTER on the keyboard. EDIT: I should clarify that this is the case for any MM or JSW game based on the original game engines - pressing Fire on a Kempston joystick will not start the game whilst the scrolly message is activated, it will only work whilst the title tune is playing. I should also clarify that I'm making this observation based on my reading of tge code, I haven't tried it out (as I don't have a Kempston or a real Speccy!)

Mystery solved! At #8633-#8635 in the Unfixed file, we find three NOPped out bytes. At #8633 in the Fixed file, there's a XOR A command ('AF'), followed by two NOPs ('00 00'). In the original Manic Miner game at #8633-5 is the CALL to the subroutine which plays the theme tune. Straight after those addresses, at #8636-38, there is a conditional jump to start the game if the ENTER or fire button was pressed (something which would have been checked for by the 'Play the theme tune' subroutine). Now, there is no music in this game (I seem to recall reading that was the author's decision in order to maximise available code for other, gameplay related purposes). So the CALL to the 'Play the theme tune' subroutine was NOPped out (and the actual subroutine, located elsewhere in the code, seems to have been repurposed as it contains what looks like a sequence of data bytes). But the following conditional jump (a JP NZ) was left in place! So if the Zero flag is not set when that point is reached in flow of execution, then the jump is activated and so the game will start automatically. Just prior to #8633, at #8626-2E, there is a check for whether a Kempston joystick is connected. If so, then a certain variable is initialised - and in the process, the Zero flag is set. Otherwise (if no joystick), then Z will be reset causing the auto-launch issue. So Philip Bee may not necessarily have had a different version of the game, or devised a fix himself, when he made his recording - he could have just had a Kempston plugged in. Finally, the fix that (presumably it was I who) devised is simple: the XOR A instruction in place of one of the NOPped out bytes has the effect of setting the Zero flag, so the condition to activate the subsequent jump isn't met and the game doesn't automatically begin. Incidentally, a better fix might have been to NOP out #8636-38 instead, since it's a redundant command (so you would have six bytes NOPped out in total, at #8633-8638, a potentially useful amount). (N.B. There is another check for whether ENTER or the Fire button is being pressed later on in the Title screen routine, during the loop which prints the scrolling message across the screen - which of course happens as soon as the game is loaded, since there is no title tune. Without that second check, with a Kempston joystick plugged in there would be no way to start the game at all!) P.S. Danny, feel free to use SPECSAISIE to see if there are any other differences between the 'fixed' and 'unfixed' files, other than the single byte at #8633? P.P.S. Sorry Sendy if this thread has veered somewhat off-topic! EDIT: Although it might be relevant in future: if one of the features of Eric's Hackulator is 'Turn off the title tune'(?), then that is seemingly currently an unsatisfactory patch.

The mystery of why Eugene: Lord of the Bathroom skips the title screen may be close to being solved - in fact, it may already have been solved at some point! I just went to see if I had a copy of the game on my laptop, doing a search in Windows Explorer using the search term 'Eugene'. I got some interesting results... as well as a Zip folder with the original game file (and its readme), I found two files in the same folder as the Zip (outside the Zip) called 'EUGENE Fixed' and 'EUGENE Unfixed'! I've just tried opening them up (in the QAOP online emulator), and lo & behold, the 'unfixed' one skips the title screen (after displaying it for the briefest of moments), whereas the 'fixed' one does not! (I haven't looked into whether any other bugs have been fixed between the two files, if indeed there are any other known bugs in the game - I'm not aware of any?) I can only surmise that at some point (the files date back to 2019), I investigated this very point, and came up with a fix - then forgot about it when the subject came up the other day! Anyway, I've attached the two files to this post - I haven't yet had chance to scrutinise the code to see the difference, though I would guess (if Erix1 Mode retains the same addresses for the title screen routine as an original Manic Miner game file), that the edit might be somewhere in the region of #861F to #8683. EUGENE Fixed.TAP EUGENE Unfixed.TAP

Just a random thought: another variable that might have been different when Philip Bee made his recording (versus Danny's recent investigations) - he could have had a joystick plugged in? (I recall there's a check in the title screen routine for whether a joystick is connected.) Bugs can manifest themselves in unexpected ways - perhaps it doesn't occur if the check for a joystick returns a different result? (This is pure speculation on my part! But it might be an explanation that doesn't rely on Philip having had a different version of the game file?) Incidentally, I don't suppose anyone is in contact with Philip these days? (In case he can shed some light on the mystery?)

"1=day, 2=night" It sounds like the idea at one point was that you would press a button during the loading process, and depending on what you chose, the BASIC loader stepped in to change the program data. (I haven't looked into what changes would have been made - dark versus light background, perhaps?)

I've had a quick go at Role Reversal. Made it as far as The Newsagents before losing my last life. I recognised some of the features from Erix1 mode (such as the message that gets printed in the top four character rows of the opening room, at the start of the game). Thanks for the credit in the readme, Sendy! 🙂 Danny's loading screen looks cool. (I tried to look at Erix's alternative loading screen out of curiosity, but couldn't get it to open - maybe someone could post a screenshot of it on here?) When free time allows, I'll have a proper go at RR, and see if I can earn Maria a night's rest!

Well, I've asked the question, and I'll let you know if I hear anything back. However, Vidar's last comment on Twitter dates from last September, so I don't know if they'll pick it up any time soon...

Is this him on Twitter?: @VidarEriksen1

Has anyone mentioned yet that there was a Jet Set Willy 3 released way back in 1985: https://jswcentral.org/jsw48-a-03_jsw_iii.html

To go all 'meta' for a moment, there may even be people who find discussions like these (about what different people's perspectives are of the most interesting aspects of JSW gaming) to be more interesting than playing, designing or hacking JSW games! 🤪

Thanks for this new file Norman, including the disassembly of the new code on the 'title screen'. Some observations: I like the way that you can dynamically switch* between the different conveyor logics using the s/d keys, as well as the detailed descriptor of the current mode (and associated values) in the status bar. 🙂 (*This feature reminds me of some of the rooms in 'Jet Set Mini', in which pressing the X, O and R keys together simultaneously causes the conveyor direction to toggle between left & right, or switches the sticky behaviour of a two-way conveyor on and off again, both of which are achieved by applying an XOR 01 gate to the conveyor direction byte.) ** I can see from the animating (but apparently unreachable) conveyor at the top left that, as I predicted 😎, all the different conveyor types animate in the same, 'clockwise' direction (except for type 11, the standard left conveyor, which animates 'anticlockwise'). ** Conveyor types 0 and 2 seem to be identical in behaviour to each other, as is the case for conveyor types 1 and 3. (N.B. Behind the scenes, types 0 and 1 might instantaneously be setting the movement flag, unlike types 2/3, but this doesn't have any effect on Willy's movement.) ** The choice of values to activate all the various conveyor types in this latest file is a pleasingly consistent set. 😃 This is not immediately apparent by looking at the values as stated - even after converting the decimal to binary - but once you subtract 3 from each value, and express in binary, you can see that in all cases bits 2-5 are set, and then every possible permutation of bits 0-1 and 6-7 are provided.

I think Andrew's policy is spot on. To take an extreme example of how a no-Pokes-are-off-limits approach amounts to cheating, if you load up Jet Set Willy and Poke the game mode indicator with a value of 2, Willy will immediately run from the bath to the toilet - game technically 'completed' in a matter of seconds! But with no sense of accomplishment or explanation.

It's all about personal perspective, and as you say everyone's is different but all are equally valid. For example, some would say that if you don't hack into the game engine and the various patches that have been applied to a game, then you don't get a full experience of it, only a limited knowledge. 😜

One more thought for now, regarding the new conveyor types that Norman came up with which always enforce sideways movement ("no lockout on falling" in Norman's terminology; "no drop & stop" in mine): If placed in a setting with earth blocks above a narrow channel that is just high enough to fit Willy (such as in the room Tree Root, or the Final Barrier in MM), these conveyors would prevent the player from using the trick of pressing the jump key to bump Willy's head on the ceiling (which on a regular conveyor can slow down or halt Willy's movement down the conveyor, making the timing of avoiding certain guardians much easier). When combined with Norman's 'fast slide' conveyor setting, this could make such scenarios much more challenging!

Incidentally, in the absence of changes to the 'Animate the conveyor' routine, all the types of conveyor discussed in this thread - except for standard left conveyors that have a direction byte value of zero - will have rightwards animation in their top pixel-layer (assuming the pixel pattern allows for visible animation).

Okay, possibly two more types (slow and fast versions respectively): POKE 32982, 130 POKE 32982, 66 My prediction(?): These ones might even have worked using Norman's original code (before I intervened). Edit: These two additional platform types would take the total number of conveyor variants up to 16 14 (FURTHER EDIT: MY LATEST EXPERIMENT DIDN'T WORK, I JUST TRIED OUT THE ABOVE TWO POKES IN TURN - THEY CREATED ANOTHER 'SLOW OFF' & 'FAST OFF' CONVEYOR, IDENTICAL IN BEHAVIOUR TO THE PREVIOUS SLOW & FAST OFF CONVEYORS), which is the maximum number of possible variants using 4 bits of the conveyor byte. Changing the other 4 bits will only create identical behaviour to those 16 14 types of platform. (Caveat: that might not be true if Willy runs over a conveyor during the toilet run, when the ability of the right 'P' key - and that right key alone - to stop the toilet run introduces an additional variable.) FINAL EDIT: The reason why the above didn't work as I had anticipated is this: Norman's code will have briefly set the movement flag, but in the absence of any bits corresponding to left-right movement being reset by a conveyor of this type (and assuming the player isn't pressing a movement key), then the movement flag will be reset shortly afterwards after the left-right movement table (#8421-#8430) is consulted.

There might be one more permutation possible - try POKE 32982, 191.

Thanks! Yes, that works exactly how I anticipated that it would. 🙂 It's an Off Conveyor, but Willy walks along it at double-speed if you press a left-right movement key (thanks to Norman Sword's code which responds to a reset bit 6 of the conveyor direction byte). And he stops moving if you stop pressing the key, even if you're still on the (non-)conveyor. One further quirk is that if you drop onto it from above without a sideways movement key pressed, Willy lands in animation frame 1, not animation frame 0 as usually happens when you drop off a platform onto the next platform below. N.B. As with my previous snapshot file, the effect only lasts until you lose a life/leave & re-enter the room/abandon & restart the game. (If you do one of those whilst playing around with the effect, you have to reload the game file.)

I think I've just come up with another new conveyor type (which also needs the minor tweak that I implemented yesterday to Norman's code to make it work - I replaced the first RET NZ with a JR NZ). A conveyor direction byte value of 11000010. (After the conveyor routine subtracts 3, this becomes 10111111.) I'm not in a position to try this out right now, but if someone wants to load up the 'Conveyor Logic test of new logic' snapshot file that I attached to my previous post, and apply the following POKE whilst Willy is in the Bathroom, they should be able to see it in action: POKE 32982, 194 (If you could then save another snapshot and re-upload, I'd be much obliged.)

Armed with my new understanding of how the conveyor direction bits affect Willy's movement, I've managed to come up with a new pair of conveyor types. Using a conveyor direction byte value of 11000001, and with a minor tweak to Norman's conveyor subroutine, I created a fast-sliding conveyor which otherwise retains the logic of the original JSW conveyors. e.g. you cannot drop down onto a conveyor from above and proceed upstream, but you can 'drop and stop' using the upstream button, and you can turn and stop by walking upstream and releasing the upstream movement key for a single time-frame then pressing it again. Implemented in the attached test file. (NB If you lose a life, or leave the Bathroom and re-enter, or restart the game, then the conveyor will stop working in the above way and you'll have to reload the snapshot file). Conveyor Logic test of new logic.sna

Aha! Cracked it! I was puzzled about this - how a conveyor with direction byte 01111110 would cause Willy to move rightwards if he falls down vertically onto it whilst facing leftwards, without any movement keys being pressed. Surely the fact he was facing left (bit 0 of #85D0 was set before he landed) would mean that leftwards movement would take precedence once the movement flag (bit 1 of #85D0) was set by Norman's code? Why, then does the conveyor turn Willy around to face to the right before moving him rightwards? (Conveyor type 6 in Norman's test file.) But then I realised that, after the conveyor subroutine has subtracted 3 from the direction value, giving 01111011 - BIT 2 IS NOW RESET. And it turns out that the higher bits of the conveyor direction byte (2-5) do actually help to determine Willy's sideways movement, not just bits 0-1. N.B. For a normal right conveyor, value 00000001, subtracting 3 gives 11111110. Only bit 0 reset so Willy moves right. For an Off conveyor, direction value 00000010, subtracting 3 gives 11111111. No bits reset so no movement (unless you press a left-right key). A direction byte of 01111101 would also act as a right conveyor (subtract 3 and you get 01111010 - both bits 0 and 2 reset).