IRF

I think the fact that Willy can walk DOWN a ramp into an Earth cell (as in On Top of the House in the original game) is worth a mention in the JSW disassembly. It happens because the routine that checks for Earth blocks when he's trying to walk across a cell boundary, doesn't check for Earth blocks lying two cells below the top of his sprite when he is only occupying two cell-rows (see 36901 / 37012). Which is obviously a good thing when he's standing on two Earth cells (otherwise he wouldn't be able to walk along Earth platforms at all!), but it means that when he's got an Earth cell and a Ramp cell beneath him, the Ramp cell takes precedence when he's walking down. Also perhaps the fact that Willy can walk UP a ramp through an Earth cell above him is worth a mention (because there is no effective check for Earth cells above him, unless he's jumping). I can't think of an actual example of this in the original game, but whilst we're 'on top of the house', if you pop next door into Rescue Esmeralda, a single POKE will illustrate the point nicely. Simply take the single Earth block that sits under the conveyor and extend it downwards by one cell (POKE 52790, 8). Of course, this would make walking up the ramp in Rescue Esmeralda a one-way route, were it not for the 'Don't Mind Your Head' bug allowing Willy to walk back down the ramp, during which manoeuvre the same Earth block is at head-height on his left!

Ignore that statement in bold, I was having a senior moment - of course, he can drop through the crumbly platform on the left and jump up through the conveyor to access it from beneath! Thus he can make the item disappear and complete the screen!

As I said, I haven't tried it myself, I just have a memory of reading it somewhere (which doesn't in itself mean that it's true!) It's easily checked, especially with that POKE - which incidentally, will set the Screen Flash off (and increment the lives) every time an item is collected! N.B. Care might be needed in case the remaining lives display runs off the edge of the screen and causes corruption elsewhere? Anyway, even if the points are allocated, I still think the fact that the item doesn't disappear from the display is worthy of shifting to the Bugs section, and a POKE provided to shift it one cell lower.

I believe it should be possible to modify the code at #8B51-8B5B, such that the pitch of the tune doesn't deteriorate with loss of lives, but instead based on the value of the Game Mode Indicator at #85DF. The idea being that the tune reflects the fact that Willy gets more 'sick' the closer he gets to the toilet dash!! The SUB and NEG commands at #8B56-8B59 would not be necessary (unless you wanted the pitch to increase through the Game Modes), as the adjustment would be made based on a variable which increments throughout the game, whereas the number of lives of course decrements. However, I anticipate that one or two extra RLCA commands (on top of the existing two) could be useful to give the decrementation of the tune pitch a wider 'range' (given that the Game Mode Indicator only ever reaches a value of '3'). e.g. one extra RLCA (three in total) would mean that each Game Mode increment would yield a drop in pitch, equivalent to that which occurs when Willy loses two lives in original JSW. But since the SUB and NEG commands use two bytes each, whereas each RLCA only uses one byte, there should be a net saving in bytes from modifying the code in this way. P.S. This would also mean that the pitch deterioration would still be showcased in a walkthrough recording, even if the player had used 'rollback' to avoid apparently losing lives!

Good work, Richard! I have a couple of other suggestions for the next update (on top of the 'disrespectful Monk in The Chapel, which I mentioned in the previous thread): In the unused code section of the JSW disassembly: http://skoolkid.github.io/jetsetwilly/maps/unused.html You could also mention the unused Screen Flash routine, which is embedded in the Main Loop (1), but always jumped (unless you POKE the value of the Screen Flash Counter at #85CD to a non-zero value). It's a relic from Manic Miner, where it kicks in every time Willy gains 10000 points, I believe. And talking of points gained in Manic Miner, there's an entry in the Trivia section of the MM disassembly here: http://skoolkid.github.io/manicminer/reference/facts.html#thePersistentItem "The item below the portal in The Sixteenth Cavern does not disappear if Willy leaves it till last and collects it by falling on it from above. The reason for this is that the portal is opened as soon as Willy collects the item, and the screen is not refreshed before he moves on to the next cavern." Of course, he has to leave that item till last in order to be able to complete the screen! But that's not my substantive point... I think I read somewhere that, not only does the item not disappear when he collects it, but he doesn't acquire the usual 100 points from doing so! i.e. as soon as Willy enters the portal, the game moves on to count down the remaining air - which in itself updates the points count - but it bypasses the code that assigns 100 points per item collected. That probably isn't readily apparent noticeable when there's a lot of air left, and so the score goes up substantially anyway, but one way to check would be to complete the rest of the screen, then wait above the portal until the air has nearly expired, before dropping into the portal at the last minute. I should point out that I haven't actually checked this myself yet! But if indeed Willy can't acquire points from collecting this item (unless he collects it 'too early' which then means he's stuck, and has to sacrifice a life and start the screen again), then I think it should be classed as a 'Bug' rather than a 'Trivia' entry. Furthermore, it should be quite easy to fix by providing a single POKE to shift the item downwards by one cell-row. Then Willy will only collect it after he's dropped sufficiently far through the portal so as not to activate it straight away. Upon landing he will get the 100 points, the item will disappear and the portal will start flashing. Then he can simply back jump up into the portal and head on to the next cavern!

I've just noticed that Richard has made quite a few updates to his Jet Set Willy disassembly, and also to his Manic Miner one. Thanks for the credits, Richard - and also for the handy hint regarding the Solar Power Generator in MM! One thing I just thought of for the next update - you mentioned that the Saw in Cuckoo's Nest only uses four of the eight available frames of animation. However, there's also the 'disrespectful Monk' in The Chapel, who always faces away from the altar!

Looking again at the above, there are two bytes which are common to both chunks of code, and located at the substantive end of each ('A9 4F'). So perhaps the new code could be two bytes shorter, jumping back to resume working through the main 'Draw the guardians' routine at the 'A9' command, instead of at the '71' LD (HL), C instruction (at #91FD)? The more efficient code would go as follows: 'New' code at #96F4 to #9709 [or wherever]: 7e e6 38 c2 f2 91 dd 7e 01 e6 0f c6 38 e6 47 4f 7e e6 38 c3 fb 91 Existing code at #91ee to #91fa edited as follows (the address in italics can be changed accordingly to point at the above 'new' code; the spare NOPped out byte is in bold): c3 f4 96 00 dd 7e 01 e6 07 4f 7e e6 78 That is then followed by the re-entry point from the 'new' code, at #91fb: a9 4f ... etc [Of course, if the additional code could be consolidated to sit inside the main loop, or somewhere within 128 bytes of the source routine, then two of the absolute jumps could be replaced with relative jumps, and one of the absolute jumps could perhaps be done away with altogether, providing a further saving of up to five bytes. But the routine is in quite a 'tight' part of the code.]

Oh, one other thing I meant to mention about this beforehand, but forgot - whilst the patch I ended up with retains the quirky ability to jump through overhead Earth cells, my initial version (which didn't allow Willy to progress onto a ledge under an Earth cell until the last minute) did add quite a bit more peril to the jump over the barrel in Ballroom East, and to crossing the Banyan Tree from right to left; I did rather like the extra challenge it brought to those screens. :excl:

Other options: 'Guardian Corona' - that's probably once again more specific to a brighter effect, though. 'Guardian Aureole'? Definitions of Aureole: 1. "a circle of light or brightness surrounding something, especially as depicted in art around the head or body of a person represented as holy." - i.e. Brighter than the host medium. 2. "another term for areola (that being the pigmented skin surrounding a nipple)." - Definitely denotes a darker shade in this case! 3. "[GEOLOGY] the zone of metamorphosed rock surrounding an igneous intrusion." - This can appear as either brighter or darker I believe, depending on the mineral content of the host rock before and after being metamorphosed. I think I've got to the nub of the answer! (Excuse the anatomical pun!)

That also brings to mind 'floaters', which are blobs of vitreous matter in the eye that can cause dark 'shadows' in the field of vision, particularly on bright sunny days.

I think you're right! If you do include an entry for it, you should probably include a note warning the player of the potential pitfalls of using the former POKE alone (i.e. without 'dipping in and out' via the latter POKE, the game effectively becomes uncompletable!) That way if someone loads up the game in the original hardware, and are unable to hack the code to reverse the change mid-game, then they have been forewarned!

Regarding the above, the POKES could be applied in-game (e.g. in SPIN), as long as the player also had available the set of POKES that reverses the change to the game engine - which they can then insert whenever they encounter a screen that requires Willy to fall through a crumbly platform in order to complete it. i.e. To turn Crumbly platforms OFF: POKE 35618, 0 POKE 35619, 0 POKE 35620, 0 POKE 35638, 0 POKE 35639, 0 POKE 35640, 0 Then to turn Crumbly platforms back ON again: POKE 35618, 204 POKE 35619, 186 POKE 35620, 139 POKE 35638, 204 POKE 35639, 186 POKE 35640, 139 Richard, would you consider the above to be two sets of six POKES, or one set of twelve (which would break your unofficial 'maximum ten POKES' rule)?

There is another definition of aura which has a 'darker' connotation: "a warning sensation experienced before an attack of epilepsy or migraine." Most instances of the bug (certainly all instances in original JSW) do tend to be a Bright field on non-Bright background cells, so the 'aura' is usually Bright. Googling 'dark aura' threw up this!: http://powerlisting.wikia.com/wiki/Darkness_Aura On the whole, aura seems more generic (or perhaps that should read less specific) than either halo or shadow. 'Guardian Halow Bug'? :huh: I did consider 'Guardian Brightness Bug' too, but I agree it's less interesting.

Danny, at the start of this thread you seemed to suggest that these routines of yours didn't quite do what you had originally anticipated? I wonder if the following alternative code implements what you were initially trying to achieve? (I understand you're happy with the resulting product that you ended up with, so this is purely for the point of academic discussion.) 3A CB 85 - LD A, (#85CB) - load the 'tick counter' to the A register E6 1F - AND #1F - the AND operand (00011111 in binary) is 255 (#FF) minus your chosen operand of 224 (#E0) C8 - RET Z - note that the conditionality of the check upon which the Return command is based, is the opposite to the C0 command in your PV 3A CD 85 - LD A, (#85CD) - load the current value of the Screen Flash Counter from #85CD to the A register 3C - INC A - increment the A register by one 32 CD 85 - load the value of the A register back to the Screen Flash Counter at #85CD C9 - RETURN (With the value of the Screen Flash Counter at #85CD initialised to a high value such as #FF, so the Screen Flash effect can be witnessed for a long period.) The above has the effect of slowing down the screen flash routine, so that the colour change only happens once every 32 'ticks' (or every 8 'dance steps'), instead of every tick. Other than the speed, it cycles through the colours in the usual way. If the operand of the AND command was set to #3F (which is 255 minus 192, or #FF minus #C0 which was your other chosen value for the AND operand), then the colour change would occur every 64 ticks. Furthermore, AND 0F would cause the screen colour to change every 16 ticks; AND 07 every 8 ticks; AND 03 every 4 ticks; AND 01 every 2 ticks; AND #7F every 128 ticks. I still intend to provide a detailed explanation of how it all works, but hopefully the above gives you some insight!

I've sought a third opinion (in a PM) from Richard/SkoolKid on the 'Guardian Aura' option (because he's preparing updates to his disassembly which may include a reference to it). 'Guardian Halo/Shadow' is a bit wordy, although I agree it encapsulates the phenomenon well.

Danny, I believe you have placed the Music Note Index from 85E1 there, NOT the Music Flags from 85E2. It might be worth bearing in mind for the readme.

Danny, I believe both PV's amount to the same thing, except that one lasts longer than the other (due to the C0 versus E0 operand), one 'hardly flashes' because the value of another variable is set so low (thus when it is loaded up to the Screen Flash Counter, it doesn't take long to decrement to zero), and of course you've modified one version so it can be adapted differently for different rooms. But I think they're the same in essence. It's late now but I'll try and give a detailed description of how they work tomorrow. For now, I'll just point out that the reason you need to add 1 to your chosen colour value, is because the original Screen Flash routine decrements the current value of A immediately before loading it up to the Screen Flash Counter variable, so you're effectively countering that.

I would say it's bad planning in the design of the game engine - as admitted by Matt Smith himself (who admitted it was supposed to be symmetrical)! Fortunately, I have now devised a bug fix which removes the asymmetry whilst allowing the original game to be completed AND retaining all those quirky features you know and love!!

But good highways planning ensures that one-way streets don't enter cul de sacs!

I'll have a read of that and a think later, and see if I can come up with an improved wording. :)

Once again, I'd beg to differ. You could equally blame the cells under his feet for not being Air cells for the reason he gets stuck? That would be ridiculous! The fundamental reason he gets stuck is because a bug allows him to progress (against the natural laws of physics) into Earth blocks, but only in one direction!

Richard, here is a small suggestion for your JSW disassembly 'to-do' list: in the entry for Willy's direction and movement flags http://skoolkit.ca/disassemblies/jet_set_willy/asm/34256.html perhaps you could add a comment that it is "Updated by the routine at 36307"? This would be in accordance with the format of most of the other entries for the game variables, and I think it would help the reader to understand why Willy can walk against the flow of a conveyor when he jumps onto it, but cannot do so when he falls onto it.

Or to put it in a way that's easy to follow during the game by watching the 'lives' indicator dancing in the status bar (assuming that the in-game music is on): With the AND C0 instruction in effect, whatever the thing that the PV makes happen, occurs [or doesn't occur, depending on the polarity of the 'check'] every tick during the first half of the first rendition of 'Rich Man' in every 256-tick cycle (sixteen 'dance steps'), and then doesn't occur [or does!] during the second half of the tune and throughout the next full tune rendition. Then the effect resumes at the beginning of the third rendition of the tune (lasting again for half the tune's length). AND E0 means that the effect only lasts [or is disabled] for the first quarter of the tune (eight 'dance steps'). N.B. Willy's lives make 64 dance steps (progressing through the four frames of animation sixteen times) during each 256-tick game cycle.

Danny, I forgot to mention that when I set the operand of the AND command to D0, I altered it from the original value which you had set of E0, which is one of the values that you mentioned at the start of this thread - and that's what made me wonder if it was indeed the Screen Flash Patch Vector that you were having trouble summarising in the readme?

I should point out that there is no conveyor nearby that can be blamed for the occurrence of the bug in Dr Jones... Dr Jones Bug.rzx