IRF

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

Andy, I believe it would be more appropriate if this topic was located in the 'JSW' rather than 'Remakes' category (along with topics on other Bug Fixes that we've created there), what do you think? Could it be moved? Also, I've just noticed that Richard (SkoolKid) provided an even more efficient way of fixing the bug in his disassembly: http://skoolkid.github.io/jetsetwilly/reference/bugs.html#longDistanceNasties I think if it was inserted via consolidation, then only four bytes would need to be found, which could be done by raiding either the Toilet code or the Flying Pig code - it wouldn't be necessary to do both!

JSW disassembly 'Display the title screen...': the side comment at #8820-8827 - it might be worth pointing out that 'DE' isn't defined here, in advance of the LDIR command at #8826 - but that's because it has been left with an 'initial' value of '#5800 (pointing at the attribute file) by the operation of the previous LDIR loop (#8813-881F) that cleared the display file!

Resides sounds good to me!

I should point out that the above patch doesn't resolve the issue which can occur, if you have a guardian that moves between mediums of different Paper colour. If a guardian does that, then the 'Draw the guardians' routine selects the Paper colour of the top-left cell that is occupied by the guardian in a given time-frame, along with its own Ink colour, and uses that attribute for all of the cells that the guardian occupies (i.e. a 2x2 square or a 2x3 rectangle). Because of this, if a guardian moves up/down or left/right past a boundary between two mediums, then the guardian's background can change colour. [Of course, it also changes the Ink colour of any filled-in pixels that fall within its 2x2 or 2x3 'zone of influence'.] To see what I mean, try inserting a Vertical Guardian in The Swimming Pool, such that as it moves it dips in and out of the (Inkless) Water cells. This is in stark contrast to the routine that draws Willy's sprite and colour attributes, in which the 4 (or 6) cells that his sprite occupies are considered in turn - each cell retains its Paper colour (and also its Ink colour unless it is an Air cell). Again, The Swimming Pool provides the best example - as Willy descends down the Ramp into the Water cells, his Ink and Paper colours make a smooth transition.

In the Entity Buffer at #8100, the description of Byte 9 of the Rope definition should read: "Index of the segment of rope being drawn (0-32)" As opposed to (0-31) which it currently states. As previously discussed, there are actually 33 segments to the Rope, although only Segments 1-32 are drawn using coordinate offsets drawn from the table at #8300; Segment 0 is drawn at the top with no offsets applied. This may seem 'picky', but the detail is quite crucial to understanding how certain quirky features of the code operate! By the way Richard, can I just reiterate what an invaluable resources your disassemblies have been, as I have endeavoured to get my head round the intricate workings of the JSW/MM game engine!

Regarding the above, when Willy jumps off the top of the screen (actually wrapping round to the bottom, as Willy's y-coordinate can't be negative - you can briefly see his head below/within the platform at the bottom of the screen!), it also causes corruption to Room 7: Miner Willy Meets the Kong Beast. See the attached screenshots. This occurs because, in trying to draw Willy at a y-coordinate greater than 224 (#E0), the routine at #927F (that is supposed to draw Willy's sprite to the Occupied Screen Buffer at #6000), over-shoots the bottom of the Screen Buffer Address Lookup Table (#8300-83FF), thus reaching code in the 'The game has just loaded' routine. There it picks up an address (specified at #8404) that corresponds to somewhere in cell-row 6 of page #CC of the code [amongst other addresses, which are mostly in the ROM and are therefore immune from being overwritten, although the stack address at #9CFE - as specified at #8402 - may also be overwritten in the process. I'm not sure whether that would have a detrimental effect on the operation of the program?] The affected addresses are overwritten by some of Willy's sprite's graphic bytes (which are stored in the range #8200-82FF), although the location in Room 7's data to which those graphic bytes are written, means that they are interpreted by the room-drawing code as attribute bytes. More specifically, values of '#3F' and '#F0' are written to #CCCB and #CCCC respectively. The former corresponds to a colour-attribute of 'White Ink on White Paper', hence the solid (non-Bright, non-Flashing) White block. The latter 'F0' corresponds to a colour-attribute of 'Flashing, Bright Black Ink on Yellow Paper'. Because 'F0' also corresponds with a graphics byte specified in the Room 7 data (the top pixel row of the Conveyor tiles), the Cell-Graphics Bug also kicks in, and so the right-hand errant block (at #CCCC) has a non-blank pixel pattern: pixel-rows 0-6 correspond to the 2nd to 8th graphic bytes specified for the Conveyor, whilst the final pixel row of the new block is a graphical representation of the attribute byte for the Nasty 1 tiles (04 - Green Ink on Black Paper). N.B. In terms of Willy's interaction with them, both of the newly-inserted blocks behave as Water cells. See attached rzx recording.