Metalmickey Posted January 15, 2017 Author Report Share Posted January 15, 2017 You may as well insert the POKE that fixes the 'invalid grid location', even if you've hacked the code entry routine so that any code will do. It's only one POKE: http://skoolkid.github.io/jetsetwilly/reference/bugs.html#invalidGridLocation fairplay, only takes a minute ... i suppose i could look into having R9 asked for while i'm at it Quote Link to comment Share on other sites More sharing options...
IRF Posted January 15, 2017 Report Share Posted January 15, 2017 (edited) pretty much, just the one which i'm not going to bother with and that's the one where grid location R9 is never asked for (poor R9 .. 33 years and never being asked) :( Oh go on, you might as well fix it for completeness, using POKE 34556,180. Especially since the same POKE also prevents the invalid grid location from being called, as I referred to above! Edited January 15, 2017 by IRF Quote Link to comment Share on other sites More sharing options...
IRF Posted January 15, 2017 Report Share Posted January 15, 2017 fairplay, only takes a minute ... i suppose i could look into having R9 asked for while i'm at it The same POKE fixes both bugs. i.e. instead of picking up an invalid address, the same value of the system variable that generates a random grid location will point to R9. At least, that's my understanding. (Although I haven't yet got my head around exactly how the routine generates a random number?) Metalmickey 1 Quote Link to comment Share on other sites More sharing options...
Metalmickey Posted January 15, 2017 Author Report Share Posted January 15, 2017 Oh go on, you might as well fix it for completeness, using POKE 34556,180. Especially since the same POKE also prevents the invalid grid location from being called, as I referred to above! So would that mean that R9 has been disguised as D>? Quote Link to comment Share on other sites More sharing options...
IRF Posted January 15, 2017 Report Share Posted January 15, 2017 So would that mean that R9 has been disguised as D>? I think that Matt Smith got the operand of a COMPARE operation out by one byte, and if a certain value is picked up then the routine is sent slightly out of range. The codes are stored at #9E00 to #9EB2, but a SUBTRACT command overshoots and points the routine at the address #9EFF (i.e. it points one byte below #9E00, but the low byte wraps around whilst the high byte still holds the value #9E.) Metalmickey 1 Quote Link to comment Share on other sites More sharing options...
IRF Posted January 15, 2017 Report Share Posted January 15, 2017 (edited) One other thing which I've picked up, looking at that list of bugs. SkoolKid's fix for the conveyor and the ramp in The Nightmare Room rotates all eight graphic bytes for the conveyor downwards by one byte, and replaces the conveyor attribute byte with the final graphic byte of the ramp cells. Then rotates the byte that falls off the end of the conveyor graphic definition to fill in the gap at the bottom of the ramp cells. However, I came up with a slightly alternative version, where only the first four conveyor graphic bytes are moved along, the bottom four pixel-rows of the conveyor are unchanged, and the fourth pixel-row's byte (as set out in the original game code) is used to fill in the base of the ramp. The conveyor cell is almost identical in both variants (the only difference being in the fifth pixel-row), but I think that the ramp looks better in the version that I came up with. Have a look at the attached screenshot which I created (based on The Nightmare Edition, but it allows a useful comparison), and the images from the disassembly (as copied and pasted below), and see what you think? Very corrupted conveyor You might be thinking that the fix given above for the corrupted conveyors bug does not do much for the appearance of the conveyor in The Nightmare Room. Perhaps that's because the real problem with this conveyor is that its attribute byte and graphic data - which should occupy addresses DDCD-DDD5 - appear to have been shifted by one byte back to DDCC-DDD4 (overwriting the eighth graphic byte of the ramp tile). If they are shifted along to the right spot, the conveyor takes on a much more reasonable appearance: http://skoolkid.github.io/jetsetwilly/images/scr/conveyor29_before.gif http://skoolkid.github.io/jetsetwilly/images/scr/conveyor29_after2.gif Before After In addition, if the byte at DDD5 (0x55) is shifted back round to DDCC it seems to fix the appearance of the ramp tile (by filling the gap at the bottom): http://skoolkid.github.io/jetsetwilly/images/scr/ramp29_before.png http://skoolkid.github.io/jetsetwilly/images/scr/ramp29_after.png Before After Edited January 15, 2017 by IRF Metalmickey 1 Quote Link to comment Share on other sites More sharing options...
IRF Posted January 15, 2017 Report Share Posted January 15, 2017 (edited) Oh, and have you implemented the POKES that fix this? http://skoolkid.github.io/jetsetwilly/reference/facts.html#asYouWere It's quite simple, just reset the values of #85D0 and #85D2 to zero during the course of the 'Display the title screen' routine, along with all the other variables that are initialised at the start of that routine. Then Willy will always be sitting at the back of the bath facing the tap at the start of every game, no matter what his stance was when the previous game ended! In fact, it can be done without calling up code from elsewhere, if you slot the commands in in place of the ones that reset the unused Screen Flash Counter and the Inactivity Timer (assuming that you've deactivated the Auto Pause function and the Screen Flash routine remains unused). I.e. insert 'D0' at #87D2 and 'D2' at #87DB. Edited January 16, 2017 by IRF Quote Link to comment Share on other sites More sharing options...
IRF Posted January 16, 2017 Report Share Posted January 16, 2017 (edited) Final suggestion for tonight: are you editing the game in John Elliott's JSWED? If so, I strongly recommend that you implement the Adjacent Ropes (New) patch (just tick the box on the Menu screen when you first open the file in JSWED, and save). It fixes this bug: http://skoolkid.github.io/jetsetwilly/reference/facts.html#theEncroachingRope Edited January 16, 2017 by IRF Quote Link to comment Share on other sites More sharing options...
IRF Posted January 16, 2017 Report Share Posted January 16, 2017 Actually this is my final suggestion. I've scoured both the 'Bugs' and 'Trivia' lists in SkoolKid's disassembly and there is one more thing for which POKES are readily available - the 'Maria's dodgy depth perception': http://skoolkid.github.io/jetsetwilly/reference/facts.html#mariasDodgyDepthPerception Let us know if that's something you would like to fix, and I'll dig out the POKES (for which the credit goes to Stuart Brady of FUSE). Quote Link to comment Share on other sites More sharing options...
IRF Posted January 16, 2017 Report Share Posted January 16, 2017 One other minor bug (not documented by SkoolKid) - the very first note of the in-game tune is missed out at the start of the game. The program keeps track of where it's up to with the tune, via the Music Note Index (#85E1), which is incremented during every pass through the Main Loop (see #8B43). However, #85E1 is incremented before its value is used to determine which note to play, so the first note is missed out until one rendition of the whole tune has been played. The value of #85E1 is initialised to '00' at #87CE. If it is initialised to 'FF' instead, then the first note of the tune is picked up at the beginning of each game. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.