Jump to content
Jet Set Willy & Manic Miner Community

JSW As Manufacturer (probably) intended .. kind of...


Metalmickey

Recommended Posts

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

Link to comment
Share on other sites

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 by IRF
Link to comment
Share on other sites

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?)

Link to comment
Share on other sites

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.)

Link to comment
Share on other sites

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

post-63-0-20101000-1484521433_thumb.png

Edited by IRF
Link to comment
Share on other sites

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 by IRF
Link to comment
Share on other sites

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 by IRF
Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.