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: 5914
Author: andrewbroad
Date: 25/08/2006
Subject: Re: Andrew's lifts-patch in JSW64
andrewbroad wrote:
>My lifts-patch replaces...
> I patched the current LIFTS.TAP using the following BASIC program
> to replace the one that JSWED creates (I then saved a snapshot
> with these POKEs applied, loaded it into JSWED, and resaved it as
> the TAP file I beta-released):
>
> 5 CLEAR 32767: LOAD "" CODE
> 10 POKE 35271,244: POKE 35272,150: REM #89C6: call #96F4
> 20 POKE 37302,205: POKE 37303,253: POKE 37304,150: REM #91B6: call
> #96FD
> 30 LET a= 38644: REM #96F4
> 40 READ b: IF b > 255 THEN RANDOMIZE USR 33792
> 50 POKE a,b
> 60 LET a= a+1
> 70 GO TO 40
> 80:
> 100 DATA 33,33,208: REM revert: ld hl,#d021
> 110 DATA 34,106,142: REM ld (#8E6A),hl
> 120 DATA 195,192,144: REM jp #90C0
> 130 DATA 221,203,1,102: REM lift: bit 4,(ix+1)
> 140 DATA 40,90: REM jr z,end ; $+90
> 150 DATA 58,209,133: REM ld a,(#85d1)
> 160 DATA 254,1: REM cp 1
> 170 DATA 32,11: REM jr nz,match ; $+11
> 180 DATA 58,213,133: REM ld a,(#85d5)
> 190 DATA 254,16: REM cp 16
> 200 DATA 40,4: REM jr z,match ; $+4
> 210 DATA 254,13: REM cp 13
> 220 DATA 32,72: REM jr c,end ; $+72
> 230 DATA 33,211,133: REM match: ld hl,#85D3
> 240 DATA 221,126,2: REM ld a,(ix+2)
> 250 DATA 230,31: REM and #1f
> 260 DATA 95: REM ld e,a
> 270 DATA 126: REM ld a,(hl)
> 280 DATA 230,31: REM and #1f
> 290 DATA 147: REM sub e
> 300 DATA 254,2: REM cp 2
> 310 DATA 56,4: REM jr c,row ; $+4
> 320 DATA 254,-1: REM cp -1
> 330 DATA 56,+51: REM jr c,end ; $+51
> 340 DATA 58,207,133: REM ld a,(#85CF)
> 350 DATA 230,240: REM and #f0
> 360 DATA 95: REM ld e,a
> 370 DATA 221,126,3: REM ld a,(ix+3)
> 380 DATA 230,240: REM and #f0
> 390 DATA 147: REM sub e
> 400 DATA 254,48: REM cp 48
> 410 DATA 56,4: REM jr c,act ; $+4
> 420 DATA 254,-2: REM cp -2
> 430 DATA 56,31: REM jr c,end ; $+31
> 440 DATA 221,126,3: REM act: ld a,(ix+3)
> 450 DATA 214,32: REM sub 32
> 460 DATA 230,240: REM and #f0
> 470 DATA 50,207,133: REM ld (#85CF),a
> 480 DATA 205,156,142: REM call #8E9C
> 490 DATA 58,209,133: REM ld a,(#85d1)
> 500 DATA 254,12: REM cp 12
> 510 DATA 210,183,144: REM jp nc,#90b7
> 520 DATA 175: REM xor a
> 530 DATA 50,209,133: REM ld (#85d1),a
> 540 DATA 33,24,104: REM ld hl,#6818
> 550 DATA 34,106,142: REM ld (#8E6A),hl
> 560 DATA 17,8,0: REM end: ld de,8
> 570 DATA 201,256: REM ret; STOP
>
> In short, the "revert" subroutine is at #96F4-96FC, and the "lift"
> subroutine at #96FD-9760. I do not guarantee that these addresses
> will not change; the end-address of the "lift" subroutine will
> almost certainly change from #9760.
>
> Here we see why the JSW64 upgrade failed: #96F4-9717 are free in
> JSW64, but not #9718-9760. The "lift" subroutine will have to be
> relocated to an area with at least 100 (#64) contiguous free bytes.
>
> For example, these subroutines can be relocated to #9B00 with the
> following changes to the above BASIC program:
> 10 POKE 35271,0: POKE 35272,155: REM #89C6: call #9B00
> 20 POKE 37302,205: POKE 37303,9: POKE 37304,155: REM #91B6: call
> #9B09
> 30 LET a= 39680: REM #9B00
>
> Upgrading the resulting game to JSW64 almost works, but there's a
> bug: after a lift has bumped you up a cell-row, you cannot fall
> through Air-cells lower than that cell-row!
>
> Apparently, upgrading to JSW64 has interfered with the self-
> modifying code that stops Willy falling through Air-cells when
> he's on a lift, which the "revert" subroutine is supposed to undo
> when he's not.
#89C6: CALL #90C0 ; move guardians
...with...
#89C6: CALL revert
revert:LD HL,#D021 ; 21 = op-code for LD HL,nn
LD (#8E6A),HL ; self-modify #8E6A: revert to LD HL,#85D0
JP #90C0
But JSW64 replaces...
#89C6: CALL #90C0 ; move guardians
...with...
#89C6: CALL #859B
#859B: LD A,(#80DE) ; get Room-offset #DE
#859E: AND #40 ; extract Bit 6 (Rigor Mortis)
#85A0: JR Z,#85A7 ; if Bit 6 == 0 then skip to #85A7
#85A2: LD A,(#8553) ; else PEEK #8553 (all items in room collected?)
#85A5: OR A ; if PEEK #8853 <> 0 (if not all items collected)
#85A6: RET NZ ; then return without moving guardians
#85A7: JP #90C0 ; else move guardians
So applying my lifts-patch to a JSW64 game would get rid of Rigor
Mortis, while upgrading a JSW48/128 game with my lifts-patch to
JSW64 causes my "revert" subroutine not to be called.
My "revert" subroutine needs to be called before the Rigor Mortis
subroutine, to ensure that it gets called even when Rigor Mortis
comes into play (i.e. so that the lifts will stop, but you can still
fall off them).
Thus, when adding my lifts-patch to a JSW64 game, or after upgrading
a JSW48/128 with my lifts-patch to JSW64, replace...
#89C6: CALL #859B ; Rigor Mortis
...with...
#89C6: CALL revert
revert:LD HL,#D021 ; 21 = op-code for LD HL,nn
LD (#8E6A),HL ; self-modify #8E6A: revert to LD HL,#85D0
JP #859B
e.g. If "revert" is located at #9B00, then replace...
#89C7: 9B 85
#9B07: C0 90
...with...
#89C7: 00 9B
#9B07: 9B 85
...and my lifts-patch works as well for JSW64 as it does for JSW48!
But any lifts in a Rigor Mortis room are not stand-onable until all
items have been collected, since it is the code for moving guardians
that has been patched to implement lift-behaviour.
--
Dr. Andrew Broad
http://geocities.com/andrewbroad/
http://geocities.com/andrewbroad/spectrum/
http://geocities.com/andrewbroad/spectrum/willy/
|
|
|