Kernel Techniques on Programming the Atari VCS in Assembly

Counting Cycles

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

Counting Cycles#

Every other platform lets you write code and measure it later. On the VCS you must know the cost before you run it, because a visible scanline is 76 CPU cycles and there is no “a little slow” — a kernel line that needs 77 doesn’t lag, it corrupts the picture. Counting cycles is the habit that makes everything else in this chapter possible.

Budget from WSYNC to WSYNC#

A kernel is a loop, and the unit you budget is one pass: the cycles between one STA WSYNC and the next. Add up the cost of every instruction in that span — using the per-instruction costs — and confirm the total fits under 76 (minus whatever the visible drawing already spends).

Waiting Precisely

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

Waiting Precisely#

Half of kernel work is making things happen; the other half is making them happen at the right cycle. WSYNC handles the coarse case — it parks you at the start of the next line — but it can only round up to a line boundary. When you need to land on an exact cycle within a line (positioning a sprite, rewriting a playfield register mid-line), or to wait out a whole region of the frame, you need finer and coarser tools than WSYNC.

Multi-Line Kernels

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

Multi-Line Kernels#

Counting cycles eventually delivers bad news: there are jobs that simply don’t fit in one 76-cycle line. Updating both players, fetching their colors, advancing their counters, and still leaving room for the draw — added up, it overflows. When a single line can’t hold the work, you stop trying to do it in one.

Spread the work across two lines#

A two-line kernel runs its loop body once for every two scanlines. The TIA still draws every line — the beam doesn’t slow down — but your code now has roughly two lines’ worth of cycles to prepare what those lines show. You split the work: some on the first line, the rest on the second.

Front-Loading & Tables

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

Front-Loading & Tables#

The last way to fit work into a 76-cycle line is to not do it on that line. Two habits push work out of the hot path: front-loading — computing a line’s data before the line needs it — and tables — computing it before the program even runs. Both trade something plentiful (earlier time, ROM) for something scarce (cycles in the critical window).

Front-loading: be early#

In the moment the beam reaches a sprite, you have just a few cycles to put the right byte in GRP0. If those cycles are also spent deciding which byte — fetching a pointer, adding an offset, looking up a color — you’ll overflow. So you do that deciding earlier, during the slack of the previous line, and leave only a fast store for the critical instant.