Jump to content
Jet Set Willy & Manic Miner Community

Useful Links


IRF

Recommended Posts

Here are a couple more useful links:

 

J.G. Harston's page:

 

http://mdfs.net/Software/JSW/

 

Geoff Eddy's Patch Vectors:

 

https://web.archive.org/web/20030701143440/http://www.cix.co.uk/~morven/jsw/patches.html

 

However, in the latter, I have noticed a couple of errors.

 

Firstly, the PVs that change Willy's colour in 'Willy Takes a Trip' (Rooms 69, 61 and 62) all contain (directly or indirectly) several Calls or Jumps to #9673.  However, the pertinent sub-routine in the Geoff Mode disassembly (link below) seems to start at #9679 (ending at #967F).

 

Secondly, the PVs in Rooms 10 and 53 of 'Willy Takes a Trip' both call up #97C8 to print a room element, but the 'Print the room' routine in the Geoff Mode disassembly is at #8D33-#8DB0.

 

Geoff Mode disassembly:

 

https://web.archive.org/web/20030701143111/http://www.cix.co.uk/~morven/jsw/geoff_dis.html

 

Ian, thanks for this info.

 

You are referring to Room 59 (not 69), besides 61 and 62.

 

I believe these are not errors. The thing is that the disassembly may not (actually I think: does not) reflect exactly the code in all of Geoff's games.

 

I suspect (without analysing it right now) that the disassembly may have been done on the basis of his first game, "J4 (The Fourth Remix)". In his later two games there must have been some slight changes, and in the fourth game there must be many changes (as it's the so-called Geoff Mode 2).

 

The PVs disassemblies have to be analysed by looking at the actual code of each game in question rather than by comparing them to the disassembly of Geoff Mode.

 

In case of "Willy Takes a Trip" the pertinent code which is called indeed starts at #9763.

 

Also, the printing routine (which I believe is something Geoff wrote, I don't believe it exists in the original "JSW") used by PVs in the rooms 10 and 53 of "Willy Takes a Trip" is where the PV disassembly indicates. I can testify to it, because I copied it into "WNM SE" and it works just fine  :) .

Link to comment
Share on other sites

Okay, so the disassembly at that link is of Geoff Mode 1?

 

But if nothing else, my message above provides clarification about exactly how the CALLs in the first link relate to the routines in the second link.  (Given that there isn't a link available for a Geoff Mode 2 disassembly, or is there?)

 

EDIT: The specific bit of code that is called up by the Patch Vectors in Rooms 10 and 53 of Willy Takes a Trip, starts at #8D96 in the Geoff Mode disassembly.

Edited by IRF
Link to comment
Share on other sites

  • 1 month later...

This is a useful link:

 

http://www.worldofspectrum.org/faq/reference/z80reference.htm

 

In particular, one aspect of the section discussing doubly-shifted opcodes was very illuminating:

 

http://www.worldofspectrum.org/faq/reference/z80reference.htm#DDFDOpcodes

 

 


It is also possible to have doubly-shifted DD CB and FD CB opcodes... note that the offset byte is the third under all circumstances: for the singly shifted opcodes, the offset byte is after the opcode byte, whilst the doubly-shifted opcodes have the offset byte before the opcode byte.

 

To me, the element that I have highlighted in italics in the above quote, is counter-intuitive.

Edited by IRF
Link to comment
Share on other sites

Okay, so the disassembly at that link is of Geoff Mode 1?

 

But if nothing else, my message above provides clarification about exactly how the CALLs in the first link relate to the routines in the second link.  (Given that there isn't a link available for a Geoff Mode 2 disassembly, or is there?)

 

EDIT: The specific bit of code that is called up by the Patch Vectors in Rooms 10 and 53 of Willy Takes a Trip, starts at #8D96 in the Geoff Mode disassembly.

 

UPDATE: The disassembly seems to be of Geoff Mode 2.  The Patch Vector disassemblies of Geoff's first three games refer to addresses in Geoff Mode 1, so they don't tally with the disassembly in some cases.  However, the PV disassemblies for ZX Willy the Bug Slayer do tally with the Geoff Mode disassembly. e.g. Bug Slayer Room 31's PV calls up the 'Print a Room Element' code (in the same way that Rooms 10 and 53 of Willy Takes a Trip do), but this time from #8D96.

Link to comment
Share on other sites

  • 6 months later...

For reference, this noise-creating subroutine at #8590 is not included in any of Geoff Eddy's disassemblies (as far as I can tell), although it is CALLed from the PV for Room 8 ('The Garden of Forbidden Fruit') of his third game 'Willy Takes a Trip':

 

#8590  3A E4 85

#8593  5F

#8594  AF

#8595  01 20 00

#8598  D3 FE

#859A  EE 18

#859C  43

#859D  10 FE

#859F  0D

#8600  20 F6

#8602  C9

Link to comment
Share on other sites

There is also some detail of code changes provided in the readme for 'ZX Willy the Bug Slayer', which isn't included in Geoff's disassembly pages for either his game engine or his patch vectors.

http://www.worldofspectrum.org/pub/sinclair/games-info/z/ZXWillyTheBugSlayer.txt

 

In particular, some of the PVs for that game (in Room 0 'Dead Flesh Nightmares' and Room 5 'PUSH BC') CALL up #8700, so I thought I would include the code here for ease of reference:

 

EDIT: This is useful for printing a sequence of characters to arbitrarily-distributed addresses on the screen (each character and address being defined by pairs of values in the table pointed at by HL) - rather than for printing a contiguous message in adjacent character spaces (which can, of course, simply be done by CALLing #9680).

 

Quote
 

; print a character
; its data is stored in 2 bytes at (HL)
; in the format <yccccccc> <yyyxxxxx>

8700 7E       LD   A, (HL) ; zero signifies "End of data"
8701 A7       AND  A
8702 C8       RET  Z
8703 23       INC  HL
8704 5E       LD   E, (HL) ; this byte needs no conversion
8705 23       INC  HL
8706 47       LD   B, A    ; this one does
8707 0F       RRCA
8708 0F       RRCA
8709 0F       RRCA
870A 0F       RRCA
870B E608     AND  #08
870D C660     ADD  #60
870F 57       LD   D, A
8710 78       LD   A, B    ; character code
8711 E67F     AND  #7F
8713 E5       PUSH HL
8714 D5       PUSH DE
8715 CD9196   CALL #9691   ; print it
8718 D1       POP  DE
8719 E1       POP  HL
871A 18E4     JR   #8700   ; do more

Edited by IRF
Link to comment
Share on other sites

  • 1 month later...

I've just spotted another discrepancy in Geoff Eddy's PV disassembly.  Here it is, for reference:

 

In the third Geoff Mode game, Willy Takes a Trip, Room 8 (The Garden of Forbidden Fruits), there is a CALL to #85A8 (to move HL up a row).

https://web.archive.org/web/20080511161939/http://www.cix.co.uk/~morven/jsw/patches.html

 

But in the Geoff Mode game engine disassembly, the corresponding subroutine is located at #8BB2.

https://web.archive.org/web/20030701143111/http://www.cix.co.uk/~morven/jsw/geoff_dis.html

 

******

 

Also, the 'fuzz border effect' subroutine is CALLed by some of the PVs in Geoff's earlier games from #876B, rather than from #8BEF where the 'fuzz' is located in Geoff Mode 2 (i.e. in ZX Willy the Bug Slayer).

Edited by IRF
Link to comment
Share on other sites

In response to a couple of Geoff Eddy's comments in his own game engine disassembly:

 

Part of Geoff's (somewhat different) arrow-drawing routine:

 

9237 DDCB007E BIT  7, (IX+#00)   ; jump if moving right

923B 2007     JR   NZ, #9244

 

923D DD3504   DEC  (IX+#04)      ; decrement timer

9240 0E22     LD   C, #22        ; 2 columns to right of screen

9242 1805     JR   #9249

 

9244 DD3404   INC  (IX+#04)      ; increment timer

9247 0E7D     LD   C, #7D        ; 2 columns to left of screen

9249 DD7E04   LD   A, (IX+#04)   ; get timer

924C E67F     AND  #7F

924E B9       CP   C

924F 2006     JR   NZ, #9257     ; if we've hit column C,

9251 CDEF8B   CALL #8BEF         ; make a fuzz

9254 C3B393   JP   #93B3         ; and move to the next guardian

 

9257 FE20     CP   #20           ; if the arrow isn't on the screen

9259 D2B393   JP   NC, #93B3     ; don't do anything else

925C E61F     AND  #1F           ; this looks unnecessary!

925E 6F       LD   L, A          ; L = column number

925F DD7E02   LD   A, (IX+#02)   ; y-coord

9262 CB27     SLA  A

9264 262E     LD   H, #2E        ; not sure why I didn't just

9266 CB14     RL   H             ; do "LD H, #5C"!

9268 E6E0     AND  #E0

926A B5       OR   L

926B 6F       LD   L, A          ; HL now points to attribute address

In relation to the first entry in bold (#925C), I would agree that this command is unnecessary.

 

In relation to the second entry in bold (#9264-67), the reason why it was necessary to initially define H as #2E and then apply a RL H command, is because the Carry Flag is rotated into the lowest bit of H in the process.  The Carry Flag will have been set, by the preceding SLA A at #8262, if (and only if) an arrow occupies the lower half of the playing area.

Simply defining H as #5C would mean that all arrows could only occupy the upper half of the playing area, even if the game designer has specified a y-coordinate in the lower half.

Geoff was obviously clever enough to recognise this when he first devised the routine, but must have forgotten his reasoning when he went back to disassemble his own work (presumably some time later)!

 

******

 

A comment in Geoff's Room Setup routine:

 

; set up the guardian data in #8100

; NOTE: this assumes that class 7F is unused

 

8922 DD21F080 LD IX, #80F0 ; start of guardian data

8926 110081 LD DE, #8100

8929 3E08 LD A, #08

892B DD6E00 LD L, (IX+#00)

892E CBFD SET 7, L ; so the data comes from #BC00

 

8930 2617 LD H, #17 ; + 8 * A @@@

 

 

8932 29 ADD HL, HL

8933 29 ADD HL, HL

8934 29 ADD HL, HL

8935 010200 LD BC, #0002 ; copy first two bytes

8938 EDB0 LDIR

893A DD4E01 LD C, (IX+#01) ; get start byte

893D 71 LD (HL), C ; and copy it

893E 0E06 LD C, #06 ; rest of data

8940 EDB0 LDIR

8942 DD23 INC IX

8944 DD23 INC IX

8946 3D DEC A

8947 20E2 JR NZ, #892B ; do another one

 

 

; add terminating #FF; Matthew forgot this! @@@

 

8949 3EFF LD A, #FF

894B 12 LD (DE), A

 

I would dispute the comment in bold - Matthew didn't need to include a command which writes a terminating byte #FF to the address #8140, because that address already holds that value in the original game file (and it is never altered).  So the code occupying #8949-4B in Geoff Mode would appear to be superfluous.

 

Furthermore, the summary of the room buffers at the start of the Geoff Mode disassembly:

 

8000          DEFS #0100 ; data for current room

8100          DEFS #0048 ; guardians in current room

8148          DEFS #00B8 ; blank

 

...seems to suggest that a room may hold up to nine guardians, rather than eight.  It should probably read:

 

8000          DEFS #0100 ; data for current room

8100          DEFS #0040 ; guardians in current room

8140          DEFB #FF; guardian list terminating byte

8141          DEFS #00BF ; blank

Edited by IRF
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.