Jump to content


Photo
- - - - -

The AND instruction


  • Please log in to reply
39 replies to this topic

#21 Spider

Spider

    DEC (HL)

  • Administrator
  • 3,487 posts

Posted 02 November 2016 - 03:46 PM

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 likes this
Changing order to chaos since 1984

#22 IRF

IRF

    Advanced Member

  • Contributor
  • 3,892 posts

Posted 10 November 2016 - 02:38 PM

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.gith...y/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 by IRF, 21 October 2017 - 08:13 AM.


#23 IRF

IRF

    Advanced Member

  • Contributor
  • 3,892 posts

Posted 10 November 2016 - 05:20 PM

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.gith.../8DF8.html#8e5f
http://skoolkid.gith...y/asm/93BB.html

Edited by IRF, 21 October 2017 - 08:13 AM.


#24 Spider

Spider

    DEC (HL)

  • Administrator
  • 3,487 posts

Posted 10 November 2016 - 06:51 PM

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 likes this
Changing order to chaos since 1984

#25 IRF

IRF

    Advanced Member

  • Contributor
  • 3,892 posts

Posted 11 November 2016 - 11:26 AM

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 by IRF, 11 November 2016 - 11:33 AM.


#26 Spider

Spider

    DEC (HL)

  • Administrator
  • 3,487 posts

Posted 11 November 2016 - 08:36 PM

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:


  • IRF likes this
Changing order to chaos since 1984

#27 SkoolKid

SkoolKid

    Advanced Member

  • Contributor
  • 54 posts

Posted 12 November 2016 - 03:01 PM

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.gith...y/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 by IRF, 21 October 2017 - 08:14 AM.


#28 IRF

IRF

    Advanced Member

  • Contributor
  • 3,892 posts

Posted 12 November 2016 - 03:05 PM

Thanks, Richard!

#29 IRF

IRF

    Advanced Member

  • Contributor
  • 3,892 posts

Posted 26 December 2016 - 06:59 PM

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.gith.../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 by IRF, 06 March 2017 - 11:41 AM.


#30 IRF

IRF

    Advanced Member

  • Contributor
  • 3,892 posts

Posted 28 February 2017 - 09:27 AM

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 by IRF, 30 June 2017 - 03:57 PM.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users