Sprite Status/Slot Select

Number	$303B
Decimal
Short desc.	Sets active sprite-attribute index and pattern-slot index, reads sprite status.
Bit Mask	%0011 0000 0011 1011 ??
Readable	Yes
Writable	Yes
Subsystem	Sprites

Write functionality

Used to select the sprite index/slot (0..63 for both pattern slots and sprite attribute slots) configured by Sprite Attribute Upload ($xx57 / 87) and Sprite Pattern Upload ($xx5B / 91). Once written, these ports may auto-increment the sprite index they are addressing. This auto-increment happens independently and so the two ports may end up addressing different sprites as a result. A write to this port will resynchronise them to the same sprite. The attribute-index has now also Sprite port-mirror Index Register ($34) mirror, which can be set to operate either independently or in link with values set on this port (details in NextReg $34 description).

Write to this port with bit 7 set adds an offset of 128 to the pattern upload index (aiming at the second half of 256 byte pattern slot 0..63).

Read functionality

When read, returns sprite status information as follows:

Bit	Effect
2-7	Reserved
1	Maximum sprites per line flag. Set to 1 when sprite renderer ran out of time when preparing next scanline. Reading the port will reset it to 0.
0	Collision flag. Set to 1 when non transparent pixels of any 2 sprites overlap during rendering scanline. Reading the port will reset it to 0.

Sprite Engine internals information

Sprite renderer is able to draw roughly about 1300..1600 pixels per line (exact amount depends on the video mode timing, slower modes like 50Hz will give renderer more time per line), i.e. all 64 non-scaled 16x16 sprites should be always rendered without any issue. When up-scaled sprites are used, the rendering time may get exhausted sooner (then bit 1 "maximum sprites" will get set, and rendering is aborted unfinished with some sprite graphics (of sprites defined later in the list) missing in final result).

The rendering does proceed through list of sprites from sprite 0 to sprite 63, preparing sprite graphics for *next* scanline, i.e. when ULA pixel area is drawing line Y=14 (raster line register reads 14), the sprite graphics for line 14 was prepared during line 13. Thus "maximum" and "collision" flags read at the end of scanline 13 (start of scanline 14) contains already results of what is visible as line 14 on screen.

The attributes of particular sprite are read in single 28MHz cycle when the sprite rendering starts, i.e. attributes of sprite 0 are read somewhere around very start of scanline, and as rendering progresses, attributes of sprite 63 are read somewhere toward end of scanline (or completely skipped in case the sprite renderer runs out of time due to large-scale sprites encountered early - the skipped sprites are also missing in the "collision" test, the "collision" flag is set only when particular colliding sprite pixels are rendered successfully and collision was "visible" on screen).

In case you are "multiplexing" sprites (changing sprite attributes during single frame to make particular sprite appear multiple times at screen at different lines), the sprite attributes for line Y must be updated when line Y-1 video output starts (for sprite 0 obviously slightly ahead of Y-1 scanline start, but not at start of Y-2 scanline, as that would modify sprite position already for scanline Y-1 result.

It is not possible to obtain from the sprite hardware the numbers or IDs of the sprites which overlapped in the "collision". The collision flag should thus be seen as initial broad phase collision detection (you can slightly narrow the detection by reading the flag at different scanlines, for example reading it at player's "top" line first to reset it, and at player's "bottom" line to ignore all sprite collisions happening above/below player).