Willy disassemblies in hexadecimal

[Spider]

And so the TODO list starts filling up again. :)

 

I've started a new thread in this forum to announce the disassembly updates, but it's still in moderation. Once it's accepted, let the comments and suggestions begin...

 

Done. 'Contributors' should not have mod queue though :unsure: in that area. Its only 'checked' in advance as its mainly for external links, its only meant to effect regular 'members' not trusted groups.

 

I'll take a look at that tomorrow.

 

Fixed :)

Edited May 12, 2016 by Spider

[IRF]

As a suggestion for a tweak to the disassembly, perhaps this page http://skoolkid.github.io/jetsetwilly/asm/8100.html should say at the end:

 

8140 Terminator

8141 - 8143 Unused (but potentially overwritten if a rope were to occupy the eighth position in the guardian list for a room)

 

Then change the 'Next' link (and the following page, and the reference in the Memory Map) from 8141 to 8144.

 

This would prevent future game developers from using those three bytes that might get corrupted in such a scenario?  Or at least, they would have been warned to use those bytes with care!  (In the case of TNE it's easily avoided, since it just so happens that there are three unused bytes at the end of the chunk of previously unused code that was recycled for new tune data. i.e. at 81FD - 81FF).

 

Regarding the above I've just noticed that, whilst it wasn't mentioned in the latest Changelog, Richard has added a note to that effect in the relevant page of his disassembly (and also towards the end of the preceding page):

 

http://skoolkid.github.io/jetsetwilly/asm/8141.html

http://skoolkid.github.io/jetsetwilly/asm/8100.html

 

Thanks Richard!  :)

[IRF]

No, there's no trigonometry involved. :) Here's the explanation I've included in the bug description:

 

"The number 15 here determines the highest segment of rope that Willy can reach (originally 12). At segment 15, Willy's y-coordinate never goes below 25 while he's on the rope, and is adjusted down to 24 (see 36782) when he jumps off, which is too far from the top the room (the maximum height Willy can jump is 20 pixels). At segment 14, Willy's y-coordinate never goes below 23 while he's on the rope, but is adjusted down to 16 when he jumps off, which is close enough to the top of the room to be able to jump through it."

 

You can see the full text in the git commit:

 

https://github.com/skoolkid/jetsetwilly/commit/99733c6c4708b86b9c58f2369934d02a43ee7c1b

 

Richard, regarding the above...

 

Whilst you and I reached the same conclusion, via different methods, it seems that we were actually both wrong!

 

Please see the short .rzx recording attached to this post.  It was based on a file in which I had applied both of the POKES that you provided in this entry of your disassembly:

 

http://skoolkid.github.io/jetsetwilly/reference/bugs.html#fromTopToBottom

 

Daniel (jetsetdanny) alerted me to the possibility of carrying out this manoeuvre.  I managed to achieve it second time round in the attached recording.  However, in the first instance, you can see that Willy makes a pair of rapid, quirky 'up and then down' jumps jerky relocations (which may help to provide enlightenment as to what is going on?)

 

In a later post, I will comment on the reason why it is possible to 'defy' our analysis in this way, and I shall also provide a further code 'tweak' that should resolve this 'bug' once and for all!  (Unless you manage to get there first?)

Double Jump Rope Test.rzx

Edited September 3, 2016 by IRF

[SkoolKid]

This bug just got more interesting! :)

 

I think I know why Willy is relocated further down the rope on your first attempt: in the section of code that handles Willy's movement along the rope, the rope status indicator is reset to 12 if it's found to be 11 or less. How you then manage to circumvent that code in your second attempt, I have no idea yet.

[IRF]

This bug just got more interesting! :)

 

I think I know why Willy is relocated further down the rope on your first attempt: in the section of code that handles Willy's movement along the rope, the rope status indicator is reset to 12 if it's found to be 11 or less.

Yes, although the value (of the Rope Status Indicator) at which the adjustment occurs is actually 14 or less (reset to 15) in the recording that I uploaded, not 11 or less (because I applied the POKES that you provided previously). Which makes the effect even more noticeable!

 

Also, just before Willy is relocated downwards, he is briefly (for one time-frame) relocated upwards slightly, because his sprite is centred on his point of contact with the rope - which happened to be his head.

 

EDIT: Actually, that latter effect is probably a fairly common occurrence whenever Willy gets onto a rope - his y-coordinate is adjusted up or down by up to one cell-height. Whereas the downwards adjustment you can see in the recording is quite large in magnitude (several cell-rows of sudden vertical displacement), and therefore much more noticeable as a result.

 

How you then manage to circumvent that code in your second attempt, I have no idea yet.

 

Then I shall leave you to ponder for a while longer!

 

Here's a clue though: I did something different, in terms of key presses, between the two occasions...

Edited September 7, 2016 by IRF

[jetsetdanny]

Richard, first of all thanks again for your wonderful disassembly of "JSW" which has been extremely useful in my work on the Special Edition of "Willy's New Mansion" (to be released soon)!  :)

 

The routine starting at #96DE, described here, is called in your disassembly "Play an intro message sound effect". While this description is certainly true, it is not the whole truth, because the routine also produces border effects. If it is NOPped out, there is indeed no sound during the scrolling message, but also the visual effects on the borders, which are an important part of the overall effect accompanying the scrolling, are markedly different.

 

So I was just wondering if it wouldn't be more accurate to call the routine in the disassembly "Play an intro message sound effect and produce border effects" or something to that effect (no pun intended).

[IRF]

At least one of the routine pages in the Manic Miner disassembly ends with a comment: "This routine continues into [the next routine]."

 

Perhaps a similar approach could be taken with the 'Start the game' entry in the JSW disassembly?  i.e. if the 'Start the game' page just covered addresses #88FC to #8911, ending with a comment like the above, then have a separate page that begins at address #8912, called 'Room set-up routine' or something to that effect?

 

As things stand, every time that Willy exits a room or loses a life during the game, the program is directed to a page which, on the face of it, is called 'Start the game'.  Whilst the program is directed to the later entry point in those circumstances - and the hyperlinks in the disassembly also point to that later entry point (#8912) - I still believe that it would be clearer if the 'Room setup' entry point marked the beginning of a separate page of the disassembly (which would then have a distinct entry in the Routines Menu).

Edited September 9, 2016 by IRF

[jetsetdanny]

I'll second that vigorously. In fact, in the "WNM SE" Readme file, I have just put:

 

88FC

[IRF]

Richard, regarding the above...

 

Whilst you and I reached the same conclusion, via different methods, it seems that we were actually both wrong!

 

Please see the short .rzx recording attached to this post.  It was based on a file in which I had applied both of the POKES that you provided in this entry of your disassembly:

 

http://skoolkid.github.io/jetsetwilly/reference/bugs.html#fromTopToBottom

 

Daniel (jetsetdanny) alerted me to the possibility of carrying out this manoeuvre.  I managed to achieve it second time round in the attached recording.  However, in the first instance, you can see that Willy makes a pair of rapid, quirky 'up and then down' jumps jerky relocations (which may help to provide enlightenment as to what is going on?)

 

In a later post, I will comment on the reason why it is possible to 'defy' our analysis in this way, and I shall also provide a further code 'tweak' that should resolve this 'bug' once and for all!  (Unless you manage to get there first?)

 

I've just rediscovered an earlier post (discussing the forthcoming 'Jet Set Mini' project), which describes a similar kind of behaviour (with a twist).  This should give another clue as to how I managed to achieve the jump off the top of the screen in the above:

 

- I set the Up Exit from Swimming Pool to The Orangery [instead of looping back to the Swimming Pool], as it was possible to fall down onto the rope from above and cause some odd 'teleport' effects!  (Willy landed on a segment of the rope that wasn't 'permitted', and as soon as you tried to shift him along a bit, he instantaneously jumped to a point halfway down the rope!  Also, it was possible to jump from the point at which Willy fell onto the rope, off the top of the screen - causing him to be teleported into the path of the Underwater Monk on the same screen, causing an IDS!!)

 

I would also add that in relation to the point above in blue, if you didn't try and shift Willy along the rope, then he sat there quite happily at the 'impermissible' height! (i.e. at a rope segment in the range 1 to 15 - N.B. Richard's POKES were also in place in the scenario being described.)

 

EDIT: In this scenario, you can also turn Willy round to face in the opposite direction without triggering the sudden shift downwards - as long as you don't move him into a different frame of animation!

 

Unfortunately, at the moment I can't share the working file in which I observed the above, but I'll try to recreate the phenomenon in a test file later.

Edited September 21, 2016 by IRF

[IRF]

This bug just got more interesting! :)

 

Richard, the 'From Top to Bottom' Rope Bug just got even more interesting again!

 

I think I have managed to come up with a code change which precludes Willy escaping 'from the top to the bottom' of a room that has a rope and the Up Exit set to itself.

 

On top of the POKES provided in the disassembly, which reset the values at #9396 and #939A in the Rope-drawing code from 12 to 15 ('#0C' to '#0F' in hex), I have changed the value of a single byte.  (Actually, for consistency I changed two bytes, from the same old value to the same new value, but only one of the two is directly relevant to the matter at hand.)  My initial attempt at a new value for the pertinent address proved to be insufficient for the task, but I managed to identify why, and then resolved that by tweaking the new value accordingly.

 

This may seem a bit cryptic at the moment, and I promise that I will reveal all soon.  But before I provide a full explanation, I would like to invite, nay challenge (if not defy  ;) ) jetsetdanny - and anyone else who might care to try - to confound me, by opening up the attached file and succeed in jumping off the top of the starting room (On the Roof), via the rope!!

 

And then, once you have (hopefully!) failed to do so, please read the spoiler box below for an even more peculiar revelation...

 

 

However, the code change I have implemented does not provide a global fix.  If you wander leftwards from On the Roof, you will notice that in this test file I have changed the Left Exit from On the Roof to lead to The Beach, where you should find that you can pull off the quirky manoeuvre that allows Willy to jump 'from the top to the bottom' of that room!

 

N.B. I haven't used a different 'Rope Class' to allow this to be achieved (i.e. the rope doesn't swing any wider in one room than in the other, which might be your first thought as to how this could be made possible..)

 

No Top to Bottom.z80

Edited September 22, 2016 by IRF