Inserting patch vectors in JSW48 games

[andrewbroad]

Yes, the H* games would be platformers (without excluding the possibility that they may contain minigames of different genres, although that

[jetsetdanny]

Looking forward to your retirement, Andrew!

 

A humble suggestion for your life: make a lot of money in the next 9 years, retire at 50 and spend the following 50 years designing ZX Spectrum games  ;) .

[IRF]

Danny,

 

Just to let you know, I have succeeded in inserting the Main Patch Vector into the Main Loop.

 

However, this was more of an academic exercise - as previously discussed, it is more byte-intensive to rely on direct jumps back from each room-specific patch vector, rather than call commands.

 

So, unlike the Cell Graphics Bug Fix (which is best applied directly into its host routine, if that can be achieved by consolidation), there is a sound 'bytes management' reason why the Main Patch Vector should be applied as a separate sub-routine.

Further to the above, it's just occurred to me that if there was a CALL (HL) command in the Z80 armoury, then that could replace the JP (HL), thereby allowing the Main Patch Vector code (i.e. the 5 byte subroutine that directs the program to the address stored at Offsets #EE-EF for the current room) to be inserted directly into the Main Loop.

 

(EDIT: Any room that doesn't have an associated PV routine could be catered for by pointing its Offsets #EE-#EF at ANY existing 'C9' Return command in the code.)

 

However, it's a moot point, as I don't believe there's such thing as a CALL (HL) command!

Edited October 3, 2016 by IRF

[Spider]

You can JP (HL) , ie jump to the 'contents of' HL but not 'call' it, so you're doing a GOTO (no return) rather than a GOSUB (which would happily accept a RET)

 

AFAIK you can't do a JR with it either (not really tried) so a JR Z JRNZ would probably be out. Might be able to work around it though by doing a compare and / or carry set test then just "Calling" anyway... :unsure:

 

Having said that it might well exist as an undocumented instruction but using these is not always a brilliant idea. Some protection schemes do AFAIK.

[IRF]

An idea for developing a code when you've run out of ideas what else to do:

 

Write a code which will provide for items to cycle through 7 colours, in every room skipping the colour which is this room's background, so that no item ever disappears :) .

One more thought on the above - if the number of colours that the items cycle through is 7, then because that isn't an exact divisor of 256, Geoff Eddy's 'flying killer blocks' might eventually collide with one of the items (fatally) at a time when it happens to be White! This could be as late as 7 in-game minutes after Willy's entry to a room which has that PV enabled!

Edited October 15, 2016 by IRF

[andrewbroad]

Looking forward to your retirement, Andrew!

 

A humble suggestion for your life: make a lot of money in the next 9 years, retire at 50 and spend the following 50 years designing ZX Spectrum games  ;) .

 

I'm not working to any predefined retirement age. My philosophy is to make hay while the sun shines, and maybe make H* when it does not (depending on which dark eventuality forces me to stop working).

 

I cannot imagine living to 100 unless the nanobots of everliving life are invented soon. Perhaps there's a game idea in that...

[IRF]

 

First of all, what I call "the main patch vector" (which Geoff simply calls "the patch vector", but they are all patch vectors, so I think it's good to distinguish this one from all the other, room-specicic ones) has to be called from the main game loop. Geoff does it at #89F5-#89F7. I'm not sure if it has to necessarily be in this very spot, but I have just followed what Geoff did and placed it there and it works fine.

Actually, the Main PV routine in later* Geoff Mode games is called from #89F2, with earlier calls to other routines shifted upwards (space is made in the code because the CALLs to the original Master Bedroom/Bathroom special code is actually enacted via patch vectors for those rooms).

 

[* In earlier Geoff Mode games, the Main PV routine is called at the point where the Master Bedroom/Bathroom special code was originally called from, which means that the routines to Draw guardians/animate the conveyor/Draw items actually comes after the Main Loop PV is enacted in early games. Not ideal if you want to have special effects involving those elements, as Geoff presumably figured out in time for his later games.]

 

 

So my suggestion is to (for example):

 

- Move the code at #89F5-#8A0A three bytes down to #89F8-#8A0D (this frees up #89F5-#89F7).

 

- Insert "CD 41 81" at #89F5-#89F7.

 

- NOP out (set to zeroes) the addresses #8A0E-#8A25.

 

Another step which you omitted to mention there, Danny, would be to edit the 'Kill Willy' routine at #90D6 so that the jump back into the Main Loop at the end of that routine points at #89F8, instead of #89F5.

 

Otherwise, if you have a Patch Vector in a room which edits the value of the Airborne Status Indicator at #85D1 (which is also used later in the Main Loop to tell the program to remove one of Willy's lives, if it holds a value of #FF), then it actually can prevent Willy from losing a life.

 

(Of course, you could use that 'quirk' to deliberate effect...)

Edited March 16, 2017 by IRF

[IRF]

Incidentally, Geoff Eddy says in his disassembly of Geoff Mode that the code used there "animates [the items] by 8 colours as in JSWII".

 

I now believe this is not true, because AFAICT the items in JSWII are animated by 7 colours - they are never black. That's what I can see by looking at the game (JSWII), at least. From this I infer that Geoff's code in this respect is different from the code in "JSWII".

 

Based on my recent observations, JSWII items cycle through five colours - blue, red, green, cyan and white.

[IRF]

And one more reflection about inserting two "main" patch vectors. While probably possible technically (why not?), I think it simply wouldn't make much sense. A patch vector is a subroutine, a chunk of code, which does something special in the room, and the two bytes in the room data point to where the patch vector for this particular room should be activated from (where it starts). The patch vector may include various elements, including calls to other subroutines. So, once you have been able to call a patch vector, you can make it perform all the tricks you want for this room. So you don't need a second patch vector.

 

I wonder whether we've been getting the terminology correct here?  Having given some thought to the matter, I now believe that:

 

- The 'Patch Vector Subroutine' is the four-byte subroutine that is CALLed from the Main Loop (or from the Room Setup Routine), which picks up a two-byte address stored within each room's data, and jumps to it;

- 'Patch Vector' is the term for the jump destination address, stored across two spare offset bytes within the room data for each room (i.e. the Patch Vector refers to the coordinates where the Patch for that room is located);

- A 'Patch' is a subroutine, located at the address that is pointed at by the 'Patch Vector' for the current room; the Patch is CALLed up from the Main Loop (or from the Room Setup Routine) via the 'Patch Vector Subroutine'.

 

So for a game in which the Main Loop contains a CALL to the Patch Vector Subroutine, all rooms have one Patch Vector (no more, no less), although a room may feature more than one Patch if several are 'daisy-chained' together before a RETurn command is encountered during flow of execution.  In such a game, if a room's Patch Vector points directly at a RETurn command, then it would be the case that that room doesn't have a Patch, but it does have a Patch Vector.

 

******

 

Following the above definitions, one would say that each room in the SE of 'Willy's New Mansion' has exactly one Patch Vector, and one or more patches.

 

******

 

Another example: in the recently-released 'Jet Set Mini', there is a CALL to a Patch Vector Subroutine from both the Main Loop and the Room Setup Routine.  Every room therefore has precisely two Patch Vectors - a Room Setup Patch Vector and a Main Loop Patch Vector.  However, some rooms don't actually feature any Patches at all (both Patch Vectors point straight at a RET command); some rooms contain a Main Loop Patch but no Room Setup Patch (or vice versa); some rooms feature both a Room Setup Patch and a Main Loop Patch; and some rooms contain more than one Room Setup Patch and/or more than one Main Loop Patch.

 

Furthermore, some Patches may be shared by more than one room (where the Patch Vectors for both of those rooms point at the same address), or a Patch might be partially shared by more than one room (if two Patch Vectors point at different entry points into the same Patch).

 

Finally, some Patches in 'Jet Set Mini' make use of existing subroutines within the original JSW code (e.g. by setting appropriate values for the register-pairs and then CALLing up the 'Print a sprite' subroutine at #9456).  Where such a feature forms the only or final element of a room's Patch, then JUMPing to the subroutine instead of CALLing it means that there is no need to insert a RETurn command at the end of the Patch; the RET at the end of the existing subroutine will do the job of returning the flow of execution back to the Main Loop (or to the Room Setup Routine).

Edited July 25, 2017 by IRF

[Spider]

 

 

JUMPing to the subroutine instead of CALLing it means that there is no need to insert a RETurn command at the end of the Patch; the RET at the end of the existing subroutine will do the job of returning the flow of execution back to the Main Loop (or Room Setup Routine).

I've always been a bit wary of this (generally) as you are sort of then reliant (as I see it at least) on the stack being correct so it knows 'where to go' , this is a bit like jumping into a GOSUB routine in a way when it his the RETURN it needs to have "somewhere" :) :unsure:

 

I see what you're saying though.