Jet Set Willy: Role Reversal release imminent

[IRF]

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. 

Edited March 14, 2023 by IRF

[erix1]

8 hours ago, IRF said:

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 is checked for in 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.  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 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, Z will be reset causing the auto-launch issue.  So Philip Bee may not have had a different version of the game or devised a fix himself (other than plugging a joystick in before loading the game!)

Finally, the fix that (presumably it was) I devised is simple: the XOR A in place of one of the NOPped out bytes sets the Zero flag, so the game doesn't automatically begin. 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, 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. 

WOW! Impressive debugging IRF! (And to think you already had it figured out years ago…)
Well, I guess we can label the support-issue “closed” then. 😊
The "Hackulator" is only used for manipulating jsw-games, and do not include the option to turn off the title-tune. Eugene lotb don't really modify the original game engine all that much. It's created using Andy Nobles Manic Miner-editor, and I think the only hacks applied is a few hard-coded extras for three special levels (Jet Set Pac, The Kold Room and The Lab.)  

 

[IRF]

12 hours ago, IRF said:

(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!)

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

Edited March 14, 2023 by IRF

[Spider]

Ah I was half right.

The issue with emulated Kempston is without the interface selected in the emulator options, the results of a read of port 31 can vary. I've not retested this but I think it varies between Spin and Spectaculator, also may vary depending on what model of Spectrum has been chosen.

Best way to test it if its enabled is to map it to 'dead' keys, try to avoid cursor because its likely to emulate these as Interface2 inputs. Perhaps set Kempston fire as right CTRL , that way little doubt.

[IRF]

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

Edited March 14, 2023 by IRF

[Spider]

20 minutes ago, IRF said:

though I could be misremembering that

I think it can vary. It might be emulator specific or vary if Kempston is enabled or not. The potential issue and I've not looked into this is a .z80 contains most of the joystick information whereas a .sna may not as its more 'memory' not much more. Then factor in the .szx format too.

EDIT... I did look into it!

Freezing emulation in 48K mode in Spectaculator at the copyright line, then taking a z80, a sna and finally an szx results in this, you can see the differences. 🙂 

For reference, the joystick type was set to Cursor/Sinclair so it would not emulate Kempston.

 

 

Edited March 14, 2023 by Spider
Much untangling of my post caused by buggy 'spoiler' code

[Spider]

May have to split these posts off into their own topic at some point.

There's also the unlikely issue (does not effect MM or JSW) of issue 2 vs issue 3 keyboards, although this relates slightly to how the ULA responds. Issue 2 is quite rare now keyboard wise as its the ULA iirc.

[jetsetdanny]

Great job, Ian! Thank you! 👍  

20 hours ago, IRF said:

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?

I've done it, the results are attached. The fixed file comes first, the unfixed second.

The only difference above #8000 is the #AF at ##8633.

The comparison shows some differences below #8000, in the Attribute buffer at #5Cnn and #5Dnn (cavern + Willy + guardians + items + portal). I'm not sure why this happens, as the TAP file with a JSW or MM game only contains data from #8000 to #FFFF (it's a block of code loaded starting at #8000), doesn't? So what does SPECSAISIE compare below #8000?

In any case, to be on the safe side, I have prepared a fixed TAP file which is only different (as analysed by SPECSAISIE) from Vidar's original file at #8633, and I also saved it as a TZX file. It is attached below, as a 'draft proposal', with a description typical of the bug-fixed versions of games I host on JSW Central.

Ian, would you have any suggestions for changes in the description in the ZIP file?

And Vidar, would you be so kind as to 'officially' approve it as a bug-fixed version? I mentioned your endorsement in the attached text file, but of course it's only tentative, awaiting (and hoping for) your approval. Please let us know! 🙂 

eugene.txt UNAPPROVED_Please_do_not_spread_Eugene_-_Lord_of_the_Bathroom_(bugfixed_version).zip

[IRF]

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

[jetsetdanny]

Thanks, Ian! 👍 It's based on what you wrote, of course.

Let's wait for Vidar then, to see if he approves the 'official' bugfix.