IRF

Another comment from Geoff's JSW webpage: https://web.archive.org/web/20030818082654/http://www.cix.co.uk:80/~morven/jsw/geoffmode.html I think this must refer to a rope where the lowest three Bits of the guardian definition Byte 0 are set to 111 (07), rather than the usual 011 (03):

I can't see any real reason why the 'Print the Remaining Lives' code in JSW is placed in a subroutine, and then CALLed from the start of the Main Loop. In Manic Miner, it forms the initial part of the Main Loop. Ditto with JSW Geoff Mode. If you remove the JP at #8988, the RET at #89AC and the CALL at #89AD, and then replace the RET Z at #8992 with a JR Z to the start of the rest of the Main Loop at #89B0, then you can achieve a net saving of six bytes. (Or five bytes if you've already implemented the one-byte optimisation of replacing the JP at #8988 with a JR.)

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: 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: 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: ...seems to suggest that a room may hold up to nine guardians, rather than eight. It should probably read:

By that, do you mean that as soon as Willy enters a room with a rope, he is automatically teleported to the room above?

:thumbsup:

That's consistent with the large flashing block letters on the Title Screen, which Matthew also created, and which has a space (but no hyphen) between 'Jet' and 'Set'. It was also two separate words (unhyphenated) on the original cassette inlay (in graffiti-spray writing, representing Willy's trashed house!) By the way, when you mention minor layout changes to the new rooms, I'm wondering if you have followed through with an idea you mooted in the readme, of having two ropes that allow access up to the Tree House...?

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).

Did you remove the hyphen from 'Jet-Set' in the scrolly (with a space character there instead)? (I'm being picky now!) By the way, I've just brought the Temporary Topic that you created back from the grave, in case it's of assistance... (I'm not sure whether I've revived it for another month, or permanently?)

By way of an explanation for the above: Earlier on, I think I established that the 'As Manufacturer Intended' game file was built upon a snapshot file - this conclusion was based on the fact that some of the addresses which store the variables that are used in the game (#85CB-#85E4), hold non-default (i.e. non-zero) values when you examine the game file's code in a hex editor. (Another example which I've just noticed - the range of variable addresses #8000-#813F [representing the buffer for the current room and its guardians] don't all hold zero values in 'AMI', as they do in an original JSW game file.) Anyway, one of those game variables is the WRITETYPER key counter at #85E3. Its default value (as per the SkoolKit disassembly) is 00, but in the 'AMI' game file, it holds a value of 01. To recap what you probably already know, the way that the WRITETYPER counter works, is that it is only updated when Willy is in First Landing and he is located on the floor of that room. It is incremented each time a correct letter key is pressed, but is reset to zero if an incorrect number key is pressed (see 'Main Loop(2)' in the disassembly). Once #85E3 reaches a value of 10 (by pressing each of the letters WRITETYPER in the correct order), then the Cheat Mode is activated. The value of 01 at #85E3 in 'AMI' suggests that the 'W' key was pressed whilst Willy was on the bottom of First Landing, but that this wasn't then followed by 'R', etc (which would have incremented the variable further). And the only way that I can think of in which the variable avoided being reset to zero by any key other than 'R' being pressed, is because Willy was then moved out of the zone (bottom level of First Landing) in which keypresses can influence the value of #85E3. Of course, 'W' is one of the Move Right keys, so if it was pressed for that purpose whilst Willy happened to be walking along the bottom of First Landing, then that would explain why #85E3 was incremented to 01. Willy presumably then proceeded rightwards because 'W' was continually pressed - either up the First Landing ramp (so that he was no longer at the correct y-coordinate for the WRITETYPER activation code), or else he walked rightwards under the ramp and then dropped through the bottom exit into To the Kitchens...Main Stairway (the wrong room for the check for WRITETYPER keys) - prior to the snapshot file being created. From this analysis, I deduced that Metalmickey (who presumably created the snapshot file upon which 'AMI' is based) is a left-handed player, who uses 'Q' and 'W' for Left and Right movement respectively. (In contrast, a right-handed 'O' and 'P' player would not cause the WRITETYPER variable to be 'accidentally' incremented as they passed along the bottom level of First Landing.) So to summarise, by studying the game code I was able to - correctly as it turned out - deduce that Mickey is a left-handed Willy player. Elementary, my dear Watson!

He has added a comment in the Manic Miner Trivia section, pointing out that adding the 'missing' conveyor to Amoebatrons' Revenge makes the cavern uncompletable. (Unless you reverse the polarity of course, but sadly he hasn't provided the POKE for that.) http://skoolkit.ca/disassemblies/manic_miner/reference/facts.html#unusedConveyors

Danny, hopefully you will now appreciate that the above wasn't merely a throwaway comment...

I never got round to explaining my thinking on the above - I don't have time right now but this is a reminder to myself to do it later...

This is now mentioned in the latest update of SkoolKid's JSW disassembly: http://skoolkit.ca/disassemblies/jet_set_willy/reference/bugs.html#missedNote

Thanks Andy! Cheat Mode 2 sounds interesting!

Shouldn't the operand in bold above actually be FC, to point back to #8D56? Although as it happens, the value of FB as stated above just jumps back to a '00' operand byte that sits immediately prior to the correct destination address. This is treated as a NOP, and so has no ill effect other than to (imperceptibly) slow down the routine. I believe that they are similar solutions, but Richard optimised the patch so as to fit within his self-imposed limit of a maximum of ten POKES per 'fix'. In order to achieve this, he identified and recycled an existing relative jump of the same length as the one I referred to above (i.e. '20 FC') at #FF28 within the unused TRS-DOS code at the end of the game file. (In fact, it was studying Richard's solution, in conjunction with his disassembly, which led me to spot Jonathan's apparent error.)

One more tiny suggestion for a tweak to the game file - in the scrolling message on the Title Screen, the use of the hyphen in the word 'Jet-Set' is inconsistent with the lettering on the Title Screen, and general usage. I believe that for consistency, it would be best to use 'Jet Set' (with a space character replacing the hyphen). Incidentally Andy, I would make the same recommendation for the banner at the top of this website (in that case, 'Jet Set' instead of 'JetSet'), although that's probably too much of a faff to change, so it's probably not worth worrying about too much. :)

I've just watched the end sequence after completing the game (I cheated and did POKE 34270, 255 so I only had to collect the Bathroom tap). Very nice effect after the clock reaches midnight! Just one little suggestion, if you're open to a final tweak - you could colour the top half of the 'victim' Cyan in this instance, to match their previous appearance? (I hope that doesn't provide too much of a spoiler?). It's no biggie though. Also, the Screen Flash effect looks good when it kicks in as Willy collects the last item. I wonder if it would be worth mentioning this in the readme, in a cryptic way? Something along the lines of "a special effect that is implemented via a bit of code which Matthew Smith devised for Manic Miner, and which remained in place (still functioning but unused) in the original JSW code".

If the two chunks of code, that print the current time (#8A31-#8A3C) and the number of items (#8A3D-#8A48) respectively, are swapped around, then IX will only need to be defined once at this point in the Main Loop (saving four bytes). Also, D will only have to be defined once for both functions, and so the second instance of LD DE, #0000 can be replaced with a LD E, #00 (saving another single byte). (N.B. The above efficiency would mean that if a game file has the 'Print the Time' code placed after the 'Update the Time' code - as is the case in Willy's New Mansion SE in order to make sure that the clock's colour is changed at precisely the right moment - then it would also need to have the 'Print the Number of Items Collected' code placed after the 'Update the Clock' code.)

Oh, one other thing that I forgot to ask: Regarding 'Norman Sword's credit, did anybody establish for definite that (as we suspect) he is actually Derrick P Rowson (author of JSW2)?

I've now read the readme. If I could just pick up on a few points:

Sorry I haven't had chance to have a look yet, I'll try to do so in the next few days. :)

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).

Thanks Mickey. I haven't got time to study this in detail at it right now, but I've grabbed the file and I'll have a look at it when I get a chance. :)

The buffers are located in 'contended memory' (everything from #4000 to #7FFF, from what I gather). I'm not sure what the implications are of that - Andy may be able to elaborate further? - but I believe that you shouldn't put things such as routines or data bytes within that range. Hence the buffers are located there (#5C00-#7FFF), I think?

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