The AND, OR and XOR instructions

[Spider]

I think this thread probably belongs in 'Chat' (alongside Danny's 'Language Questions' thread), rather than in 'Remakes'?

The teleporter extension was loaded ;) so I've applied it.

[IRF]

This query doesn't relate to the AND instruction, rather it concerns OR and XOR:-

 

Is there any good reason (e.g. in terms of the effect on the Flags, perhaps?) why the original game engine uses an XOR command at #91FB, instead of an OR?

 

http://skoolkid.github.io/jetsetwilly/asm/91BE.html

 

It's the instruction which merges a guardian's INK colour and BRIGHT value (Bits 0-2 and 6) with the PAPER colour (Bits 3-5) of its host cells.

 

Since neither of the two values that are being 'merged' will have any 'common bits' set in this particular case, the 'toggling' effect of the XOR will never be brought into play, and so it's exactly the same as using an OR (except that using XOR is arguably less 'elegant')?

Edited October 21, 2017 by IRF

[IRF]

This query doesn't relate to the AND instruction, rather it concerns OR and XOR:-

 

Is there any good reason (e.g. in terms of the effect on the Flags, perhaps?) why the original game engine uses an XOR command at #91FB, instead of an OR?

 

It's the instruction which merges a guardian's INK colour and BRIGHT value (Bits 0-2 and 6) with the PAPER colour (Bits 3-5) of its host cells.

 

Since neither of the two values that are being 'merged' will have any 'common bits' set in this particular case, the 'toggling' effect of the XOR will never be brought into play, and so it seems to have exactly the same effect as using an OR (except that using XOR is arguably less 'elegant')?

Further to the above, I've noticed that the equivalent routine in Manic Miner (which is actually present, although unused, in the JSW code) does in fact use an OR command to merge the guardian's INK with the background's PAPER colour, not an XOR!

 

http://skoolkid.github.io/manicminer/asm/8DF8.html#8e5f

http://skoolkid.github.io/jetsetwilly/asm/93BB.html

Edited October 21, 2017 by IRF

[Spider]

I'm not actually sure why its using that. Richard may be the one to be able to answer that more accurately that I could ? :)

[IRF]

I'm not actually sure why its using that. Richard may be the one to be able to answer that more accurately that I could ? :)

 

Perhaps it arose as a result of the 'rush to release' JSW in advance of Xmas 1984?  It doesn't seem to make any difference though, as far as I can tell?

Edited November 11, 2016 by IRF

[Spider]

Perhaps it arose as a result of the 'rush to release' JSW in advance of Xmas 1984?  It doesn't seem to make any difference though, as far as I can tell?

That does sound quite likely. From what I recall the 'race to release' was a bit hectic and I think Matt may of wanted other things possibly in the game :unsure:

[SkoolKid]

Is there any good reason (e.g. in terms of the effect on the Flags, perhaps?) why the original game engine uses an XOR command at #91FB, instead of an OR?

 

http://skoolkid.github.io/jetsetwilly/asm/91BE.html

 

It's the instruction which merges a guardian's INK colour and BRIGHT value (Bits 0-2 and 6) with the PAPER colour (Bits 3-5) of its host cells.

No, there's particular reason to use XOR instead of OR here. As you've noted, there's no difference in the resulting value in the A register, and there's also no difference in the effect on the flags (which are not checked anyway).

Edited October 21, 2017 by IRF

[IRF]

Thanks, Richard!

[IRF]

No, there's particular reason to use XOR instead of OR here. As you've noted, there's no difference in the resulting value in the A register, and there's also no difference in the effect on the flags (which are not checked anyway).

In a similar vein, when it comes to drawing the guardian sprites, I think it would have been more elegant (and would perhaps have made it easier to understand how it works), if the first three bytes of the guardian definition were loaded up in their numerical, 'indexed' order at #9211:

 

http://skoolkid.github.io/jetsetwilly/asm/91BE.html#9211

 

i.e. In turn:

 

- Load up the guardian's current Animation Frame;

- AND with the Animation Frame Mask;

- OR with the Base Sprite Index.

 

Which is mathematically identical to what the code actually does, as A AND B is equal to B AND A.

 

EDIT: To clarify, what the code actually does is:

 

- Load up the guardian's Animation Frame Mask;

- AND with its current Animation Frame;

- OR with the Base Sprite Index.

 

As I said, it amounts to the same thing, but if you think in terms of the Animation Frame Mask being a filter (to select the correct number/sequence of frames to cycle through), I think it's more rational to load up the current frame first, and then AND the Frame Mask, rather than vice versa.

 

(Then in either case, ORing with the Base Sprite from the Guardian Specification selects the correct start sprite-frame.)

 

Edited March 6, 2017 by IRF

[IRF]

I have to say I'm quite impressed with John Elliott's cunning use of an XOR followed by an AND command, in the 'Move the Horizontal Guardians' code in JSW64, in order to determine when to reverse the guardians' direction of movement.

 

The traditional JSW code uses an AND gate - to pick the lowest five bits of Byte 2 of the guardian definition, and then compares it against the minimum or maximum x-coordinate (Byte 6 or Byte 7 respectively) using a CP command.

 

However, that isn't possible in JSW64, because the highest three bits of Byte 7 are used as flags for Fast and Slow horizontal guardians.  So an XOR command, and then an AND gate, is used as an alternative way to compare selected bits (0-4) for comparison - after that pair of operations, the zero flag is set if (and only if) the values stored in the lowest five bits of the pair of bytes under consideration, exactly match.

 

EDIT: To clarify, load Guardian Definition byte 2 into A, XOR with Guardian Definition Byte 7, then AND #1F.  The Z flag will be set iff the x-coordinates match.

Edited June 30, 2017 by IRF