Sprites: Players & Missiles on Programming the Atari VCS in Assembly

Drawing a Player

Mon, 01 Jan 0001 00:00:00 +0000

Drawing a Player#

The two players (P0 and P1) are the TIA’s real sprites: 8-pixel-wide bitmaps you can move anywhere and color independently. A player is how you draw the tank, the spaceship, the character. Drawing one is, like everything on the VCS, a matter of feeding the right register at the right scanline.

One byte, one row#

A player’s shape lives in a single register — GRP0 for player 0, GRP1 for player 1. Its 8 bits are 8 pixels: a 1 lights a pixel in the player’s color (COLUP0 / COLUP1), a 0 is transparent. But a register holds only one row, so — exactly like the playfield kernel — you rewrite GRP0 on each scanline the sprite occupies, walking down a bitmap table:

Horizontal Positioning

Mon, 01 Jan 0001 00:00:00 +0000

Horizontal Positioning#

This is the technique that defines VCS sprite work, and the first place every beginner hits the cycle wall. A player has no X-coordinate register. You cannot write “put P0 at column 40.” Instead you position it by timing — and then nudge it into place.

Step one: strobe to a coarse position#

Writing to RESP0 is a strobe: the value doesn’t matter, the act of writing does. It snaps player 0’s horizontal position to wherever the beam happens to be at the moment the store executes. So you move a sprite by choosing when in the scanline to run STA RESP0.

Size & Copies (NUSIZ)

Mon, 01 Jan 0001 00:00:00 +0000

Size & Copies (NUSIZ)#

There are only two players, but a single register stretches what they can do. NUSIZ0 and NUSIZ1 (one per player) set a player’s width and let the TIA stamp out multiple copies of it across the line — and the same register sizes that player’s missile. It’s the cheapest way to get more than two objects on screen at once.

Player width and copies#

The low three bits of NUSIZ choose one of eight modes:

Missiles & the Ball

Mon, 01 Jan 0001 00:00:00 +0000

Missiles & the Ball#

The other three movable objects — two missiles and one ball — are the TIA’s single-bit shapes. They have no bitmap; each is just a solid colored rectangle whose only graphic choice is its width. That makes them cheap to position and toggle, which is exactly what you want for bullets, balls, and small markers.

The missiles#

Missile 0 and missile 1 are turned on by ENAM0 / ENAM1 and positioned with the same strobe-and-HMOVE dance as the players (RESM0/RESM1, HMM0/HMM1). The catch — and the convenience — is color: a missile has none of its own. M0 always draws in player 0’s color (COLUP0), M1 in player 1’s. A missile is, by design, this player’s projectile.

Object Priority

Mon, 01 Jan 0001 00:00:00 +0000

Object Priority#

When two objects cover the same pixel, one of them has to win — and which one shows in front is object priority. This is a separate question from collisions: collision detection only tells you that two objects overlapped, never which was drawn on top. Priority is what decides the picture.

The default order#

The TIA ranks the six things it can draw in a fixed order. Highest priority is drawn in front:

Sprite Multiplexing

Mon, 01 Jan 0001 00:00:00 +0000

Sprite Multiplexing#

The TIA gives you two players, and — unlike ROM or RAM — no cartridge hardware adds more. The two-sprite limit is one you beat in software. Yet games routinely show a screen full of enemies, shots, and characters; they do it by time-sharing the two players — reusing each one to be several different things, either down the screen or across frames.

Reuse down the screen#

The key realization: a player only occupies the scanlines you actually draw it on. If two objects never share a scanline, one player can be both of them — enemy A in the top third of the screen, enemy B in the middle, enemy C at the bottom, all drawn by the same player 0 in a single kernel.