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

 

 

	Previous message		Next message
	Previous in thread		Next in thread

 

 

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/

 

 

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