Oric Sprites
The Oric has no sprite hardware. Everything that moves is a software sprite: a small bitmap the program draws into the HIRES screen by hand, then erases and redraws each frame. The serial attribute system makes colour on the Oric harder than on most machines, so a moving object must manage the control bytes on every row it touches.
Overview
Because there is no hardware sprite system, a sprite is just pixel data plus, usually, a mask. The program pokes it straight into the HIRES bitmap at the right address, which it works out from the simple row-times-40 layout, and restores the background underneath when the sprite moves. All the cost is in the 6502, so sprite size and count trade against frame rate.
Sprite format
A sprite is stored as rows of bytes, six pixels per byte, bit 5 leftmost, exactly like a pixel byte. Bit 6 must stay clear so the byte is not read as an attribute, and bit 7 can invert the six pixels. A sprite w bytes wide and h rows tall is w × h bytes, held row by row. A sprite with a mask stores two bytes per cell per row: the mask that clears the background and the data that draws the shape.
| Field | Layout |
|---|---|
| Pixel row | 1 byte per 6 pixels, bit 5 left, 1 = ink, bit 6 = 0 |
| Mask row | 1 byte per 6 pixels, marks where the sprite is solid |
| Order | Top row to bottom, left byte to right |
Masks and drawing
To place a sprite over a background without a box around it, each screen byte is combined with the sprite in two steps: AND with the mask to punch a hole, then OR with the data to fill the shape. In 6502 terms, screen = (screen AND mask) OR data. The mask has clear bits where the sprite is opaque so those pixels are wiped, and set bits where the background should show through. Care is needed to keep bit 6 clear in the result so a written byte is never mistaken for an attribute.
To move a sprite the program first restores the pixels it covered, either by saving them before drawing or by redrawing the background, then draws the sprite at the new position. Because rows are stored plainly, stepping down is a fixed add of 40 to the address.
Attributes on the row
The serial attribute system means colour is set by control bytes that run left to right along each row. A sprite drawn into the middle of a row inherits whatever ink and paper the attribute bytes to its left have set. If the sprite overwrites an existing attribute byte, or needs a different colour, it must place its own control byte just to its left and, since a control byte occupies six pixels of width and shows as background, restore the correct attribute just past its right edge so the rest of the row keeps its colour.
| Situation | Action |
|---|---|
| Sprite keeps row colour | Write only pixel bytes, leave attributes alone |
| Sprite needs its own colour | Write ink or paper control byte to its left |
| After the sprite | Restore the row's attribute past its right edge |
Colour and movement
A sprite's own bytes carry only pixels and the invert flag, not a colour. Colour comes from the attribute state at that point in the row, so a moving coloured object must manage the attribute bytes on each row it crosses, spending six pixels of width for every colour change. Games handle this in a few ways: keep the playfield a single ink and paper so sprites read cleanly with no attribute work, reserve columns for the control bytes so objects always have room to set their colour, or move objects in steps of six pixels so their attribute bytes land on byte boundaries. The state resets to the defaults at the start of every row, so nothing carries between lines.