Skip to content

6502 ORA Tricks: Bitwise OR Special Uses

The bitwise OR instruction (ORA) offers an efficient method for evaluating multiple conditions simultaneously, avoiding the overhead of sequential branch testing. This optimization appears frequently in game loops where multiple states must be checked before proceeding with normal operation.

The Challenge

Checking whether any flag among several variables holds an active state traditionally requires individual load and branch instructions for each, consuming both processor time and memory. In gameplay code that checks player state every frame, this overhead compounds significantly across the roughly 50 frames per second on PAL systems.

Optimization Strategy

Standard Method

Sequential LDA and BNE pairs test each flag variable independently (such as plane state, slide mode, turn status, and respawn flags). Each test requires loading the variable and branching based on its value.

  • Resource usage: 20 cycles, 16 bytes
  • Behavior: Skip processing when any condition holds true
  • Downside: Each branch adds 2-3 cycles depending on whether taken, plus the load and store overhead accumulates

Improved Method

Chain ORA instructions to merge all flag states into the accumulator, then branch once based on the combined result. The accumulator progressively accumulates any set bits from all tested variables.

  • Resource usage: 14 cycles, 10 bytes
  • How it works: Successive ORA operations combine values without intermediate branching, deferring the decision until all flags have been incorporated
  • Savings: 6 cycles and 6 bytes compared to sequential testing of four flags

Essential Concept

Binary flag representation makes this possible (01 for true, 00 for false). ORing multiple flags together yields a non-zero result when any flag is active, allowing a single branch instruction to handle all conditions. The technique requires that flags use compatible representations—mixing different bit positions works fine, but flags using values other than 0/non-zero would require additional masking.

This pattern extends naturally to any number of flags, with each additional ORA adding just 3 cycles for zero-page access. The savings increase proportionally with the number of conditions being tested.

See also: EOR optimization patterns · pointer-based memory access · missing 6502 instructions