The Limitation: Hardware Sprite Count

Many systems with dedicated sprite hardware (like the MSX or certain arcade boards) have a severe limit on the number of sprites that can be displayed on a single horizontal scanline (e.g., 8 or 16 sprites). Exceeding this limit causes sprites to disappear or flicker.

The Solution: Sprite Multiplexing Sprite Multiplexing is a software technique that dynamically reuses the hardware’s limited number of sprite slots multiple times per frame. The goal is to quickly change the sprite’s position and pattern as the display beam moves down the screen.

The Display List (The Engine’s To-Do List)

To facilitate multiplexing, the CPU generates a Display List during the Vertical Blanking Interval (VBI).

Display List Structure: The Display List is a structured list in RAM containing:

  1. The Y-position where the hardware slot should activate.
  2. The X-position for the sprite.
  3. The index/pointer to the sprite’s graphic pattern.

Execution: The Horizontal Blanking Interrupt

The Display List is processed during the Horizontal Blanking Interrupt (HBI) — the very brief time when the beam is resetting to the left edge of the screen.

The HBI Routine:

HBI_HANDLER:
    PUSH AF, HL, DE, BC  ; Save ALL registers!
    
    ; 1. Check Display List: Read the Display List pointer
    LD   HL, (DISPLAY_LIST_POINTER)

    ; 2. Update Hardware: Read the next item from the list and
    ;    write its pattern and position to the hardware's sprite registers.
    CALL WRITE_SPRITE_REGS
    
    ; 3. Advance Pointer: Increment the Display List pointer to the next entry.
    
    POP  BC, DE, HL, AF   ; Restore all registers
    RETI                  ; Return from the interrupt

The Result: Virtual Sprites

By having the HBI handler continually rewrite the sprite hardware registers, you trick the display chip into drawing far more than its native limit. For example, if the hardware supports 8 sprites per line but you have 16 sprites, the HBI handler rapidly rewrites the 8 slots halfway down the screen.

The Challenge: Timing is everything. The HBI window is incredibly small (often under 50 Z80 T-states). The HBI routine must be perfectly optimized, or it will introduce visible screen corruption.