Inserting patch vectors in JSW48 games

[IRF]

In Z80 machine code, CALLing a subroutine pushes the address of the next instruction after the CALL instruction onto the stack, and sets the program counter to the address specified by the CALL instruction, so as to execute the subroutine.

 

RETurning from a subroutine pops the return address off the stack, and sets the program counter to the return address, so as to execute the next instruction after the CALL.

 

Whereas a jump (JP or JR) instruction simply sets the program counter without affecting the stack.

 

So a subroutine is a CALLable sequence of instructions with at least one RET instruction.

Thank you for that clarification Andrew.

 

Is there a word or phrase that we should be using, to avoid confusion, when referring to a subsection of code within a particular routine (i.e. not a 'subroutine' called up from elsewhere)?

[IRF]

For instance, there is a routine in JSW described in the SkoolKit dissasembly as 'Draw the rope, arrows and guardians in the current room'. But as well as being bookended by chunks of code that set up the drawing loop, there are three significant subsections that deal with, in turn:

 

(1) horizontal and vertical guardians;

(2) arrows;

(3) ropes.

 

I have been referring loosely to e.g. the 'draw an arrows subroutine'. If that isn't technically a 'subroutine' (because it isn't called up from elsewhere), then what should I be calling it?

[Spider]

I've always judged CALL as 'GOSUB' and 'JP' as 'GOTO' :) as there is no RET 'RETURN' from a 'GOTO/JP'

[jetsetdanny]

Thanks for your explanation, Andrew!

[andrewbroad]

Thank you for that clarification Andrew.

 

Is there a word or phrase that we should be using, to avoid confusion, when referring to a subsection of code within a particular routine (i.e. not a 'subroutine' called up from elsewhere)?

 

There isn

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

Edited July 4, 2016 by IRF

[jetsetdanny]

Congratulations, Ian! You are quickly becoming an expert on Z80 machine code :).

 

For my part, I have successfully inserted Stuart's Graphic Bug fix into the main loop in "WNM SE" (thanks to your technical tips). More about it later.

[jetsetdanny]

I'll try to provide a short update on "WNM SE" tomorrow, time permitting. There's work in progress, still  :) .

[jetsetdanny]

I am pleased to say I *think* I have completed the last code consolidation in "WNM SE" and I *hope* it's really the last one.

 

I have inserted Stuart's Cell Graphics Bug Fix into the main loop thanks to Ian's technical tips. Hats off to both gentlemen for their contribution!  :)

 

I have consolidated the code related to some of the patch vectors and moved things around a bit. As a result, apart from finding "secure" space for the "border colour restoration" code (which I had to move from the "endangered" area in A3...), I also inserted another "customised"* patch vector (PV) into the game, bringing the total of rooms with PVs to 63 out of 66. The three rooms which do not have patch vectors are: "The Multi-Toilet Bathroom" (a special room in itself, obviously), "Jump 'n' Jive" (the very first JSW room I ever designed) and "Copin' with Ropin'" (a room which doesn't need any PV for the kind of challenge it has).

 

There are several "customised" PVs in "WNM SE" which comprise the following parts: an "introductory" part setting a variable or some variables within the PV proper and then the "PV proper" which executes whatever is supposed to happen. So the "introductory" parts are different for each room this PV is applied in, while the "PV proper" is just one and the same for all.

[IRF]

I have inserted Stuart's Cell Graphics Bug Fix into the main loop thanks to Ian's technical tips. Hats off to both gentlemen for their contribution!  :)

 

Danny, I was helped by advice from Stuart which I found in an old message of his:

 

"So here it is again, the fix for the block-graphics bug, only this time I have pasted my fix into SkoolKid

Edited April 15, 2016 by IRF