jetsetdanny Posted August 17, 2016 Report Share Posted August 17, 2016 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 :) . IRF 1 Quote Link to comment Share on other sites More sharing options...
IRF Posted August 17, 2016 Author Report Share Posted August 17, 2016 (edited) 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 September 7, 2016 by IRF Quote Link to comment Share on other sites More sharing options...
IRF Posted October 3, 2016 Author Report Share Posted October 3, 2016 (edited) 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 March 13, 2017 by IRF jetsetdanny 1 Quote Link to comment Share on other sites More sharing options...
IRF Posted October 4, 2016 Author Report Share Posted October 4, 2016 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. Quote Link to comment Share on other sites More sharing options...
IRF Posted April 17, 2017 Author Report Share Posted April 17, 2017 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 jetsetdanny 1 Quote Link to comment Share on other sites More sharing options...
jetsetdanny Posted April 17, 2017 Report Share Posted April 17, 2017 Thanks for this, Ian! :) Quote Link to comment Share on other sites More sharing options...
IRF Posted April 21, 2017 Author Report Share Posted April 21, 2017 (edited) 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 March 31, 2021 by IRF Spider and jetsetdanny 2 Quote Link to comment Share on other sites More sharing options...
jetsetdanny Posted April 21, 2017 Report Share Posted April 21, 2017 Great! Thanks, Ian :) Quote Link to comment Share on other sites More sharing options...
IRF Posted June 4, 2017 Author Report Share Posted June 4, 2017 (edited) 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 July 18, 2017 by IRF Spider and jetsetdanny 2 Quote Link to comment Share on other sites More sharing options...
IRF Posted June 5, 2017 Author Report Share Posted June 5, 2017 (edited) 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 June 5, 2017 by IRF jetsetdanny and Spider 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.