Free space and code optimisation in "JSW"

[Norman Sword]

Small rewrite in the JSW game initialisation code which saves a byte:

 

87F5   LD HL,$857C     87F8   LD (HL),$30     87FA   INC HL     87FB   LD (HL),$30     87FD   INC HL     87FE   LD (HL),$30

 

LD HL, #857C

LD BC, #0330

loop:

LD (HL), C

INC HL

DJNZ loop

 

The simpler alternative is as follows

 

LD HL,#3030

LD (#857C),HL

LD (#857D),HL

 

9 bytes. Which is another byte shorter

Edited June 13, 2019 by Norman Sword

[IRF]

Thanks Norman. I notice that that method overwrites the intermediate byte twice, with the same value (not that it matters).

Edited June 13, 2019 by IRF

[IRF]

The start of the Move Willy(3) routine (#8FBC-#8FD0) could be simplified/shortened:

 

Within that part of the routine, Willy's Direction and Movement Flags variable (#85D0) is loaded up to A twice.  (First to check if he's moving left or right - Bit 1 - and RET to Main Loop if he isn't; then to check which way he's moving, left or right? - via Bit 0 - before deciding which path to proceed through the rest of the routine.)

 

But in between those two checks, the Rope Status Indicator (#85D6) is loaded up to A and its value tested (with a RET to Main Loop if Willy's on a rope).

 

If the test of the rope status is put first in that sequence, before the movement/direction flags are loaded up to A, then you could test Bits 1 and 0 of A in turn (reacting accordingly) via BIT instructions, thus removing the need to reload #85D0 into the Accumulator for a second time.  That should provide a modest saving of three bytes.

Edited August 1, 2020 by IRF

[IRF]

#8F14 is a two-byte RLC A command; I can't see any reason why it couldn't be a one-byte RLCA?

[Norman Sword]

The full list of alternate (shorter) opcodes using either RRCA for RRC A and RLCA for RLC A in JSW.

The two sets of opcodes are not exactly the same in operation regarding flags. But in their context within JSW swapping to the shorter version has no impact on the code.

Besides the value at #8f14, all the other uses are in the conveyor routine.

RLC A at #9514 and #9516
RRC A at #9527 and #9529

[IRF]

Yes, I did consider whether the flags might be affected differently, but took the view that it didn't matter in the context (as you have now confirmed 🙂).

The equivalent commands in Manic Miner could also benefit from the same optimisations.

Edited May 20, 2021 by IRF

[geoff]

Inspired by this thread, I made some space optimisations in the Pyramid, only nobody seems to have noticed yet. I won't say what they are, but I will say that you don't necessarily need a disassembler to find them...

[Spider]

On 5/21/2021 at 10:32 AM, geoff said:

Inspired by this thread, I made some space optimisations in the Pyramid, only nobody seems to have noticed yet. I won't say what they are, but I will say that you don't necessarily need a disassembler to find them...

Not had chance (read: no 'free time') to look myself yet Geoff. 🙂

On 5/20/2021 at 7:56 AM, IRF said:

#8F14 is a two-byte RLC A command; I can't see any reason why it couldn't be a one-byte RLCA?

I wonder, why this happens ? Genuine question.

Is it just coding habits and the way some may write instructions "one way" and others "another way" ?

 

For instance I tend to change colours in Basic with pokes now rather than ensure all the attributes are set as its a bit quicker (and uses a bit less space) although its not as easy to read by a long margin.

 

[IRF]

Potential six-byte saving here (see my comment in the post after the linked one):