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

 

 

Previous message		Next message

 

 

Message: 5912

Author: andrewbroad

Date: 24/08/2006

Subject: Re: Andrew's lifts-patch and Geoff's patch-vectors in JSW64

 

dm_boozefreek wrote:

>
> So to Andrew
>
> Can I ask for my own ends does your lift patch at present
> translate to JSW 64?

Not at present, no. I tried upgrading it to JSW64:V using JSWED, but
it just crashed on entering the first room.

The lifts-patch is written in terms of JSW48 addresses, without
regard for how JSW64 may store the corresponding data at different
addresses, and without regard for any code-differences that may
interfere with the patch. In fact, I haven't even considered where
the "lift" and "revert" subroutines would fit into a JSW64 memory-
map.

I'll wait until I have developed the JSW48 test-bed to my
satisfaction before I start worrying about JSW64.

> or is it a 48k thing?

It does work for JSW128!

> Anyway if the lift patch does translate to JSW 64 any chance of
> you breaking down what's in the tech readme into just the
> addresses the changes are made to

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.

> To Andrew and/or John Elliot (or maybe even Geoff Eddie)
>
> Can any of you give me a hand in how to implement Geoff Mode
> vectors into JSW64 (if indeed it is possible, although I can't see
> why it wouldn't be).
>
> The ones I would like to use are:
>
> As 48k taken from Geoff Eddies patch vector disassembly
>
> 41 (Willy's Drinking Licence)
> Very simple; flip Willy's horizontal position every 63 ticks.
> 9788 3ACB85 LD A, (#85CB)
> 978B E63F AND #3F
> 978D C0 RET NZ
> 978E 3AD385 LD A, (#85D3)
> 9791 EE1F XOR #1F
> 9793 32D385 LD (#85D3), A
> 9796 C9 RET

I don't see why this wouldn't work in JSW64. Try it and see!
I assume that you know how to insert these bytes at an appropriate
address (#9788-9796 aren't free in JSW64), and set the room's main-
loop patch-vector to point to that address?

> and
>
> ; room 15 [Doppelganger]
>
> 9784 1E80 LD E, #80 ; signify other half of screen
> 9786 0E01 LD C, #01 ; "die if we touch something"
> 9788 CD3B96 CALL #963B ; print doppelganger
> 978B C2B790 JP NZ, #90B7 ; die if somethingh is touched
> 978E C9 RET ; otherwise exit
>
> ; rewritten "draw Willy" code so that this works
>
> 9637 1E00 LD E, #00
> 9639 0E00 LD C, #00
> 963B 3ACF85 LD A, (#85CF)
> 963E 80 ADD B
> 963F AB XOR E
> 9640 2682 LD H, #82
> 9642 6F LD L, A
> 9643 23 INC HL
> 9644 7E LD A, (HL)
> 9645 2B DEC HL
> 9646 6E LD L, (HL)
> 9647 67 LD H, A
> 9648 3AD385 LD A, (#85D3)
> 964B E61F AND #1F
> 964D 85 ADD L
> 964E 6F LD L, A
> 964F 3AD285 LD A, (#85D2)
> 9652 E603 AND #03
> 9654 0F RRCA
> 9655 0F RRCA
> 9656 5F LD E, A
> 9657 3ADE80 LD A, (#80DE)

This instruction reads Room-offset #DE, which in Geoff-mode 2
is "Border colour in bottom 3 bits" and "Willy on screen | mode, in
top 2 bits". The JSW64 room-format is completely different...

> 965A 47 LD B, A
> 965B 3AD085 LD A, (#85D0)
> 965E CB10 RL B
> 9660 3804 JR C, #9666
> 9662 CB10 RL B
> 9664 1807 JR #966D
> 9666 CB10 RL B
> 9668 3802 JR C, #966C
> 966A EE01 XOR #01
> 966C 1F RRA
> 966D CB1B RR E
> 966F 3AED80 LD A, (#80ED)

This instruction reads Room-offset #ED, which in Geoff-mode 2 is
Willy's sprite-page. Luckily, this just happens to be the same in
JSW64.

> 9672 57 LD D, A
> 9673 C35694 JP #9456


> One more pretty stupid thing to ask after this but what byte
> would you use to make BRIGHT green on black for instance 4c
> Is BRIGHT green on blue, I could work it out if I just stopped and
> thought.

%FBPPPIII
%01000100 = #44

> But I've prepared the second file for "The Dark Quadrology",

I assume you refer to _The Overfiend_, but what does this mean
exactly?

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

 

 

	Back to the Yahoo! Archive
Previous message	home page	Next message