Resource centre for ZX Spectrum games
      using Manic Miner and Jet Set Willy game engines

 

Archive of the

Manic Miner & Jet Set Willy Yahoo! Group

messages

 

 

 

Message: 7123

Author: ian.rushforth

Date: 28/07/2017

Subject: Re: Guardian corruption / weird rope bug in UMM

 

I wrote:

I then remembered a very minor error in John Elliott's amendments to the in-game music routine in JSW64  > (and JSW128).  Part of John's partial diassembly of the JSW128 changes  > (http://www.seasip.info/Jsw/jswdiffs.html) is reproduced below.  The conditional relative jump at #8B65 is  > supposed to jump to #8B70, rather than #8B6F.  So I changed the operand value at #8B66, from '08' to '09', > and this seemed to magically cure the guardian corruption problem altogether!  But I have no idea why?!?   Further to the above, the existing destination of that relative jump (#8B6F) is the last of six contiguous NOPped out bytes, prior to the start of the teleport code (existing WRITETYPER or the CALL to John's Teleport subroutine) at #8B70.  There is no obvious reason why the jump arriving at #8B6F, instead of at #8B70, should cause any problems.  (Indeed, I only referred to it as a "minor error" in the quote above, because it doesn't leave the full six spare bytes free for other purposes.  See also message 7063.)
For further experimentation, I have tried altering the value of the jump operand at #8B66, in the 'buggy' UMM file, to other values (which shouldn't make a difference to the flow of execution, as long as it bypasses #8B67-69, which is the CALL to #FEC0).
I found that pointing it at any of the first three NOPped out bytes (#8B6A to #8B6C, i.e. inserting '28 03', '28 04' or '28 05' at #8B65) also stopped the guardian corruption from taking place.
But pointing that relative jump in the in-game music code at any of the NOPs at #8B6D to #8B6F (i.e. at #8B65 put '28 06', '28 07' or '28 08' - the latter being the default value in the JSW64 game engine), with no other changes to the game file, caused the guardian corruption to occur once again, at the same exact point during the game as I reported on earlier (i.e. during Willy's second life, at the point when the 'DIE MORTAL' lettering disappears).
I am now very confused as to what on earth is going on!?!?  How can such a trivial change as directing a relative jump to a different point in a sequence of NOPped out bytes, cause such a major difference in the outcome?  The only possible thing I can think of is that the precise value of the 'Program Counter' register is coming into play, in determining whether or not corruption of the guardian buffer occurs???  

 

 

arrowleft
arrowright