IRF

Further to the above, I've just observed that this particular efficiency is present in 'Geoff Mode', so it is 'tried and tested'!

N.B. The Cyan 'Kong caverns' guardians are present when you play the game!

Richard, I've just noticed that neither of the two 'Kong Beast' screenshots in the MM disassembly display the Cyan horizontal guardian!? Also, the comment at #91EE caused me momentary confusion; perhaps it should read: "The Kong Beast is drawn with Yellow Ink when he is falling"?

We already used or recycled a lot of those elements in The Nightmare Edition, but it's good to have them catalogued here in this thread for the 'wider audience'. :) Note that 'AIR' is used by JSWED to determine whether or not a file may be edited using its GUI.

Comparing the 'The game has just loaded' routines for MM and JSW (contrast the two links below), the latter seems to go about sending the program to the 'Display the title screen...' routine in a rather roundabout way. Perhaps this was originally done to try to confuse potential hackers who were attempting to bypass the 'Code entry screen' security element of the game? But now that the 'Code entry' routine is a bit of a 'relic', maybe the MM approach could be used in JSW? It would only take 7 bytes to disable interrupts, set the stack pointer (in the case of JSW, to #5BFE) and then make a direct jump to #87CA. http://skoolkid.github.io/manicminer/asm/8400.html http://skoolkid.github.io/jetsetwilly/asm/8400.html

Funny you should mention the Spectrum ROM, I've been experimenting recently and a familiar shape has popped up - see if you recognise it from the attached screenshot (the Black thing at the top-centre of the screen)... Also, you might be able to answer a query I had a while ago about the area of the 'contended memory' #5B00-5BFF. The 'top end' of it seems to be used for the stack addresses in JSW (starting at #5BFE-FF), but does it have any other use than that? #4000-#57FF is the display file, #5800-#5AFF is the attribute file, and the JSW buffers begin at #5C00 - so 'page' #5B fits in between those. I came round to your way of thinking on Willy's Jumping Animation Counter (when he makes a quirky jump 'Through the Wall') and the way the Rope Animation Table works (in calculating the offsets of each Rope segment) - although I had a couple of suggestions for 'clarifications' in the Trivia entry for the former, and the introductory text for the latter - and I've bombarded this thread with a host of other ideas since!

I've tried the above and it worked!

I believe the exact same trick can be pulled off at #8950. And a similar trick at #8975, replacing the LD DE, $0000 with a LD E, $00. (The value of 'D' is retained as #50 from the preceding command at #896B.)

Further to my 'Guardian Class 127' fix: I now believe, although I haven't tried this yet, that it might be doable in seven bytes (replacing the two-byte RES 7, L instruction at #892E, so a net total of just five bytes would need to be inserted via consolidation): 08 7D 12 3C 28 $00 08 I haven't figured out the operand of the relative jump in the above yet; but it needs to send the program straight to #894A. EDIT: Actually, it might still be #1B, although the conditionality of the relative jump is now reversed so that it's now '28 1B' rather than '18 1B'. FURTHER EDIT: If the one-byte efficiency at #893E has been employed (replacing the LD BC with a LD C , then the above relative jump forwards should be 28 1A. And similarly, the relative jump backwards below should read 20DD. Also, the operand of the relative jump at #8948 would need to be 'changed differently'; I think it should now read '20 DC'.

I have just noticed that the LD BC, $0000 command at #893E can be replaced with a LD C, $00, thereby saving one byte (because the '00' value of B is retained from earlier on in the code that populates the current room with guardians).

9D00 in the JSW disassembly: 'Willy sprite graphic data' - perhaps you could mention that one of the sprites is used by the 'Display the game over sequence' at #8C4A?

Incidentally, where does Interface1 fit in, in the scheme of things?

Does anyone ever use the number keys to control Willy's movement in JSW? I believe that if you were prepared to sacrifice the ability to use the number keys to move Willy, then the following bytes could be 'recycled': #8F1A-8F31 and #8F78-8F7F - that's about 32 bytes that could be freed up! N.B. This stills leave the options of pressing Q-P for left-right movement and the bottom row/Space bar for jumping, or else using a joystick. (EDIT: Also, the number keys would then allow you to unpause the game without causing Willy to move, or altering the On/Off status of the in-game music.)

Preambling quote from another thread: I think there may be a way to iron out this inconsistency in the way that the joystick's 'Fire' button works (or doesn't) in starting up the game from the Title Screen. And in the process, it may achieve a saving of 6 bytes! I haven't tried this out yet, but if the 9 bytes from #88E3-88EB were replaced with a 3-byte CALL to the subroutine at #96C9, shouldn't that do the trick? If it works, it would be of great assistance in implementing the code changes nearby (in the 'Start the Game' routine) that allow a Guardian Class 127 to be created! UPDATE: I just tried it, and it does seem to work - certainly the ENTER key starts the game up with no problems both during 'Moonlight Sonata' and during the scrolling message (alas I haven't got a joystick to try the Fire button out in both scenarios).

I bumped the topic because you mentioned this in the 'Quirky features' PM, so I thought you were looking for it? :ph34r:

More like Snail Pace Willy than Jet Set Willy then?

I think #FF is slow enough!

*Bump*!!!

Note that there is an alternative approach to the instructions at #880E-8812, namely to initialise the value of #85E2 to '1'. This can be achieved by inserting (via either consolidation, or a jump to elsewhere and back again) the following commands near the start of the 'Display the title screen...' routine (#87CA onwards): LD A, 1 [or INC A if it follows the commands that set various parameters with a value of A=0] LD (#85E2), A The above ensures that the in-game music is always playing at the start of every game - even if it had been switched off during the previous game - as well as setting the Keypress Flag (Bit 0 of #85E2) to 1, to prevent the player from accidentally turning the music off if they keep the ENTER key depressed as the game begins.

Incidentally, the game can also be started up by pressing the '0' key, which acts as a 'Jump' key during the game. But there is no equivalent check of the Keypress Flag when pressing jump, so starting the game in this way can indeed instigate a jump at the start of the game (if you keep the key pressed for too long). N.B. Pressing the 'Fire' button on a joystick can also be used to start up the game when the title music 'Moonlight Sonata' is playing, which could have the same effect. Although looking at the code it would appear that, curiously, the joystick Fire button does NOT provide the function of starting up the game whilst the scrolling message is in operation!

Sorry, I probably didn't make my thoughts clear. What I meant to say was: it would be good to have an option of unpausing the game without having to press a 'movement key' and without having to switch the in-game music off. (i.e. if you've paused the game when Willy is in a perilous position, you don't necessarily want to 'unpause' the game by pressing Jump or Left or Right, which might make Willy's situation worse!)

If you apply the following two POKEs: #8B27, #1E #8B29, #1E then the ENTER key no longer toggles the in-game music on and off. However, the music can still be toggled via the H-J-K-L keys. (The original value of those two bytes is #1F. Also, it is instructive to compare and contrast the two operands at #96DA and #96DC, which both have values of #01.) I think that implementing the above would mean that the five bytes of code at #880E-8812 are no longer necessary? (The purpose of those bytes is to ensure that when pressing the ENTER key to start the game, if in doing so the player keeps the key pressed for too long, it doesn't accidentally toggle the in-game music on/off.) It is also useful to be able to have a method of pausing and unpausing the game without the in-game music being switched off. (e.g. It keeps each rendition of the in-game tune in sync with the 'game minutes' on the status bar digital clock.) Finally, I would say that ENTER is already treated differently to the rest of the keys with which it shares a 'port' (if that's the correct terminology?), because of the use of ENTER (and only ENTER) to start the game, and so it makes sense to fully differentiate the key's function in this way.

Further to the above, I just NOPped out the single byte at #8D4D (or the equivalent location) in a test file that I created a while back, in which I'd integrated Stuart's Cell-Graphics Bug Fix into the main 'Drawn the current room...' routine (it's the first of two '59' entries in the hex code in the vicinity), and Stuart's patch still works just fine. So to quote Richard (SkoolKid), #8D4D is a 'redundant instruction' once the patch is in place. And furthermore, the spare byte is in a potentially useful place, as it isn't too far away from the start of the routine in which it sits (which in turn is preceded by the Game Over sequence, which in our recent projects has been amended/relocated elsewhere, leaving a good chunk of unused code in the vicinity to consolidate the extra byte with).

Looking at the 'Draw the current room to the screen buffer' code, in association with Stuart's POKEs, I believe that the single byte in the existing code at #8D4D is superfluous with Stuart's fix in place, and could be consolidated away. Its original purpose was to pass the value of C on to E, whilst the CPIR loop worked on the BC register pair. Stuart's code (as an alternative to the CPIR loop that yielded the Cell Graphics Bug in the original game) uses the DE register-pair to count (and therefore bypass) the intervening graphic bytes between each attribute byte. It also uses the B register, but not the C register. After an attribute byte match has been found, the program returns back to #8D59, where an identical instruction to that at #8D4D is now located. This is instead of the command in the original code that restores the value of E back to C; the value of C no longer needs to be restored, but the value of E does, and so an LD E, C command is applied - again - and this supercedes the need for the first attempt at passing C's value to E (#8D4D). For reference: http://jswmm.co.uk/topic/93-new-jsw-build-suggestions/?p=798