Cheat modes in JSW128

[JianYang]

foodstuff could work for a fat willy game and maybe twiggiest for the bulimic willy sequel?

[jetsetdanny]

13 hours ago, IRF said:

That isn't my recollection of your previous attitude, Danny.  As I recall, after I had figured out the JSW128 cheat code (about 2 or 3 years ago), I offered to let you know what it was. But you asked me not to reveal it to you as you wanted to work it out for yourself.

Then a year ago, you got so close (at least in respect of the 'superuser' code), that although you then invited me to fill in the details, I felt honour-bound not to deprive you of the satisfaction of working the rest out for yourself!

And I still maintain that, if you had spent the two minutes it would have taken you to correct the unfortunate typo in your first attempt that I pointed out to you last year (see third post in this thread), then with a bit of lateral thinking you should have been able to solve the puzzle in a much more intellectually satisfactory manner - and consuming less of your 'precious Willy time' 😁 in the process - than the 'brute force' trial-and-error method that you eventually employed!

No matter, it's done now.

 

Ian, let me explain 🙂.

My primary objective has always been that the way to activate the cheat code should be made public.

At some point in the past, 2 or 3 years ago as you say, when you had solved the mystery, you chose not to make it public. You did offer to reveal it to me and I said I would try to work it our for myself for the following reason: if you had revealed it to me, I wouldn't have felt I had a "moral right" to make it public, especially if you hadn't thought it was a good idea. If you had insisted that it should not become public knowledge, because maybe someone else would have their fun solving the mystery or for whatever reason, it would have been an awkward situation for me: knowing the solution, but not being able, for ethical reasons, to reveal it.

This is why I declared back then that I preferred to continue working on the solution myself, so as to have no qualms and publish it immediately after I discovered it on my own. Which has just happened 🙂.

Furthermore, in recent days I did not just ignore your comments and tips. When I started working on this issue on Saturday, I first corrected the error you had spotted in my earlier data table and I tried to figure the solution out by analysing the code. It did cross my mind that three bytes could be involved for each letter instead of two, but, firstly, I had no idea why 1f  1f  1d would correspond to "s" (which I knew was the first letter) and secondly, I made another mistake: when I re-copied the data (in pairs of bytes) I ended it with the #FE which is at #C49B, so I had 14 pairs of bytes, which (if only two bytes were involved) seemed to correspond to 14 letters (I can now see the FE is part of a CP instruction, isn't it?). I knew that there were only 9 letters in the password (because #09 was the value which turned the cheat mode on when POKing the game), but I thought that perhaps the 10 additional bytes had to do with letters that activated antigravity and invincibility.

When I wrote previously, regarding your tips, that "I should note that I did not make use of them - I couldn't arrive at the solution on the basis of the code", what I meant exactly was that I did not use them in arriving at the solution. The truth is, I tried to use them, but I failed to succeed in this way, by looking at the code, so then I tried a different method (for which your tips had no impact whatsoever) and it worked. And, to be honest, it was entirely satisfactory for me at any level - after all, I *did* solve the mystery on my own and could announce it "to the whole world" without any qualms - which had been my objective all along 😁.

As for something being more or less "Willy-time-effective": once I knew that the brute force method would work (when pressing u" turned the value of #C400 to "02"), I was sure this was the way to go. I knew this method would work; it would take some time, but it was pretty much a guarantee of solving the puzzle successfully. On the contrary, wondering about how the code works has no guarantee of success for me, ever. If I don't understand it, I can spend hours pouring over it, and still fail to succeed, only growing increasingly frustrated in the process. So it is an easy choice for me if a brute force method is available.

Having said that, I need to confess that I still don't understand why 1f  1f  1d corresponds to "s". If it is explained in plain terms (which I suspect you might do) so that changing the password becomes easy for me, I *might* change it if I ever design a JSW128 or JSW64 game again (no promise there though). Otherwise, no, I will not be taking up this challenge, as my "Willy-time" will be better spent on other things, sorry 🙃.

[IRF]

4 hours ago, jetsetdanny said:

Furthermore, in recent days I did not just ignore your comments and tips. When I started working on this issue on Saturday, I first corrected the error you had spotted in my earlier data table and I tried to figure the solution out by analysing the code. It did cross my mind that three bytes could be involved for each letter instead of two, but, firstly, I had no idea why 1f  1f  1d would correspond to "s" (which I knew was the first letter) and secondly, I made another mistake: when I re-copied the data (in pairs of bytes) I ended it with the #FE which is at #C49B, so I had 14 pairs of bytes, which (if only two bytes were involved) seemed to correspond to 14 letters (I can now see the FE is part of a CP instruction, isn't it?). I knew that there were only 9 letters in the password (because #09 was the value which turned the cheat mode on when POKing the game), but I thought that perhaps the 10 additional bytes had to do with letters that activated antigravity and invincibility.

Since you had previously stated at the start of this thread (correctly) that "The data in question is at #C480 - #C49A", it never occurred to me that, after deleting the errant byte from your table of data, you would shunt another one along to replace it! (the 'FE' at #C49B which, as you point out, is a CP instruction). Perhaps if that had been a 3A (LD A, $00) or something, you might have recognised it more easily as code rather than data (but that's a moot point!)

Anyway, from what you said above, it seems you did have at least an inkling that the data should be arranged in three columns rather than two.  If you had followed up on that notion, by rearranging the data into groups of three (i.e. three columns in your table of data), then you wouldn't even have needed to understand why '1f 1f 1d' equates to 's' - you knew from trial-and-error that 's' was the first key, and no other keys in the A-G half-row are used in the cheat code ('s' is reused but that's just another '1f 1f 1d'), and all the other groups of three bytes correspond to equivalent entries in the WRITETYPER code from original JSW (as long as you add a '1f' at the end of each pair of bytes from the original JSW WRITETYPER table. e.g. the last entry in the WRITETYPER data in original JSW is '17 1f', equating to the final 'r' of WRITETYPER; whilst in JSW128 the last row in Norman's table is '17 1f 1f' which also corresponds to the final 'r' of the codeword SUPERUSER).

But to assist your understanding, here's a full explanation: the program looks at inputs from three key ports (three half-rows of keys) in the following order: Q-T, then Y-P, then A-G.  Just as with WRITETYPER, an indexed CP command is used (CP (IX), I think), to compare the input from each key port in turn with the associated entries from a table of data.  (IX is first defined so as to point at the correct row of the table, based on the current value of the Cheat Mode Key Counter variable at #C400).

In original JSW, the table is arranged in two columns, with a CP (IX+$00) and CP (IX+$01) being used to interrogate the first column and then the second column.  (These data in Skoolkid's disassembly are expressed in binary, which helps with understanding which bits are set/reset.)  In JSW128, the table has three columns, so CP (IX+$00), CP (IX+$01) and CP (IX+$02) are employed to check the first, second and third columns of the table in turn.

So the entry '1f 1f 1d' works out like this:

(An input to a key port of 1f means that no keypresses are detected.  If any of bits 0-4 are reset, that indicates a key being depressed.)

The first entry in this row of the table is 1f = none of the keys Q-T are being pressed;

The second entry in this row of the table is 1f = none of the keys Y-P are being pressed;

The third entry in this row of the table is 1d = one of the keys A-G is being pressed - so lets look in more detail at that half-row of keys: pressing A sends the value 1e to the relevant key port (bit 0 is reset); pressing S sends the value 1d to this key port (bit 1 is reset), etc [see Norman Sword's table for the full list] - we have a match in bold with the 'S' key!

 

Anyway, congratulations Danny on finally working out the JSW128 Cheat Code, by hook or by crook!

 

P.S.  I've just checked out a JSW128 game file, and the key combo for Forcefield is F+SHIFT on my laptop; for anti-Gravity it's G+SHIFT.  (I think SHIFT on a laptop is equivalent to CAPS SHIFT on a real Spectrum, with CRTL on a laptop equating to SYMBOL SHIFT on a Speccy, but I'm not 100% sure on that - they could be the other way round?)

 

(P.P.S. I should probably mention that in original JSW, the first row (or rather, the 'zeroth row' - it is skipped past in the first instance that the table is used) in the WRITETYPER table isn't the one corresponding to the 'w', but a pair of values '1f 1f' corresponding to no keys being pressed.  I think that's present because there's a check back to the previous entry in the table to make sure pressing a key for too long doesn't accidentally reset the Key Counter variable back to zero.  You might expect a similar row of three '1f's at the start of the table of data in JSW128, but there isn't.  However, its absence doesn't seem to affect the ability to switch on the Cheat Mode.)

Edited March 8, 2021 by IRF

[IRF]

1 minute ago, IRF said:

and all the other groups of three bytes correspond to equivalent entries in the WRITETYPER code from original JSW

Actually, now that I've re-read it, I've realised that statement is not entirely true - the letter 'U' doesn't appear in WRITETYPER but it does appear (twice) in SUPERUSER.  But you should now have enough information (both in my previous post and in Norman Sword's post from yesterday) to work out the three-byte entry which equates to the 'U' key - or indeed any of the keys in the range Q-G, should you ever wish to devise a new Cheat password for a JSW128 or JSW64 game! 🙂

[Norman Sword]

I had read some of the posts regarding this topic. It was not something I needed to know, so it did not concern me. I looked at the code only a few minutes before my only post on this subject. 

[IRF]

7 minutes ago, Norman Sword said:

I had read some of the posts regarding this topic. It was not something I needed to know, so it did not concern me. I looked at the code only a few minutes before my only post on this subject. 

And a very concise and helpful post it was too!

[jetsetdanny]

Ian,

Thank you for providing the Invincibility and Antigravity cheats! 👍

On my Spectaculator running on a desktop computer the keys that activate them are exactly the ones you mentioned: Invincibility (Forcefield) is f + left SHIFT and Antigravity is g+ left SHIFT.

I really like the icons that appear when these cheats are activated! 🙂

I treat the cheats as a curiosity rather than a real tool, because using them to play the game would make it 'unreal' and perhaps even limit the playability in some cases. For example, using both cheats, I got out of "Root" and went up to "The Drive". I propelled Willy upwards to hang in mid air, then turned Antigravity off (leaving Invincibility on). He fell down to the ground and didn't get killed, but all sprites disappeared - Willy and all of the bird guardians. I am staring at an empty Drive, with the cheat-mode in-game tune playing in the background, and I don't think there's anything else I can do other than reset the game. Even the fast inter-room teleportation (which could be a useful tool perhaps) isn't working any more...

[jetsetdanny]

Ian, thank you so much for your detailed explanation of how the code works to form the password that activates the cheat mode! 👍 Your explanation has allowed me to understand how it works and it's all clear to me now, which I have confirmed by making a test and modifying the password successfully 🙂.

[IRF]

3 hours ago, jetsetdanny said:

I really like the icons that appear when these cheats are activated! 🙂

You will be able to see what I mean now about the missing graphic byte for one of those icons in JSW64!

I treat the cheats as a curiosity rather than a real tool, because using them to play the game would make it 'unreal' and perhaps even limit the playability in some cases. For example, using both cheats, I got out of "Root" and went up to "The Drive". I propelled Willy upwards to hang in mid air, then turned Antigravity off (leaving Invincibility on). He fell down to the ground and didn't get killed, but all sprites disappeared - Willy and all of the bird guardians. I am staring at an empty Drive, with the cheat-mode in-game tune playing in the background, and I don't think there's anything else I can do other than reset the game. Even the fast inter-room teleportation (which could be a useful tool perhaps) isn't working any more...

I do recall observing that glitch a while ago (and coming up with an explanation how it works in terms of the code - I think the Main Loop gets stuck in a, er, loop!)

You can easily get out of it though, without resetting the game, by just toggling Invincibility Mode back off again.🙂

Edited March 9, 2021 by IRF

[IRF]

Here's another strange effect which can arise from use of the Invincibility feature: if you walk through a Fire cell, Willy disappears temporarily (as do all the guardians).  However, if you keep pressing the Left or Right key then Willy can continue to walk 'behind the scenes' (and all the guardians are still moving behind the scenes as well), until the point when he has cleared the Fire cell, at which point his sprite reappears (as do the guardians)!  So it doesn't create the same 'frozen up game' issue that you discovered when Willy lands on a solid platform after falling from a fatal height with his Forcefield in place.

***

Anyway, in terms of the usefulness of the Forcefield and antiGravity features, I believe they are useful tools to be used in conjunction with the inter-room teleportation via Z/X/C/V (part of the package, if you will).

If you try to teleport between rooms without using SHIFT+F and SHIFT+G, then it is possible to inadvertently end up in an Infinite Death Scenario if you appear in a room on top of a guardian or Fire cell, or if you emerge suspended in mid-air more than four character rows above a solid surface.

The Forcefield and antiGrav features are therefore recommended (by none other than John Elliott himself!) to be toggled on before you attempt to use Z/X/C/V for inter-room teleportation, and then once you have arrived at your intended destination, and you've ensured that Willy is in a safe position, you can toggle F and G back off again. 😃