Jump to content


Photo

Useful Links


  • Please log in to reply
28 replies to this topic

#11 jetsetdanny

jetsetdanny

    Advanced Member

  • Contributor
  • 1,913 posts

Posted 17 August 2016 - 02:02 PM

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....sw/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..../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  :) .


  • IRF likes this

#12 IRF

IRF

    Advanced Member

  • Contributor
  • 3,813 posts

Posted 17 August 2016 - 02:28 PM

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, 07 September 2016 - 10:03 AM.


#13 IRF

IRF

    Advanced Member

  • Contributor
  • 3,813 posts

Posted 03 October 2016 - 01:32 PM

This is a useful link:

 

http://www.worldofsp...80reference.htm

 

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

 

http://www.worldofsp...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, 13 March 2017 - 04:10 PM.


#14 IRF

IRF

    Advanced Member

  • Contributor
  • 3,813 posts

Posted 04 October 2016 - 03:57 PM

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.



#15 IRF

IRF

    Advanced Member

  • Contributor
  • 3,813 posts

Posted 17 April 2017 - 12:13 AM

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



#16 jetsetdanny

jetsetdanny

    Advanced Member

  • Contributor
  • 1,913 posts

Posted 17 April 2017 - 09:57 AM

Thanks for this, Ian!  :)



#17 IRF

IRF

    Advanced Member

  • Contributor
  • 3,813 posts

Posted 21 April 2017 - 12:29 PM

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.worldofsp...heBugSlayer.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 congiguous message in adjacent character spaces (which can, of course, simply be done by CALLing #9680).

 


; 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, 10 July 2017 - 10:56 AM.


#18 jetsetdanny

jetsetdanny

    Advanced Member

  • Contributor
  • 1,913 posts

Posted 21 April 2017 - 02:19 PM

Great! Thanks, Ian  :)



#19 IRF

IRF

    Advanced Member

  • Contributor
  • 3,813 posts

Posted 04 June 2017 - 02:01 PM

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....sw/patches.html

 

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

https://web.archive..../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, 18 July 2017 - 04:27 PM.


#20 IRF

IRF

    Advanced Member

  • Contributor
  • 3,813 posts

Posted 05 June 2017 - 12:45 PM

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, 05 June 2017 - 12:51 PM.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users