IRF

If Willy comes under the 'shadow' of a guardian then he (or part of him) can change colour. He only gets killed if one of his pixels collides with a guardian pixel though.

It won't make a difference in some caverns, where you have to wait around later on for a moment anyway - e.g. for the bottom penguin in the Cold Room to move out of the way of the portal. But it may well tweak the score up in other caverns?

Regarding the above, I meant to point out that the same is also true of using the WRITETYPER feature in a JSW128/JSW64 game. i.e. If you have activated Forcefield and anti-Gravity, then you can use WRITETYPER to get around without risk of accidentally suffering an IDS.

How strange, I wonder if it was an issue with your emulator? I've done a RZX recording to try and replicate what you described - see the attached - but I didn't encounter the problem (well, I did get the empty screen, but toggling the Forcefield off resolved the issue). Once the recording has finished, perhaps you could 'take back control' to see if you can replicate what you saw before? Forcefield Bug.rzx

I wasn't aware of the shortcut in 'Out on a Limb' which allows the top-right set of leaves to be bypassed, until I saw your video. However, I would tend to agree with Danny about the potential time saving from kamikazi-ing this room, especially as it is possible to collect both items in a single jump - see attached RZX recording. I've checked the timings and in both your recording and mine, it takes 28 seconds from entering 'Out on a Limb' to the moment when Willy drops down into 'On a Branch over the Drive' - but in your recording, you had already lost all of your spare lives by that point, whereas I had a full complement of lives when I started the recording (losing one in the process of collecting the two 'Out on a Limb' items). Plus I had the in-game tune playing, whereas you didn't. So taking those factors into account, I think you would save a good few seconds. I don't know how many seconds of playing time you saved on each occasion that you used the kamikaze method, but some of them might be outweighed by the time saving available in OoaL? ** A couple of other things that I did wonder about: firstly, why visit the Beach and Yacht area before collecting the Tool Shed item on the way back? If you do the Tool Shed first, then the time spent on the Beach/Yacht would run a bit quicker as you'd have one less life dancing on the status bar. And since Tool Shed is en route in both directions, there's no reason why you couldn't have done the Tool Shed first? Also, it seems an awful long walk all the way to the Offy and back again - isn't there a saving to be made by jumping off the top of the Watch Tower so that you only have to make that journey in one direction? Out on a Limb.rzx

It's also more perilous as you might hit one of the crabs embedded in the sand.

There's a potential rope warp in The Beach as well, isn't there?

Danny, I was going to provide that link to the full set of recordings, but I decided against it as it will presumably soon need updating - once you have managed to match (or perhaps even beat?) the current record score for the Cold Room? 😉

P.S. I did try out using 'A' in a Cheat password, but it seems to pause the game and therefore cause the code which detects Cheat keypresses to be bypassed, before the program gets chance to update the Cheat Key Counter variable. So if you come up with a password for which you wish to use the 'A' key - which may well be the case since it happens to be a vowel - then you would need to change the Pause button. e.g. changing the 'AND 01 CP 01' at #8AC8-8ACB to 'AND 04 CP 04' makes 'D' the JSW128 pause button instead of 'A'. (Or you could just ditch having an in-game Pause key, and use your emulator's Pause function instead!)

To take this a bit further, the following three commands in the JSW128 Cheat routine could be edited to change the half-rows of keys that are picked up: At #C428, there is LD BC, #FBFE (01 FE FB in opcode) At #C446, you will find LD B, #DF (06 DF) At #C45E, we have LD B, #FD (06 FD) Changing the value that is loaded up to B in one or more of the above commands will change the half-row(s) from which keypresses are detected. Doing that in conjunction with editing the data at #C480-#C49A could allow you to have a 9-letter Cheat password that draws characters from any three half-rows of keys. e.g. POKE #C45F, #FE changes the existing password to ZUPERUZER (loading B=#FE allows you to access the half-row SHIFT-V, and in this case there is no need to edit the table at #C480-9A, because 'Z' occupies the same position as 'S' in their respective half-rows - pressing them resets Bit 1 in both cases). Note that if you're using a key like 'Z' as part of your password, which also functions as a Jump key, then you have to wait until Willy has landed again after pressing it before proceeding with pressing the next character in the password sequence - I've just tried it though and it does work! There is a very handy table below (from the following link), which gives a full list of all the ports and bits that correspond to each key on the Spectrum: http://www.breakintoprogram.co.uk/computers/zx-spectrum/keyboard

I watched Danny's recording in SPIN.

Attached is JetSetDanny's (Daniel Gromann's) RZX recording of Abandoned Uranium Workings, in which he achieved a score of 1854 points. 04 Abandoned Uranium Workings.rzx

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. 😃

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.🙂

I believe that if the jump at 22 seconds was replaced by walking off the platform instead, then it might save one time-frame (equating to one more point)? Because jumping forwards, when you can walk continuously forwards instead, slightly slows you down. (I'm not certain though, because that jump ends in a fall to a lower level which has to be executed anyway, even if you walk that bit.)

It looks like laughter to me!

From RB's previous posts, I don't think losing all lives (bar one) is required by the rules, but that it's a tactic employed in order to speed up the game (when measuring a 'real time' completion time), because the program drawing the remaining lives slows down the game (only slightly, but it adds up over the course of a whole game). (I'm not sure about your terminology queries.) From your perspective Danny, of basing the speed of completion on the in-game clock time, the running speed of the program is not a factor so I think you should definitely stick with your tactic of 'Top Landing item first'.

And a very concise and helpful post it was too!

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

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

I did come up with the idea of doing a Fat Willy (oo-er missus!), with a really fat playing sprite (making it difficult to sneak past some of the guardians), and have the cheat code key sequence as SPARETYRE! 😁 But the 'A' key is used to pause the game, so the program would probably pause before 'A' gets detected for cheat code purposes, thereby disallowing that letter from being used. (Unless you tweaked the game engine so that, say, 'D' pauses the game instead of 'A'. N.B. 'F' and 'G' couldn't be used for pausing as they're used in activating the Forcefield/antiGrav features.)

For Eugene, you might need to adjust your algorithm so that it collects the nearest item to the portal last - even if that means passing close by to it without grabbing it straight away, but coming back for it once all other items have been bagged. And also, if Eugene is too close to the portal at the point when Willy is about to finally collect that item, you might have to get him to wait around [which I know you've said the algorithm doesn't like to do!] until Eugene has ascended to a height that allows Willy to sneak into the portal once it starts flashing (whereupon Eugene becomes angry and starts descending again). Thinking ahead, Skylab Landing Bay is another 'special' room, but I don't foresee that one will cause the algorithm any particular problems?

Another fundamental difference in cultural mindset on display here - I enjoy the site of lots of air being counted down at the end of a cavern, as a sign that I've achieved a high score; you presumably see it as a nuisance, holding you back from swiftly tackling the next cavern!

The two normally amount to the same thing, don't they? As air is sapped in a linear fashion over time. The only exception to that rule is the solar cavern. I would imagine it will be quite complicated to optimise for remaining air in the solar cavern. Bear in mind that the amount of air sapped by the beam in each frame, when Willy is inside the beam, is different if Willy is vertically cell-aligned (occupying only two character rows), than if he is mid-jump or mid-fall and therefore his sprite (technically, his white INK colour-attribute) is spanning three character rows of the screen. So as well as generally minimising the time when Willy is within the beam, your algorithm might need to take into account that - for those moments when entering the beam is unavoidable - the air-sapping power of the beam differs as explained above. P.S. Given that you optimise for least number of time-frames of the game, rather than for highest score per se, you presumably won't bother collecting the bonus points for dislodging Kong from his perch? Which will probably mean that you won't match the highest scores in the two Kong caverns.

Or better still, so that game designers can edit the cheat code table of data, allowing them to have a bespoke activation code instead of 'superuser', for others to crack! Your latest challenge Danny, should you choose to accept it, is this: the next time you are designing a JSW128 or JSW64 engine game, think of another 9-character codeword that only draws on the same three half-rows of keys (i.e. Q-T, Y-P and S-G; 'A' is the pause key in JSW128/64 so is best avoided), and use what you have learned from Norman Sword's post above, to implement a novel alternative Cheat Mode key-sequence for your new game...