IRF

Have you ticked off all the entries on this list:? http://skoolkid.github.io/jetsetwilly/reference/bugs.html

I'm happy to report that I've cracked this particular nut! And I'm especially pleased with the method that I came up with to switch between am and pm, and back again (rather cunning, if I do say so myself!). Please see the attached file. For demonstration purposes, I've NOPped out the byte at #8A51 (previous value was #59), so that the clock is updated every time-frame (every 'tick' of the game's internal clock), rather than every 256 'ticks'. If you load up the file, you'll see the clock racing through the numbers! Obviously, that address should retain its proper value in a normal game file. The substantial changes are at #8A81-#8A96, and at #9700-#9708 and #9710-#971E. Mickey, you may have to find alternative locations for the stuff in the #97XX range if you've already used them for other purposes. By the way, my initial attempt didn't include the extra code at #9710-#971E (which replicates #8A31-#8A3C). When I ran the program to test it, everything worked fine at noon, and the game terminated at the right time (progressing to 'Game Over' as it should, not the Title Screen). However, the clock display didn't update to '12:00am' (midnight) when the 'Game Over' screen kicked in. I managed to fix that as well though. I realised that, even though the value of the digital clock is updated internally before the jump to #8C4A, the Main Loop prints the digital clock display onto the screen before the digital clock is updated. Thus I had to replicate the 'Print the current time' commands just before the jump to Game Over. (There may be a more efficient way of doing this by inserting the 'Print the current time' code into a sub-routine, but it's probably more trouble than it's worth unless you've got a critical shortage of spare addresses.) am to pm fixed.z80

Another feature of the patch that I've just thought of - it allows Willy to jump rightwards and land on a platform that is up to four cell-rows below his starting position, if (but only if) he bangs his head on an Earth cell on the way down! (A feat which he could already achieve jumping leftwards.)

As I said before, SkoolKid's patch is better than the one I came up with, but he only provides POKES in decimal. I tend to think it's easier to understand how they operate in hexadecimal (although emulators such as SPIN don't allow you to enter POKES in hex, which is a pain). To give you a hand, I've converted SkoolKid's POKES for this into hexadecimal, and I've also made the address for the 'remote' part of the patch more generic, so that you can slot it in wherever you know there's a space (only 6 contiguous bytes in this case) in the code. #9634 Yy #9635 Xy That the operand of the conditional Jump command at #9633 (written in the usual 'Little-endian' format). Then at the jump address #XxYy write: CB 4C CA B6 90 C9 (Assuming you decide you want to fix the bug after all!)

Out of interest, I just playtested 'Dr No', with the check for Earth cells to the right of James' head disabled. (It was a 'quick and dirty' test; I didn't implement the full patch, I just NOPped out #90A8; so in theory James could also walk through head-height Earth cells on both sides, although the opportunity to do so doesn't present itself in Dr No.) I was correct in my suspicion that attempting to jump rightwards over Honey Ryder whilst halfway along the conveyor, taking advantage of the intermittent pairs of non-Earth cells in the overhead platform, does now cause James to fall to a standstill on the conveyor, even if you keep the Right key depressed. However, it is possible to reach the lift at the bottom-right, if you run up the conveyor very closely behind Honey Ryder, and jump just before she turns round at the right-hand end. That way, James has cleared past all of the overhead Earth cells before he attempts the jump. But you have to wait till Honey has traversed the conveyor three times (first left, then right and left again) before you set off. If you go too early (on the first occasion that Honey starts to go right), then you hit the side of the lift (fatally) just after you've jumped over her. I then went on to complete the screen, but because of the extra delay involved in waiting for an extra 'Honey cycle', the time constraint is tighter, and it would be easier to run out of air supply before reaching the portal. It's not too critical though. ****** So in summary, the patch doesn't affect the completability of the screen in this particular example, but it does serve as a reminder of the danger of 'unexpected consequences' when you're making any changes to the game mechanics (or to the game engine in general)!

Although the SkoolKid fix jumps to the location of Room 61-63. So you'd have to amend it to jump elsewhere. Also, the location SkoolKid chose was immediately followed by a Return command (he did that to minimise the number of POKES). So if you are inserting the fix but putting it elsewhere, make sure to add a C9 at the end of the 'remote' part of the code!

SkoolKid has a more efficient patch for that one (see the Bugs section of the SkoolKit disassembly).

Another bug that may be best left unfixed is the one where a Fire cell at the top of the room can kill Willy if he falls off the bottom of the screen directly below it. That can be quite usefully applied to prevent falls into 'Infinite Death Scenarios'!

By the way, I came up with a 'proper' fix for the 'Sticky Bed Bug', involving swapping around some of the chunks of code in the 'Move Willy (2)' routine. (Off the top of my head: place #8F05-#8F0C before #8EFA-#8F04.) However, turning the Conveyor action of the bed to 'Off' does the trick more simply, and since Willy can't really access the bed anyway, it's probably not worth the hassle of shifting code around. In any case, it's a matter of debate whether it's a 'bug' or a 'quirky feature'! (I can perhaps imagine a teenage Matt Smith thinking: "If you play with Willy for too long, you end up with a sticky bed!!" )

Here you go, Danny - better late than never!: Moving Left #9032 C3 00 97 #9700 B7 ED 52 3A D1 85 FE 01 20 06 3A D5 85 B7 20 05 3A B2 80 BE C8 C3 35 90 Moving Right #90A1 B7 ED 52 #90A4 C3 18 97 #9718 3A D1 85 FE 01 20 07 3A D5 85 B7 C2 A9 90 3A B2 80 C3 A7 90

I thought I should consolidate all of my proposed changes that fix this bug into one post, for easier reference: #91EE to #91FA edited as follows: C3 Yy Xx 00 DD 7E 01 E6 07 4F 7E E6 78 where #XxYy is a suitable address where there are 19 spare contiguous bytes. Then at #XxYy: 7E E6 38 C2 F2 91 4F DD 7E 01 E6 0F C6 38 E6 47 C3 FB 91

Did you have any luck with this one in the end? I can provide a few pointers if necessary. :) (I've just realised that the area of code which I previously suggested for this fix, overlaps with the addresses that I put forward last night for the head-height Earth cell patch! :blush: ) EDIT: This might help: http://jswmm.co.uk/topic/184-guardian-aura-bug-fix/?do=findComment&comment=5587

Please see the attached file, in which I've applied my patches that: - Allow the program to detect an Earth cell to the left of Willy's head when he is walking (but not when he is jumping); - Suppress the detection of an Earth cell to the right of Willy's head when he is jumping (but it is still picked up when he's walking). Some credit goes to Dr Andrew Broad for helping to devise the concept for this hybrid solution, which provides the 'best of both worlds' because it: - Fixes the asymmetry in Willy's walking behaviour; - Prevents Willy from getting stuck forever in clusters of Earth cells (e.g. inside the elephant's head in Dr Jones), or in other situations (such as if he exits Forgotten Abbey in a certain way: http://skoolkid.github.io/jetsetwilly/reference/bugs.html#stuckInTheWall ); - Retains the quirky behaviour when Willy jumps leftwards (which is necessary to allow him to navigate around The Wine Cellar, and to return along the top platform of Ballroom East); - Introduces the same quirky jumping behaviour when Willy leaps rightwards (for example, he can now exit from Emergency Generator to the Priest's Hole by jumping from the right-hand stack - although he can't progress any further than that, so it doesn't facilitate a sneaky shortcut down the East Wall!) I've tried to optimise the patches a bit (although more efficiencies could probably be found!) The code changes are as follows. I've suggested that the new code could occupy the spare addresses at #9700 to #972B, but you may need to change that [and therefore the bytes highlighted in bold] if you've already used those locations for other patches: Moving Left #9032 C3 00 97 #9700 B7 ED 52 3A D1 85 FE 01 20 06 3A D5 85 B7 20 05 3A B2 80 BE C8 C3 35 90 Moving Right #90A1 B7 ED 52 #90A4 C3 18 97 #9718 3A D1 85 FE 01 20 07 3A D5 85 B7 C2 A9 90 3A B2 80 C3 A7 90 The new patch ends at #972B. ****** On a separate matter Mickey, did you fix the conveyor (and ramp) in The Nightmare Room in your project?: http://skoolkid.github.io/jetsetwilly/reference/bugs.html#veryCorruptedConveyor The fix described in the above link goes further than the Cell-Graphics Bug patch. Stuart Brady and I share the credit for spotting this glitch. (Actually, if you apply the fix - which involves shifting a few bytes back in the code by one byte - then the Cell-Graphics Bug in this particular room is fixed even if the CGB fix isn't in place!) Earth cell symmetry restored.TAP

If you're not careful you can get stuck in the elephant's head in Dr Jones because of the 'Don't mind your head' bug!

I've not seen a fix for the am/pm bug. It's something which I thought I might have a go at some day, but I haven't got round to yet. :blush: Andrew Broad fixed it in a sense, by introducing a 24-hour clock. However, I'm not sure that fits in thematically with Willy's creaky old mansion! :ph34r: ****** I have a couple of other suggestions, if they're not too late... :mellow: In terms of 'As Manufacturer Intended', have you fixed the bug which causes the asymmetry in Willy's horizontal movement? I recall reading an interview with Matthew Smith, in which he said that Willy's movement in JSW was meant to be symmetrical (as it is in Manic Miner). So fixing that would seem to fit the bill of 'as manufacturer intended'. :huh: You'd have to be careful not to end up making some of the jumps in the likes of The Wine Cellar impossible though. :excl: I came up with a 'hybrid' fix that provides the best of both words, although I haven't got round to disassembling it yet (yet another thing on my 'to do' list!) EDIT: Here's a link, if you're interested: :) http://jswmm.co.uk/topic/196-dont-mind-your-head-while-walking-left-bug-fix-for-jsw/?p=3999 ****** Final query: what did you do to fix the Conservatory Roof bug (i.e. the uncollectable item)? The 'official' fix* simply removed a Fire cell, but it still left another item requiring a 'kamikaze' manoeuvre to collect it. :o Andy (Spider) devised a good fix which resolved that from a 'gameplay' perspective, but it involved separating the Fire cells and items from each other. :unsure: I take the view that, from a visual point of view, the Fire cells and items in Conservatory Roof should all be paired up (as per my profile pic!) To my eye, each little 'gremlin' is clutching a beer bottle (with a black label on it) - their left arm is wrapped around the bottle as part of the item graphic (whilst they're swinging from the roof structure with their right arm) - and they appear to have drunken grins on their faces! :P I eventually came up with a layout that gives all four items an accompanying nasty, yet which allows them all to be collected without losing a life! There's a screenshot of my suggested layout in the pertinent topic. ;) ****** * In relation to the 'official' fixes, they were only 'official' in the sense that Software Projects took the POKES that the first people to complete the game came up with (to enable them to do so), and then released them retrospectively to the wider public. So I don't give them that much credence really - particularly the one that relocates the invisible, unreachable item from First Landing to The Hall, without even bothering to make it visible! :blink:

Yes, the new caverns are most intriguing! Do you have a copy of a playable file you could share with us please?

Oh, and an explanation (of both the bug and the fix) will still follow - in fact, it was when I went to type up the explanation that I got distracted by noticing the potential for further 'overspill' of Willy's graphics. (Fortunately, there are three contiguous unused bytes available for the POKES, whose addresses are of the correct format, and which lie just beyond the furthest potential reach of the corruption!)

My apologies, the previous POKES didn't entirely fix the problem. I've just discovered that the corruption is potentially more far-reaching if Willy jumps up off the top of a cavern, from a position four cell-rows below the top, compared with if he falls off the bottom. With the previous version of the POKES that I provided, this caused a permanent, although non-fatal, corruption of one of the right-facing Toilet sprite-frames in "Eugene's Lair". Therefore I've amended my previous post, tweaking some of the POKES slightly. The code corruption should be fully prevented this time.* N.B. If you previously downloaded the zip file which I attached to my previous message above, then please delete it and re-download it with the correctly functioning POKES in place. (There were previously two downloads, which I suspect that was Andy [spider] and Danny?) (*Except for a brief temporary glitch that occurs at the 'Screen File' level (#4000-#4FFF) in the lower half of the screen, below Willy in cell-row 10, pixel-row 1 - a pair of Willy's graphic bytes is briefly drawn as he jumps off the top. However, since the filled-in pixels don't appear at the buffer level, they can't collide with any guardians, so this doesn't affect the gameplay. Note that this temporary glitch can also occur in the original game engine, without the POKES, if Willy jumps off the top - although it isn't visible if it coincides with Air cells and if the Air INK and PAPER colours match, or if it coincides with graphic bytes that are already completely infilled.)

I suppose to have truly fixed the clock properly, the display should change from 11:59pm to 12:00am (i.e. midnight) just as the foot is coming down to squish Willy on the Game Over screen.

You mean the game shouldn't run on till 1am?

Ending the game at noon im TNE meant that we never got round to resolving the am/pm thing. I'd be interested to see what you come up with!

Some thoughts - I hope they are of assistance... Surely the values #09 and #BE only come into consideration, because they are the Z80 op-codes for two of the instructions that are inserted by SkoolKid's POKES? Now, if you insert the POKES at the addresses which SkoolKid suggests, it just so happens that they overwrite the operand of an (unused) Call instruction - but I don't think that Call command (at 65317 / #FF25) is ever executed, and I don't believe that #BE09 [bear in mind here that low bytes come before high bytes in 'Little-endian logic'] was ever intended as a destination address!

I'm not sure, but #BE09 is mid-way through the guardian graphics data, so I'm not sure what the purpose of Calling that address is?

This should be useful for anyone designing games based on the Manic Miner game engine, who wish to have the option of Willy jumping up beyond the top of caverns (appearing at the bottom), or falling off the bottom of caverns (appearing at the top) - without fear of causing corruption of the game code. (In the original Bug Byte MM release, this bug affects the layout data of Cavern 07). Fixing the bug can be achieved using five POKES. Three contiguous spare bytes at #841C-1E are used for this. (Note that the other spare byte at #841B should retain its original value of #30, or else be NOPped out.) In hexadecimal: POKE #8405, #1C POKE #8406 #84 POKE #841C, #C3 POKE #841D, #CC POKE #841E, #85 In decimal: POKE 33797, 28 POKE 33798, 132 POKE 33820, 195 POKE 33821, 204 POKE 33822, 133 I've tested these out and they do the job. See the attached files - one is original Manic Miner (Bug Byte version), with a hole created in the floor of the Central Cavern. Drop Willy through the hole [he dies], then teleport him to 'Miner Willy Meets the Kong Beast' [type 6031769, then press 1+2+3+6 simultaneously] to see the corruption in action. EDIT: You can also see what happens when Willy jumps up off the top of the screen, thanks to an additional platform placed four cell-rows below the top of the Central Cavern. I've also changed the Air INK in Central Cavern to Yellow - note the brief, temporary & harmless graphical glitch below Willy (in pixel-row 1 of cell-row 10), just as he passes the top of the screen. (N.B. This only occurs when Willy jumps up from the new platform located four rows below the top, not from the platform located three rows below the top - I only added the latter platform in order to break Willy's fall, so that the top-left of the cavern can be accessed quickly and safely by dropping down from the start position at the bottom-left.) Then the second file is the same as the first, but with the above POKES applied. Repeat the exercise (fall through the hole, then make your way to Kong Beast), and Hey Presto! - there is no screen corruption [EDIT: other than the temporary, harmless effect noted above] and the bug has been fixed! I'll provide an explanation of how this works when I have more time. UPDATE: For the Software Projects version of the game, the bug causes corruption of the horizontal guardians in Room 8, which can soon prove to be fatal and prevent the game being completed. This variant of the bug can also be fixed, but one of the POKES is slightly different - swap the fourth POKE above for this one: POKE #841D, #D2 or POKE 33821, 210 MANIC Corruption Fix.zip