Free space and code optimisation in "JSW"

[IRF]

The three byte command at #959A is unnecessary; if the program arrives there, then A already holds the number of the current room from #8420, having been assigned it by the identical command at #9534.

[IRF]

I believe that in a game with fewer than 256 collectable items, it would be possible to use the spare range of addresses at the top of pages #A4 and #A5 for other purposes.

 

However, extreme care would need to be taken if subsequent editing of the item definition bytes is carried out - individual entries would need to be edited in the hex editor.  If items are deleted in the JSWED GUI, then all other entries above in the item tables are shunted down, which would mean any Patch Vector subroutines would be brittle.  A 'safer' use of the spare addresses at #A4xx / #A5xx would be for data such as graphics, or an in-game tune.

 

(I resisted the temptation to use the spare bytes in this range when working on 'Jet Set Mini'.)

[IRF]

The three byte command at #959A is unnecessary; if the program arrives there, then A already holds the number of the current room from #8420, having been assigned it by the identical command at #9534.

 

The same is true of the four-byte command at #8CD7-8CDA.

[IRF]

The 'Print a message' routine at #9680 uses the indexed IX register-pair to point at the start of the message to be printed.

 

However, I believe it would be more efficient to use the HL register-pair instead.  The only pitfall is that 'Print a message' calls 'Print a single character' (#9691) as a subroutine, which uses HL.

 

But if the CALL to #9691 from #9683 was bookended by a PUSH HL and a POP HL, then the three-byte LD A, (IX+$00) command at #9680 could be replaced with a single-byte LD A, (HL) command.

 

So far the code changes are 'byte-neutral'.  But it would allow further efficiencies throughout the program.  For starters, the INC IX at #9686 could be replaced with INC HL (saving one byte).

 

But it would allow all the commands which set up IX prior to a CALL to #9680 to be replaced with commands that set up HL.  This removes the need to use the 'DD' shift-opcode, and in some instances the offset byte operand.

 

e.g. at #8835, #88C8, #8965, #8971, #8A31, #8A3D, #8CCB and #8CD7, you could replace the four-byte LD IX, $0000 commands with three-byte LD HL, $0000.  (Although the commands in red are already ones that I have identified as potentially redundant, because those routines print two messages in quick succession which are stored in adjacent addresses in the code, so IX [or the suggested HL] will already point at the correct location to pick up the message.)

 

At #88CF, the two-byte ADD IX, DE could be replaced with a single-byte ADD HL, DE.

 

Some of the above changes could be very useful in freeing up bytes in tight spots in the code (such as the Main Loop). :)

[Spider]

It would be useful to gain a few bytes in the main loop yes without (for example) either sacrificing the 'screen flash' routine and / or calling other pieces of code temporarily from within the main loop.

 

Possibly exception to this I guess is the pause control as that could in 99% of cases safely be binned as most will be using emulators where pause is a click away and failing that not too many variants do impose strict time limits.

[IRF]

The inactivity timer code is fairly unnecessary in this day and age.

[Spider]

The inactivity timer code is fairly unnecessary in this day and age.

What I tend to do apart from applying Richard's three pokes to fix the pause bug (if I don't remove the whole routine instead!) is also remove the INC A instruction that lives at 35518 / #8ABE , although in theory I could chop the check out further down removing this as you know will just stop it 'auto pausing' if the in-game tune is disabled.

 

This single change on its own will also in theory at least fix the pause bug on a real machine if an IF1 is attached provided the user never pauses the game too, but for safety I always apply the three fixes anyway as his work properly compared to others but as mentioned my favourite really is to simply remove all that section ideally.

 

Personally I never saw the need for it to either auto-pause (or not) dependent on if the game tune was playing / not playing. :)

 

I started writing a large bit of text here then had a brainwave instead:

 

http://jswmm.co.uk/page/guides.html/_/jetset-willy/pause-bug-fix-r7 :)

[IRF]

The 'Print a message' routine at #9680 uses the indexed IX register-pair to point at the start of the message to be printed.

 

However, I believe it would be more efficient to use the HL register-pair instead.

 

 

I just tried the above and it works fine!  :)

 

The IX (and IY) registers come into their own when you're reading and/or updating a sequence of consecutive bytes (such as an ASCII string), or using a lookup table (such as #8200-FF), or when you're dealing with the likes of the guardian buffer (addressing each eight-byte definition in turn, to move or draw the guardians).  The ability to use an offset-byte operand saves you from having to constantly redefine the index pointer.

 

But the 'Print a message' routine doesn't do any of those things, it just uses IX like any other register-pair to hold an address (the start of a ASCII message).  I suspect the only reason Matthew didn't use HL is because that also is used by the subroutine which prints each character in turn.  But PUSHing and then POPping HL gets around that.  ;)

[Spider]

The 'I' registers have been a slight source of confusion for me given their unique erm properties, at least as I understand it. :unsure: :)

[IRF]

The I register is something different I think (and is still a bit of a mystery to me - it controls the Interrupts).

 

I was referring to the IX and IY register-pairs, which work just like HL, but you can specify bytes at a specific offset from the 'origin'. e.g. look at how the guardian code works.  You access them by using a 'shift byte' in front of the regular Z80 operation byte ('DD' for IX, 'FD' for IY).  :)