IRF

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

Your scores achieved using this method have so far matched the highest reported scores in this thread: http://jswmm.co.uk/topic/421-file-manic-miner-highscore-challenge It will be interesting to see what score your automated method manages to acquire when you reach the Solar Power Generator, where Willy's interactions with the solar beam provide for perhaps a less predictable outcome in scoring terms...

No need to imagine - Crem has seemingly proven that 1724 is the highest possible score for the Central Cavern, via his automated generation of MM walkthroughs as reported in this thread: http://jswmm.co.uk/topic/580-automated-generation-of-manic-miner-speedrunwalkthrough/

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.

Spot on! Where Danny went wrong is that he arranged the data table into two columns, on the basis that that is how the data are arranged in the original JSW. But of course the reason that the data in original JSW is arranged in two columns, is because the WRITETYPER code draws on two half-rows of keys. Whereas in the JSW128 game engine, the fact that 'S' is one of the keys required indicates that three half-rows of keys are used, and therefore you need to arrange the data into three columns. The only question then is in which order the three half-rows are interrogated. The fact that the first three databytes are 1f 1f 1d, and once you knew that 's' is the first key in the sequence, tells you that A-G is interrogated after the first two half-rows (which follow the same order as in original JSW: Q-T and then Y-P). It was unfortunate that Danny made an error in transposing the data into his table - by adding an extra '1f' byte that doesn't exist, the dataset of 27 bytes became 28 and therefore fell into two columns. Once the errant byte is removed from the table, it should be obvious that the data doesn't fit into two columns. Hence my earlier comment that Danny should think about the: "implications... for the structure of the data".

EDIT: Danny, if when you read this post you have a 'lightbulb moment' and decide that you want to fully solve the 'superuser' puzzle for yourself, then please refrain from reading the following two posts before you have done so. Actually, I'll have a go at rearranging Danny's table of data myself to see what happens, just for fun. Using the same assumptions and methodology that Danny used first time round, but deleting the erroneous byte, this is what you get: 1f 1f no keys pressed 1d 1f w 17 1f r 1f 1e p 1f 1b i 1f 1f no keys pressed 17 1f r 1f 1f no keys pressed 17 1f r 1f 1f no keys pressed 1f 1d 1b w and i pressed simultaneously! 1f 1f no keys pressed 17 1f r 1f This byte has fallen off the end of the table! Clearly, something's gone wrong...

That's a big assumption in bold above. (Depending on your browser, you might need to expand out the quote to see the bit I've highlighted in bold.) To assist further, I've struck out the erroneous databyte from the second table above with a strikethrough font (and I've also highlighted it in italics). Now Danny, if you were to rearrange your table of data above with the correct number of databytes (to correspond with what is to found in the code at #C480 to #C49A, would there be something about the table of data that might make you question your assumption in bold?

Actually, it's only just occurred to me that drawing the maze must have been a far from trivial exercise, even putting aside the random nature of it every time it is drawn!