Willy disassemblies in hexadecimal

[IRF]

(without having read the spoiler)

 

I've tried it repeatedly and I don't think it's possible. The mechanism which allows Willy to perform a double jump is not there any more. Willy doesn't get hold of the rope unless he's below certain height, and it's too far away from the top to jump effectively.

 

Danny,

 

I've just proved myself (and you) wrong on this point!!  I managed to jump off the top of the single-rope room via the rope, notwithstanding the code change which I thought would prevent such a manouevre!  I'll do an .rzx later!

[IRF]

It was a pleasure  :) . And this time I could only confirm that what you declared to be impossible was indeed impossible!

 

Except that it now turns out that it isn't impossible! :D 

[jetsetdanny]

Congratulations on proving me wrong, Ian! I look forward to watching the RZX.

 

It's very difficult - if not impossible - to prove that something is not possible. You try the manoeuvre once, you try it twice, you try it ten times. You can't complete it. You try it another fifty times, and you still can't complete it. Does it mean it's impossible? Not really. You can suspect it is, but you can never be 100% sure.

 

In a sense, it's about how many times you are willing to try. Declaring that something is impossible after trying to achieve it once or twice would be foolish. Declaring it after trying ten or twenty times gives your claim more credibility, but is still far from conclusive. Declaring it after trying a hundred times is even more credible, but still, you never know whether someone else will not prove you wrong.

 

So, in essence, I shouldn't have said:

 

I could only confirm that what you declared to be impossible was indeed impossible!

 

but rather:

 

I could confirm that what you declared to be impossible was probably impossible.

 

It is always "probably", it is never 100% certain...

Edited July 31, 2017 by jetsetdanny

[IRF]

Congratulations on proving me wrong, Ian! I look forward to watching the RZX.

 

It's very difficult - if not impossible - to prove that something is not possible. You try the manoeuvre once, you try it twice, you try it ten times. You can't complete it. You try it another fifty times, and you still can't complete it. Does it mean it's impossible? Not really. You can suspect it is, but you can never be 100% sure.

 

In a sense, it's about how many times you are willing to try. Declaring that something is impossible after trying to achieve it once or twice would be foolish. Declaring it after trying ten or twenty times gives your claim more credibility, but is still far from conclusive. Declaring it after trying a hundred times is even more credible, but still, you never know whether someone else will not prove you wrong.

 

So, in essence, I shouldn't have said:

 

I could only confirm that what you declared to be impossible was indeed impossible!

 

but rather:

 

I could confirm that what you declared to be impossible was probably impossible.

 

It is always "probably", it is never 100% certain...

 

Actually, it was my scrutiny of the code which made me wonder if it was theoretically possible, which I subsequently confirmed to be the case in practice.

 

And it involved a change in technique to that which you tried before - I still maintain that it is impossible via your previous approach!

[IRF]

Et voila!  Please see the attached recording!

 

I believe that in order to prevent Willy jumping out of a room with the Up Exit set to itself, is to apply Richard's POKES (available here: http://skoolkid.github.io/jetsetwilly/reference/bugs.html#fromTopToBottom )  and set the value of #8FAA to #E9.

 

As opposed to the value #EC for #8FAA which I previously suggested.  N.B. The original value for #8FAA in JSW is #F0.  Therefore, preventing the jump off the top requires a delay of 7 additional time-frames between Willy dismounting a rope, and being able to climb back onto it, compared with original JSW.

 

And as before, the above fix won't work in a room with more than one rope!

Yes Top to Bottom!.rzx

[jetsetdanny]

A nice jump :). Sometimes the simplest solutions are the best  ;) .

[IRF]

From the Manic Miner disassembly:

 

http://skoolkid.github.io/manicminer/reference/facts.html#sourceCodeRemnants

 

Before the game starts for the first time, the 512-byte cavern buffer at 8000 contains source code remnants.

 

Further to the above, I've just discovered that in Manic Miner the range of addresses #5B00-#5BFF also appears to contain remnants of source code.

 

(In JSW, the upper end of that range of addresses is used by the program for the stack, but in MM the stack is located elsewhere.)

 

Some editors such as JSWED 'tidy' up these addresses, so they appear to be blank in the hex editor.  However, if you open up the game file in SPIN and then use the debugger to PEEK at those addresses, you can see the unused source code in situ.

Edited September 11, 2018 by IRF

[IRF]

From the Manic Miner disassembly:

 

http://skoolkid.github.io/manicminer/reference/facts.html#sourceCodeRemnants

 

 

Further to the above, I've just discovered that in Manic Miner the range of addresses #5B00-#5BFF also appears to contain remnants of source code.

 

(In JSW, the upper end of that range of addresses is used by the program for the stack, but in MM the stack is located elsewhere.)

 

Some editors such as JSWED 'tidy' up these addresses, so they appear to be blank in the hex editor.  However, if you open up the game file in SPIN and then use the debugger to PEEK at those addresses, you can see the unused source code in situ.

 

Oops, please ignore the above - when the game file is opened up in SPIN in 48K mode, page #5B of the code just holds values of zero!

 

It is only when the file has been opened up in 128K mode that some seemingly random code manifests itself in that range of addresses.  This seems to arise from the way in which the Spectrum 128K mode operates, rather than being newly-discovered remnants of source code as I suggested earlier.  :blush:

Edited September 11, 2018 by IRF