IRF

Could you perhaps squeeze a few more bytes out of the code so that EVERY room has one? (e.g. the spare 6 bytes in G127's data, if you haven't already used them?)

I guess that the need to 'return' is implicit in the above sentence, but it would be good to make it explicit in your guide. EDIT: Is the definition of a 'sub-routine' a section of code that is arrived at by being called up from elsewhere, and which therefore requires, by its very definition, to be terminated with a 'return'? I've been using the term to refer to certain parts (i.e. subsections) within a routine which don't need to be 'called up' as such. (For example, the 'Play a note of the in-game music' subsection of code within the Main Loop.) But that might have been sloppy use of language on my part? (It wouldn't be the first time!)

Danny, I believe that there is one aspect which you omitted to mention in your otherwise comprehensive (and much-appreciated) guide to inserting Patch Vectors. Namely, the fact that each Patch Vector should be concluded with a 'C9' Return command. You did explicitly point out that the Main Patch Vector ends with a 'C9' (which returns the program back to the main loop by default, for those rooms that don't have a room-specific Patch Vector). However, I think your guide should explicitly mention the fact that when a room-specific PV is called up, the relevant chunk of code should also end in a 'C9' command. (May I kindly suggest that you edit your initial post in this thread accordingly?) By the way, my ruminations on this have helped me to understand why the Main PV is called up from the Main Loop, rather than having been directly inserted into the Main Loop (which on the face of it would save four bytes: 3 for the Call and 1 for the Return). I still maintain that the Main PV could be inserted into the Main Loop (as per our previous discussion). However, it would mean that each and every room-specific PV would have to be terminated with a 3-byte Direct Jump command (or at best a 2-byte Relative Jump, if a particular PV's address happened to be within 128 bytes of the Main Loop), rather than a single-byte Return. So the notional 'saving' of 4 bytes, achieved by inserting the Main Patch Vector into the Main Loop, would soon be overtaken by the increased length of all the room-specific Patch Vectors!

By the way Danny, hopefully the bug fix will have 'liberated' you to consider changing guardians on Black screens in WNM to Bright ON, without fear of causing any instances of the Shadow Bug around guardians in the non-Black rooms.

I think I might have implemented it in that way in the first place, but when I came to typing it up for this article, I put the spare byte at the end, thinking that was 'neater'. (And I thought that if it had to be consolidated to sit alongside other spare bytes, to make good use of it anyway, then it wouldn't matter where exactly the spare byte was left.) However, as you've presumably realised Danny, if it's been left at the end of the section of modified original addresses, then it wouldn't be safe to keep it in situ and use it for a single-byte variable (such as the Music Flags). This is because the program would stumble across it after drawing every guardian in a non-Black room, and may take whatever the value of the Music Flags happens to be at that instant, and try to interpret it as a command code - with unpredictable and potentially disastrous consequences!! So your approach is better, Danny, as both of the alternative Guardian-drawing sub-routines bypasses the spare byte entirely! Thank you for pointing out this 'trick', which may be a useful general principle to apply elsewhere in the code!

Good question! I suppose - like inserting data into the unused addresses in the Rope Animation table - you could 'suck it and see'!

Actually, I've just noticed that the fix is even more comprehensive. The Swimming Pool has a Black background, but the Underwater Monk is walking amongst Inkless Water cells, which are of course non-Black (Cyan). If you edit original JSW and turn that Monk Bright Yellow, it has a Bright Cyan Shadow against the surrounding non-Bright Cyan Water cells. However, with the above patch in place, there is no shadow - the Monk is rendered non-Bright Yellow on this screen (unless the Water cells are set to Bright Cyan, in which case both the Monk Guardian and the pool's Water cells are Bright, so again no shadow!) But the same Guardian Class of Monk is seen in The Forgotten Abbey, this time in Bright Yellow!

What you call the "modified original code" is actually the 'new' code [although it's based on an unused routine left over from Manic Miner]. Whilst what you call the "new code" is actually the 'old' [original JSW] code, relocated! (I did it that way because the 'new' code is shorter, and therefore it - and a jump command to the new location - slotted nicely into the original location, without the need to carry out extensive consolidation of the existing 'Draw the guardians' routine.) Are you still following me? Good! On we go... The 'old' code (at the new location) actually starts at #96FA, as it is preceded by a check at #96F4: '7e e6 38 c2 f1 91'. The first three bytes of that selects the Paper colour of the current room's Air cells i.e. the screen's background colour. '7E' is LD A, (HL), which picks up the attribute byte of the cells in which a guardian is located; 'E6 38' is AND 00111000 (#38 expressed in binary), which selects Bits 3 to 5 (Paper colour) and ignores all the other bits of the attribute byte. Then there is a 'C2' (JP NZ) conditional absolute jump command, which returns the program back to #91F1 if the Air Paper is NOT ZERO (i.e. non-Black). Thus on the Black screens, the program proceeds as it always did (with both Bright and non-Bright Guardians potentially present, determined by the Brightness setting of each individual Guardian Class). Whereas on the non-Black screens, the Brightness setting of the guardians is determined by the Brightness setting of the screen's Air cells (as specified by the 'new' code, via an 'E6 78' command - AND 0111000). So the section of code that you thought was being bypassed is in fact the new element that fixes the 'Guardian Shadow' Bug! N.B. My first attempt at a fix only had that 'new' code in place [with the original JSW guardian-drawing code from #91EE-91FC removed entirely], which did indeed fix the 'shadow bug'. However, that placed limitations on the range of guardian colours that you could have present on the Black background screens - they could either all Bright or all non-Bright on a given screen, determined by the Air's Brightness setting. (Of course, on non-Black screens, you still cannot have both Bright AND non-Bright guardians without one or the other displaying a 'shadow' against the background - I don't think it is possible within the game engine to define screen cells that have Bright Ink and non-Bright Paper colours, or vice versa.) So to summarise, the final product - the code in the first post in this thread - calls up one of two sub-routines to draw the guardians onto a screen, and which one of the two sections of code is used is dependent on whether the screen's background (Air cells Paper colour) is Black or non-Black.

There are two chunks of unused code, each 42 bytes long, in the 'Rope animation table' set of data: http://skoolkid.github.io/jetsetwilly/asm/8300.html It would appear that these 84 bytes (at #8356-837F and #83D6-83FF) can be used for other purposes, without affecting the game.

Does anyone know if Richard Hallas is a member here?

Thanks Andy for merging these! They're all in the right order as well!

I thought I would include the link within the same post that now contains an Excel file which provides a hexadecimal translation of Richard's musical notes!

I've added a potentially useful Excel file to the original post in this thread.

Shout out to Andy (Spider) - I'm not sure whether or not this stuff should be in the 'Remakes' section instead? Also, I considered amalgamating the three tune-related threads into a single one, but I couldn't figure out how to alter the title of a topic (even one that I've created), or how to delete topics if they are defunct as a result of consolidating them into other topics. It that something that you or a moderator could do? I think a generic topic title like "Playing around with the in-game tune in JSW" would cover the longer/shorter/faster/slower tunes topics.

The standard in-game Jet Set Willy tune takes up 64 bytes. It is possible to alter the length of the code that the program selects when playing the tune, by a factor of 2 either way. So you could insert tunes that are either 32 bytes or 128 bytes in length. To play a 32-byte tune, simply alter the value of the byte at #8B48 to '3e'. (In original JSW, this will have the effect of just looping the first half of the 'Rich Man' tune, ignoring the second half.) To play a 128-byte tune, alter the value of the byte at #8B48 to 'fe'. You would then have to insert another 64 bytes of tune code immediately after the existing in-game tune - this would involve overwriting the [no longer necessary] 'security code entry' routine. (Otherwise the game will play 64 bytes of 'noise' - trying to interpret the 'code entry screen' data as a tune - before reverting back to the start of 'Rich Man'.)

To make the in-game music in Jet Set Willy play half as fast, change the value of #8B48 to 'fc' (i.e. the operand of the AND command at #8B47) and add an extra '0f' after the existing one at #8B49 (so that there are two consecutive RRCA instructions). N.B. To achieve this requires some consolidation to allow the extra byte to be inserted. However, if you don't mind losing the effect that deteriorates the pitch of the tune as Willy loses lives, then the 11 bytes from #8B51-#8B5B can all be NOPped out (filled with '00'), which is very handy for this purpose! If you are carrying out the latter change (removing the 'tune pitch deterioration' sub-routine), then you also need to alter the values of two other addresses - the '5a' instructions at #8B5F and #8B68 should be changed to '5e'. Other topics to follow: How to alter the code to allow for a tune that is twice as long (128 notes instead of 64), or half as long (32 notes).

I should clarify that the 'Guardian Halo/Shadow Bug Fix' doesn't eliminate the 'shadow' that occurs when a guardian's 2x2 square passes over Willy or other room elements (without a pixel collision, which is of course fatal), temporarily changing the Ink colour of part of Willy or the room elements that the guardian passes 'in front of'. It only prevents a 'square halo/shadow' against the screen's background (of the opposite 'Brightness Polarity' to the room's Air cells). i.e. an anomalous Paper colour within the 2x2 square (or 2x3 rectangle when the guardian isn't cell-row aligned).

To make the in-game music in Jet Set Willy play twice as fast, simply change the value of #8B48 to '3f' (i.e. the operand of an AND command) and NOP out (replace with '00') the byte at #8B49 (an RRCA instruction). To follow: How to slow down the in-game music...

Further Update: I have also fixed the problem described here: http://jswmm.co.uk/topic/184-guardian-aura-bug-fix/?p=7914 Update: for an optimised solution, see this post on page 3 of this thread: http://jswmm.co.uk/topic/184-guardian-aura-bug-fix/?do=findComment&comment=5587 ****** Here is a patch for the bug that is seen in Jet Set Willy in non-Black rooms, if a Guardian is present that has a different Brightness setting to the Air cells in that room. e.g. The Flying Pig in Emergency Generator. The following 'new' code should be added - I suggest you locate it between #96f4 and #970b: 7e e6 38 c2 f1 91 dd 7e 01 e6 0f c6 38 e6 47 4f 7e e6 38 a9 4f c3 fd 91 Then the existing code at #91ee to #91fc should be edited as follows (this is based on the suggested starting address for the new code listed above): c3 f4 96 dd 7e 01 e6 07 4f 7e e6 78 a9 4f 00 (The last byte is a NOPped out spare byte in the guardian-drawing routine.) The above patch is an amalgamation of two routines in the original Jet Set Willy code (one of which was previously unused, except in Manic Miner). It eliminates the 'Guardian Halo/Shadow' bug in non-Black rooms, whilst allowing a wider range of guardian colours (Bright and non-Bright) in rooms with Black screens). N.B. There is a simpler fix for the Guardian Halo/Shadow Bug that uses fewer bytes, but it would limit the colour palette of guardians throughout the game. i.e. with the simpler fix in place, all guardians on a given screen must be either Bright or non-Bright - even on Black screens where the Guardian Halo/Shadow Bug doesn't manifest itself. So for example, you would no longer see a Bright Red AND a non-Bright Red Monk in The Forgotten Abbey. Note also that the way the alternative guardian-drawing routine (a remnant from the Manic Miner code) is implemented, avoids the following bug from occurring: http://skoolkit.ca/disassemblies/manic_miner/reference/bugs.html#attributeCrash So the above fix really provides the 'best of both worlds'!

All in the same place, for convenience: http://skoolkit.ca/disassemblies/jet_set_willy/index.html http://skoolkid.github.io/jetsetwilly/ [The above in hex] http://skoolkit.ca/disassemblies/manic_miner/ http://skoolkid.github.io/manicminer/ [The above in hex] https://jswcentral.org/ http://www.binaryhexconverter.com/ http://www.miniwebtool.com/bitwise-calculator/ http://www.z80.info/z80oplist.txt http://www.z80.info/z80syntx.htm http://www.z80.info/z80code.htm http://www.z80.info/z80undoc3.txt http://www.z80.info/z80info.htm http://www.z80.info/z80undoc.htm http://www.z80.info/z80sflag.htm http://z80.info/z80flag.htm - T-States listed for each instruction http://www.worldofspectrum.org/faq/reference/z80reference.htm http://www.worldofspectrum.org/faq/reference/48kreference.htm http://www.worldofspectrum.org/faq/reference/128kreference.htm http://z80-heaven.wikidot.com/start http://www.breakintoprogram.co.uk/ https://chuntey.wordpress.com/category/z80-assembly/ http://www.worldofspectrum.org/ZXBasicManual/ http://jgmalcolm.com/z80/ http://www.worldofspectrum.org/Z80.html http://hallas.net/Software/music.htm I've also attached an Excel file with the values for each note (taken from the above link, Richard Hallas's document: 'A Miner Triad') converted into hexadecimal. Feel free to add! Musical Tone Codes in Hex.zip

So providing a single Earth cell two rows above the crumbly floor should allow Willy to jump through in quirky, logic-defying fashion!

Or if it was a quirky game, provide an 'innocent looking block' to jump through! (Does that work in MM?)

Ah, I hadn't thought of that. Still, it could be useful for other games that use the MM engine.

It's just struck me that the Pokes section of the Manic Miner disassembly could do with a Poke that stops crumbly platforms from crumbling. Could that be achieved by NOPping out all the commands that call up the routine at 35770?

I did think of Danny's point actually i.e. what if someone else gets there first? So by all means, publish it if you wish! Although maybe we could legitimately request that it's done in a 'low-key' manner? i.e. without posting a link on WoS saying "Look everybody, this is how to complete JSW The Nightmare Edition!" Perhaps I'm worrying too much - as Danny says, players are aware that rzx recordings are inherently spoilery! Anyway, well done on completing it Mickey!