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: 6039

Author: andrewbroad

Date: 13/02/2007

Subject: Re: Disappearing teleporter in Jet Set Emily FE

 

Daniel wrote:

>
> I have discovered a disquieting phenomenon during earlier playtests
> of the game, and it happened again when I had another (rather
> superficial) look at the bugfixed version yesterday. The problem is
> that the teleporter sometimes disappears. Let me explain.
>
> The teleportation module in "JSE FE" is located at the addresses
> #81A8 - #81FF. It defines three teleporters: two leading
> from "homestarrunner.com" (027) to "Shiggity Shiggity Shwa" (059)
> and one leading back from that room to "homestarrunner.com".
> I created the teleporters using John Elliott's teleporter extension
> and following Andrew Broad's technical notes accompanying his
> "Jet Set Willy: The Lord of the Rings". And it works fine, but
> sometimes something bad seems to happen which makes the teleporter
> disappear, or at least become dysfunctional.
>
> When I compared snapshots of the game before and after it happened,
> I found out that the problem is at the address #8B70, which has the
> value "CD" when the teleporter works, and "01" after it has stopped
> working. If I understand correctly, "CD" means that the
> teleportation subroutine is called. So when this value is changed,
> it's no wonder that the teleporter no longer works.

Yes, #CD is the op-code for "call NN", and 1 is the op-code for
"ld bc,NN", as in the original JSW (#8B70: LD BC,#EFFE).


> I think this is what happens, but I have NO IDEA WHY it happens. I
> have not been able to associate it with any particular move or
> moment in the game.

>
> Can someone help me to explain this phenomenon and, most
> importantly, explain what triggers it? And how can it be avoided?
>
> Otherwise, there is a risk that there will be a random element to
> the possibility of completing "JSE FE" successfully - much as
> Andrew Broad assures us that the game engine is "a discrete
> system which is 100% deterministic" and in which "there aren't even
> any pseudorandom elements". I know Andrew is right, of course, but
> if something happens and we don't know why, then we cannot avoid
> it, and so for all practical purposes it IS a random event.
>
> If the teleporter disappears before you have collected the two
> items in "Shiggity Shiggity Shwa", you cannot complete the game
> successfully. Unless it can reappear (can it?)

No.

> or you POKE the game engine to re-establish the correct value at
> #8B70.
>
> And one more thing: when the teleporter has disappeared and you
> have lost all your lives and restart the game, the teleporter is
> still off. So you are doomed to failure from the very beginning.
>
> Can anyone help with solving this puzzle?

The obvious thing to try is disassembling JSE FE and then searching
for any references to #8B70 (using "Find" in a text-editor is sound
but incomplete, as you don't know what code might be calculating
#8B70).

This I have done, and lo and behold, #8B70 is written to by the
routine at #8764-87B1! This is the code from the Softricks editor to
provide attract-mode, and it assumes that the byte at #8B70 is
supposed to be 1 under normal circumstances.

#8764: LD HL,0
#8767: LD (#8B1C),HL
#876A: LD (#8B1D),HL
#876D: XOR A
#876E: LD (#8420),A
#8771: LD (#97FF),A
#8774: LD A,#C9 ;;;;; write the value #C9 (op-code for "ret")
#8776: LD (#8B70),A ; to address #8B70
#8779: CALL #88FC
#877C: LD B,#3F
#877E: PUSH BC
#877F: CALL #89AD
#8782: LD BC,#BFFE
#8785: IN A,(C)
#8787: BIT 0,A
#8789: JR Z,#879E
#878B: POP BC
#878C: DJNZ #877E
#878E: LD A,(#97FF)
#8791: INC A
#8792: LD (#97FF),A
#8795: LD (#8420),A
#8798: CP #3E
#879A: JR NZ,#8779
#879C: JR #879F
#879E: POP AF
#879F: LD A,1 ;;;;;;; write the value 1 (op-code for "ld bc,NN")
#87A1: LD (#8B70),A ; to address #8B70
#87A4: LD A,#CA
#87A6: LD (#8B1C),A
#87A9: LD HL,#8C01
#87AC: LD (#8B1D),HL
#87AF: JP #87CA

Apparently, this code disables WRITETYPER during attract-mode (by
planting a RET instruction to return immediately from the WRITETYPER-
code at #8B70), and then reinstates #8B70 to what it is in the
original JSW. (Does the bug occur even when you haven't let it go
into attract-mode?)

So, for Softricks' attract-mode to work in conjunction with John
Elliott's teleporter-extension, it needs to reset the byte at #8B70
not to 1 but to #CD, so that the teleporter-subroutine still gets
called.

Thus you need to replace...

#879F: LD A,1

...with...

#879F: LD A,#CD

i.e. change the byte at #87A0 from #01 to #CD.

The moral of this story is that you have to be careful, when
combining patches from different sources, that they do not interfere -
especially when self-modifying code is introduced!

And, when documenting patches, it's important to document the
assumptions that they make, if bugs such as this are to be avoided.

--
Dr. Andrew Broad
http://geocities.com/andrewbroad/
http://geocities.com/andrewbroad/spectrum/
http://geocities.com/andrewbroad/spectrum/willy/

 

 

arrowleft
arrowright