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

 

arrowleft Previous message
Next message arrowright
arrowleftthread Previous in thread

 

 

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 Previous message Back to the Yahoo! Archive
home page
Next message arrowright
arrowleftthread Previous in thread