IRF

I've never noticed that before. The original images (with two Bright, two non-Bright) can be seen here: http://skoolkid.github.io/jetsetwilly/asm/9B00.html I wonder if Metalmickey might want to tweak this in his 'as manufacturer intended' project?

Actually, the Main PV routine in later* Geoff Mode games is called from #89F2, with earlier calls to other routines shifted upwards (space is made in the code because the CALLs to the original Master Bedroom/Bathroom special code is actually enacted via patch vectors for those rooms). [* In earlier Geoff Mode games, the Main PV routine is called at the point where the Master Bedroom/Bathroom special code was originally called from, which means that the routines to Draw guardians/animate the conveyor/Draw items actually comes after the Main Loop PV is enacted in early games. Not ideal if you want to have special effects involving those elements, as Geoff presumably figured out in time for his later games.] Another step which you omitted to mention there, Danny, would be to edit the 'Kill Willy' routine at #90D6 so that the jump back into the Main Loop at the end of that routine points at #89F8, instead of #89F5. Otherwise, if you have a Patch Vector in a room which edits the value of the Airborne Status Indicator at #85D1 (which is also used later in the Main Loop to tell the program to remove one of Willy's lives, if it holds a value of #FF), then it actually can prevent Willy from losing a life. (Of course, you could use that 'quirk' to deliberate effect...)

Perhaps Willy is under surveillance - the authorities are suspicious as to how he gained his new-found wealth?

I've since noticed that John Elliott came up with a similar method on Yahoo! to control the lethality, although not in the context of fixing the bug.

I like it just as 'Special Branch', which isn't just a geographical descriptor but has an alternative meaning in its own right (which might not immediately be obvious to a non native English speaker?) https://en.wikipedia.org/wiki/Special_Branch

Maybe you're right regarding the contrast with 'Under', Danny. I agree that there's no need for a comma. Another example would be 'On a Branch Over the Security Guard'... As for centralisation of the room names, I think the convention we used in TNE was that if there are an odd number of characters, then we placed it slightly left-of-centre (e.g. 5 spaces to the left of the name and 6 to the right if the name is comprised of 21 chars, etc).

Tiny detail: in terms of the capitalisation of room names, I wonder if the word 'over' in 'On a Branch over the Drive' should be lower case, as it's a preposition like 'in' or 'on'. (Of course, the 'On' in the room name is capitalised in that particular room, because it's the first word of the name.) Then again, your new room 'One Flew Over the Cuckoo's Nest' does seem right with 'Over' capitalised; perhaps because it's the title of a film? What do you think?

If this is open to further enhancements, may I humbly suggest that you insert the item that was supposed to be present in the Swimming Pool in the original Jet Set Willy. Unfortunately, Matt Smith made the Air INK setting White in that room, which meant that the item was auto-collected upon Willy's entry to the room. The item even has a shape defined in the code for the room 'Swimming Pool' - an upside-down wine glass, in keeping with the game's theme of Willy clearing up after a party - but because of the bug, you don't get to see it. When JSW2 was made, the authors (of whom you are one, perhaps?) failed to pick up on the above point. It means that 'Swimming Pool' is the only room [other than 'Cheat'] which is not visited if you follow the 'recommended route' [in order to complete the game having collected every item], as listed here: http://www.jdawiseman.com/papers/games/jsw2/jsw2_route.html Which seems a shame - it's an iconic room, very atmospheric and a symbolic status of Willy's new-found wealth and his decadent lifestyle - when there is an item shape already defined (and it was obviously Matt Smith's intention that it should make an appearance in the game).

I suggest you consult Daniel Gromann's detailed readme for the Special Edition of Willy's New Mansion; it contains detailed disassemblies for various code changes, including doubling the in-game clock speed (and another suggestion of mine, namely writing the current room name one row lower on the status bar). :) Hmm... thinking out loud... the instruction at #9590 sets the internal 'ticker' to zero when Willy reaches the toilet. So if another check was made somewhere in the Main Loop: Firstly, check the value of the Game Mode (#85CF) - is it #03? (If not, skip to XxYy) Next, check the value of the 'ticker' (#85CB) - has it reached a certain value (anything up to #FF)? (If not, skip to XxYy) Then insert a CALL to your new routine XxYy The value in bold could be adjusted - #FF = 255 'ticks', which is just short of one in-game minute [or two in-game minutes if you've doubled the rate at which the minutes pass]. EDIT: It might be simpler to implement whatever it is that you have in mind, if it were to take place at the exact moment when Willy puts his head down the toilet, as you could just CALL your new routine directly from #9591. (I don't really see the need to reset the minute counter as the program currently does; it's extremely unlikely that Willy will reach the toilet during the narrow time window between 11:59pm and 12:00am!)

In 'Solar Power Generator', Miner Willy isn't always killed if he runs out of air supply at a time whilst he is standing in the solar beam: http://skoolkid.github.io/manicminer/reference/bugs.html#nineLivesInTheLight This is because the 'Solar Power Beam' routine calls up 'Decrease the air supply' as a subroutine eight times in succession (four for each character of Willy's sprite that the beam passes through in a given time-frame), without checking whether the air in the cavern has run out. As a result, the air supply can 'wrap around' past zero, causing the final character of air on the status bar to be replenished with another eight pixels! Anyway, I've come up with a twelve-POKE fix for this: At #88FC, insert '18 F4 E1'. At #8D89, insert '06 04 C5'. (Incidentally, the operand '04' is the number of times the Air Supply is depleted by the Solar Beam in the original MM; it could be altered to make the Solar Beam less deadly, or even more so!) [The CALL at #8D8C remains in situ.] Finally, at #8D8F, insert 'C1 CA FE 88 10 F6'.

Here are the POKES to ensure that Maria reacts to Willy's horizontal - rather than his vertical - position: POKE 37829,58 #93C5, 3A POKE 37830,211 #93C6, D3 POKE 37831,133 #93C7, 85 POKE 37832,230 #93C8, E6 POKE 37833,31 #93C9, 1F POKE 37834,201 #93CA, C9 POKE 38221,205 #954D, CD POKE 38222,197 #954E, C5 POKE 38223,147 #954F, 93 POKE 38225,19 #9551, 13 POKE 38226,48 #9552, 30 POKE 38231,18 #9557, 12 If you implement it, then credit should be given to Stuart Brady in the readme. Note that part of the patch is located at what was a spare place in the code: #93C5 to #93CA. But you might need to place it somewhere else (and adjust the CALL at #954D-4F accordingly) if those addresses have already been used for another purpose in your project? Whilst I'm on the subject of credits, would you mind giving me a personal credit (Ian Rushforth) for: the am/pm fix to the clock; the patch which prevents Willy from walking leftwards through head-height Earth cells; ensuring that the first note of the in-game tune is played at the start of each game; and the 'Guardian Aura' bug fix. (You mentioned it by referring to the fact that guardians have a 'glow' in the 'blue' rooms.) N.B. contrary to what you claim in the readme, this fix wasn't implemented in JSW The Nightmare Edition! We just made sure that all the guardians in non-Black rooms were non-Bright. However, that meant that all other instances of such guardians in the game ended up non-Bright, even where they appeared in rooms with Black backgrounds - so it was a workaround, not a fix, as it were. Also, the fix for the corrupted conveyor (and ramp) in The Nightmare Room was something that Stuart Brady and I collectively came up with when were were working on JSW The Nightmare Edition. (It was implemented in The Nightmare Edition, but - again contrary to what it says in the readme - I think it's still corrupted in the 2015 Bug Fix Edition, which predated the TNE project.) Finally, in terms of giving credit where credit's due, I believe that you've fixed these two glitches? If so, John Elliott deserves a mention for coming up with the patches: http://skoolkid.github.io/jetsetwilly/reference/facts.html#asYouWere http://skoolkid.github.io/jetsetwilly/reference/facts.html#theEncroachingRope (The latter is achieved simply by ticking the box for 'Adjacent Ropes' in JSWED.)

I think the Nightmare Room looks better for having a greater variety of animating Maria's. So my personal preference would be to keep the foot-tapping one. However, your query has led to me discovering another oddity in the original game code. The Red Maria (Guardian Class 49) has an Animation Mask setting of 03, which is capable of displaying in four sprite-frames. However, the selected Base Sprite in The Nightmare Room is 06, which means that only the Pointing Marias are actually used by the guardian. It makes me wonder if either (1) Matt Smith meant to use Base Sprite 04 (which would yield a four-frame Red Maria), or (1) Guardian Class 49 was intended to have an Animation Mask setting of 01 (for a two-frame Maria, those two frames being determined by the value of 06 for the Base Sprite i.e. the pointing ones)? As for the Monk in The Chapel, I did wonder if the intention was for him to face the altar constantly, but Matt got the thing backwards? I guess we will never know. However, having watched my Catholic Mother-in-Law 'genuflecting' in church (when returning to her seat after receiving mass, doing a funny half-bow whilst walking backwards into the pews), I think it would make sense for the Monk always to face towards the altar. Others may feel that the 'disrespectful' Monk is more 'traditional' (and I guess you could argue that he's turning his face away from the Demon which has taken over the place). So I don't have strong feelings* either way (or rather, between the three options). But just in case you do decide to implement him always facing towards the altar, that can be achieved by reverting to an Animation Mask of 03, and selecting a Base Sprite of 04. *The Saw in Cuckoo's Nest is a different consideration though - I really do think that was a rushed job, based on the fact that it was the final Guardian Class to be created by Matt i.e. the last defined one listed here: http://skoolkid.github.io/jetsetwilly/asm/A000.html#a378 (and sawing backwards makes even less sense than walking backwards!)

Or it could be implemented on a 'per room' basis - I think The Nightmare Room in 'WRN' might feature a backwards tune (to match Willy's backwards Flying Pig sprite)!

P.S. Reversing the order of the notes for the Title Screen tune can be achieved by just three POKES: - At #88A9-AA, insert '5D 86', to point the 'Title Screen' routine to the final note in the first instance; - At #96C6, replace the INC HL (opcode '23') with a DEC HL (opcode '2B') command, to make the 'Play the theme tune' subroutine select the notes in reverse order. However, this means that there is no longer a terminating 'FF' byte at the end (formerly the beginning) of the tune, so the program plays random notes (code interpreted as data) for some time, until it eventually chances upon a value 'FF' and proceeds to the Scrolling Message. (The WRITETYPER look-up table immediately precedes the Title Screen tune data in the code, so it isn't easy to insert the 'FF' marker here.) Again, you can test out the above by applying it to Andrew Broad's 'ylliW teS teJ', in which the order of the Title Screen tune notes have all been manually reversed (actually, the process might have been done automatically via software; perhaps "physically reversed" would be a better turn of phrase?) Applying the above code changes to the mirrored game file causes the notes to be played in the correct (original) order. ****** P.P.S. It would be fun to edit the code which normally generates the 'falling pitch' sound effect during the Scrolling Message, in such a way that the sound rises in pitch instead as the message progresses! I haven't investigated that in detail yet, but first thoughts are that a CPL or a NEG command could be inserted at or around #88DE, with some modification to the ADD A, #32 thereabouts (changing it to a SUB A and/or changing the value of the operand). EDIT: It can be done by adding a CPL ('2F'), immediately prior to the ADD at #88DE, and then making the latter an ADD A, #52 ('C6 52'). One additional byte needs to be inserted, which can be achieved by replacing the CP #01 at #88EA-EB with a DEC A ('3D') and shuffling down the intervening 10 bytes (12 bytes if you include the ADD command). It's quite a cool effect; strangely familiar yet quite different!!

Here's another quirky tune-related effect: to make the in-game tune play backwards, insert a CPL command immediately prior to the AND #7E command at #8B47 in the Main Loop. This requires a bit of consolidation in order to insert the extra byte, but I've just noticed a one-byte efficiency that can be achieved in this part of the JSW code. [Which would also be useful in implementing the effect of slowing the music down to half speed by inserting an extra RRCA instruction, as detailed in the second post in this thread.] The efficiency is as follows: At #8B4B, there is a LD D, #00 command, which takes up two bytes. But at #8B3C, there is a single-byte XOR A command which sets A to zero. So if a single-byte LD D, A command is inserted before the value of A gets altered from zero, then one byte can be saved overall - thereby allowing the above to be implemented. You can test this out by making the following quick alterations to the hex code of Dr Andrew Broad's game ylliW teS teJ (a.k.a. MIRRORJSW): - Clear the LD D, #00 from #8B4B-4C; - Shift the code from #8B47-4A along by two bytes, to occupy #8B49-4C; - At #8B48, insert a CPL instruction (opcode '2F'); - Shift the code from #8B40-46 along by one byte, to occupy #8B41-47; - At #8B40, insert a LD D, A command (opcode '57'). In the unedited version of MirrorJSW, the in-game tune already plays backwards - but I believe that Andrew achieved this by manually physically inverting the positions of all the 'notes' in the range of addresses #865F-#869E. (i.e. the value '56' at #865F in the original JSW is located at #869E in MirrorJSW, whilst the value '40' at #869E in original JSW occupies #865F in MirrorJSW'; the value '60' which was originally at #8660 is shifted to #869D in the mirrored game, etc.) By making the above changes to the Main Loop (which only require 14 POKES to achieve), you will find that the in-game tune gets reverted back to being played 'forwards' (with all the notes in the correct order) - thus proving the effectiveness of the solution which I have come up with for 'reversing' the tune.

However, she is tapping her foot... The yellow Maria on the right isn't animated at all - but if you made her animate, I fear that would also cause the Foot guardian to start flicking to the Barrel sprite and back again? (Since it shares the same Guardian Class).

You probably should re-upload the corrected file as V.5 to avoid confusion, especially now V.4 has been subject to recorded playtesting..

Probably the easiest way to fix the extra (unwanted?) item in A Bit of Tree, would be to edit the Item Graphic for that room (fill a pixel in), then you can see where the item is and delete it from the room layout.

I think the CP #FF at #96A3 could be replaced with an INC A (saving one byte). I previously mentioned some similar savings here: http://jswmm.co.uk/topic/196-dont-mind-your-head-while-walking-left-bug-fix-for-jsw/?p=5802 And I originally got the idea from J.G. Harston's second Pause Bug Fix, as listed here: http://mdfs.net/Software/JSW/JGH/Docs/Pause.htm (I still think that's the most elegant Pause Bug Fix, even though Jonathan has recently added SkoolKid's more byte-efficient solution to the list.)

I'll go for 'B'.

Now that I think about this, it is more of a fundamental intervention in the original game than I originally realised. It means that there is an escape from the 'MegaRoots' area without climbing back up through 'Under the Drive' - one of the trickiest manoeuvres in the whole game! That is if you're prepared to sacrifice a life after collecting the left-hand item in 'Tree Root'. Or to complete the game without losing a life, the player would have to pass through the Wine Cellar/Forgotten Abbey/Security Guard/Under the Drive/Tree Root route twice - once to access 'The Bunker' and again via the traditional exit up 'Under the Drive' and onto 'The Drive'. I think that is quite a major intervention if it's meant to be 'as author intended' [but filling in the gaps]. So on reflection, it would be better if the top of 'The Bunker' was closed off and 'The Bunker' was somehow made an 'in-and-out via the same entrance' type room. What do you think?

I think the unused item from The Attic is a pair of beer bottles stacked next to each other (on in front of the other, but diagonally offset so you can see both)? Final(?) tweak - the topmost item in The Bunker perhaps looks a bit odd floating in mid-air, without a supporting platform. (I realise that the items in the adjacent Tree Root are also defying gravity, but at least they're 'wedged' in a corner!)

I have to say I'm quite impressed with John Elliott's cunning use of an XOR followed by an AND command, in the 'Move the Horizontal Guardians' code in JSW64, in order to determine when to reverse the guardians' direction of movement. The traditional JSW code uses an AND gate - to pick the lowest five bits of Byte 2 of the guardian definition, and then compares it against the minimum or maximum x-coordinate (Byte 6 or Byte 7 respectively) using a CP command. However, that isn't possible in JSW64, because the highest three bits of Byte 7 are used as flags for Fast and Slow horizontal guardians. So an XOR command, and then an AND gate, is used as an alternative way to compare selected bits (0-4) for comparison - after that pair of operations, the zero flag is set if (and only if) the values stored in the lowest five bits of the pair of bytes under consideration, exactly match. EDIT: To clarify, load Guardian Definition byte 2 into A, XOR with Guardian Definition Byte 7, then AND #1F. The Z flag will be set iff the x-coordinates match.

The floor in The Hall uses Water cells (predefined, but previously unused in that room), instead of Earth cells? I can't see anything else at the moment. The new 'Hall carpet' isn't that subtle, so I'm guessing that there's something even more subtle somewhere? :huh: One other thought that I just had, in terms of utilising Matt Smith's original defined-but-unused graphics - I think the item shape from The Kitchen has a more meaningful form (in terms of the game story) than the one from Under the Drive (the former appears to be a champagne flute on its side, the latter seems to just be a random pattern). Perhaps you could use the Kitchen item shape in The Bunker (instead of the Under the Drive one), or alternatively in Special Branch (replacing the similar shape in there, which doesn't look 'quite right' - the stem seems a bit off-centre)? It's just an idea though, no biggie.

On top of things that have been discussed previously, I noticed the following :ph34r: : B)