NES 8 sprites per scanline: a checker for dropped sprites

The NES draws at most 8 sprites per scanline. The PPU looks through all 64 OAM entries in order, keeps the first 8 that touch the line, and drops the rest without a trace. On my test ROM, 12 sprites on one row lost the same 4 in every frame, and the PPU’s own overflow flag, as Mesen emulates it, missed one real overflow in 119 of 119 frames and reported a false one in another 119 of 119. To find dropped sprites without playing the ROM, I built nessprites, a headless checker that names every sprite lost on every line of every frame.

I checked it against the real picture: run the same ROM with the emulator’s sprite limit off and on, and any line whose pixels differ really lost something. It missed 0 of 7,923 damaged lines on the test ROM and 0 of 190,788 in 19 ROMs written by Claude. Those pictures come from FCEUmm, and the flag from Mesen. I did not check any of this on a real NES.

This is the NES version of mdsprites, the Mega Drive sprite limit checker, and the first tool in the retro series that runs NES ROMs; the pixel art checker already tested NES palette and attribute limits on images.

How many sprites per scanline can the NES draw?

Eight, out of 64 in OAM. The NESdev wiki describes how the PPU picks them: during each line it scans OAM from entry 0, copies the first 8 entries whose Y puts them on the next line, and draws those. Lower entries win, so whatever sits late in OAM is what disappears. A sprite with OAM Y = y is drawn on lines y+1 to y+8, or y+16 in 8x16 mode.

Here is what the checker reported for one row of the screen. Each layout ran for 120 frames on FCEUmm, with a blank background so every lost pixel shows:

Layout on one row	Sprites lost per frame	Lines that lost pixels
8 x 8x8	0	0
9 x 8x8	1, the last in OAM, every frame	960
12 x 8x8	4, the same 4 every frame	960
10 x 8x16	2	1,928
24 in 3 rows of 8, 16 lines apart	0	0

The checker’s numbers and the picture agreed on every line in every layout. Twelve balls are in OAM; the last four never reach the screen.

Can the sprite overflow flag detect dropped sprites?

Not reliably. Bit 5 of PPUSTATUS ($2002) is meant to say “more than 8 sprites on a line”, but the NESdev wiki documents a hardware bug: after the eighth hit, each miss moves the PPU to the next entry and to the next byte within it, so it starts comparing tile numbers, attributes and X positions as if they were Y coordinates. That gives false negatives and false positives.

FCEUmm sets the flag exactly, without the bug. Mesen emulates it. So my test ROM reads $2002 at the start of every NMI and stores bit 5 in RAM, and I ran it on both cores. nessprites also computes the flag both ways from OAM: the exact answer, and the bugged evaluation as the wiki describes it.

Layout	Sprites lost	Exact	FCEUmm flag	Mesen flag	My bug model
9 on a row	1	set	119/119	119/119	set
8 on a row, entry 8 off the row, entry 9 on it	1	set	119/119	0/119	clear
8 on a row, entry 9 off the row with tile number 103	0	clear	0/119	119/119	set

In the second layout, the PPU checks entry 8’s Y (off the row), then entry 9’s tile number ($05) instead of its Y, so it never sees the real ninth sprite. In the third, entry 9 is nowhere near the row, but its tile number, 103, is a Y that is on the row. Across all ten layouts the model matched Mesen’s flag in 1,360 of 1,360 frames.

I found the third case by accident. My first version of the second layout set the flag, because entries I had “hidden” with Y = $FF still held an X of 100 from an earlier layout, and the PPU read that X as a Y. If you hide sprites by writing only Y, the flag depends on what is left in their other three bytes. The list of sprite overflow games on the wiki shows games that use the flag on purpose, with care. For finding dropouts, count sprites yourself, or run a checker.

Does a cleared OAM steal sprite slots?

Yes. A common way to start a frame is to zero OAM. That puts all 64 entries at Y = 0, which is on screen: lines 1 to 8. They are invisible with a blank tile, but they still take the 8 slots. In my test, 56 zeroed entries came first and 8 real sprites at Y = 3 came last. The real sprites lost lines 4 to 8 in every frame, and only their bottom 3 rows showed:

Hide unused entries with Y = $EF to $FF instead. nessprites reads each lost sprite’s pattern row from CHR, so it reports losses like these zeroed entries (384 lost rows per frame here, with nothing opaque in them) separately from the ones you can see.

Does sprite flicker fix the dropouts?

Flicker doesn’t remove the loss, it shares it. The usual trick is to change the OAM order every frame, so a different sprite is last each time. With 12 sprites on a row, 4 are lost in every frame no matter what. What you choose is how the loss is spread. I tested two rotations of the same 12 balls:

OAM start moves by	Share of frames each ball is invisible	Longest run of frames one ball is invisible
1 slot per frame	33.3%	4
5 slots per frame	33.3%	1

Moving the start by 1 hides each ball for 4 frames out of every 12, a gap of about 67 ms five times a second. Moving it by 5, which shares no factor with 12, never hides the same ball in two frames running. Same cost, same share, a much steadier picture. The NESdev forum has a long thread on controlled sprite flicker if you want other people’s patterns.

How the checker works

nessprites is a small libretro frontend in C. It loads the FCEUmm core, built without its symbol version script so the emulator’s own OAM (SPRAM), PPU registers and indexed picture (XBuf) are visible, runs the ROM headless, and after each frame evaluates every line:

for (int line = 0; line < 240; line++) {
  int found = 0, n;
  for (n = 0; n < 64; n++) {
    if (!in_range(line, oam[n * 4], h)) continue;
    if (found++ < 8) continue;                  /* drawn */
    if (!row_visible(&oam[n * 4], line - oam[n * 4], tall, ctrl, show_left))
      { w.clear_lines++; continue; }            /* lost, but transparent */
    note_loss(line + 1, n);                     /* lost and visible */
  }
  /* the PPU's own evaluation, with the overflow bug */
  found = 0;
  for (n = 0; n < 64 && found < 8; n++) if (in_range(line, oam[n * 4], h)) found++;
  if (found == 8)
    for (int m = 0; n < 64; n++, m = (m + 1) & 3)
      if (in_range(line, oam[n * 4 + m], h)) { w.flag_hw = 1; break; }
}

FCEUmm runs VBlank (NMI, OAM DMA) first and the 240 visible lines after it, so after retro_run() returns, OAM is the table those lines used. The truth check runs the ROM twice, first with FCEUmm’s fceumm_nospritelimit option and every frame saved, then with the limit on, comparing the two pictures line by line. FCEUmm, Mesen and cc65 are cloned at pinned commits and built in Docker; nothing is installed on the host and no emulator code is changed.

The test ROM and the Claude scenes share a tiny cc65 runtime. Its NMI copies OAM only after the program calls oam_ready(), so a table still being filled is never shown, and it counts a lag frame when the program was not ready in time. I added that after my own test ROM showed half-built tables: one layout made 64 calls to a small put() helper and needed two frames to do it.

Does Claude respect the NES sprite limit?

It knows the limit. I asked Sonnet 5.5 for 6 scenes that crowd sprites onto lines, one run each, with two prompts: plain, and with one added sentence, “It must look right on a real console, with no sprites dropping out or flickering.” Each ROM ran for 1,200 frames under a scripted pad. When a scene lost sprites, I sent the checker’s report back once and asked for a fix that kept the same objects, sizes and behavior. All 19 programs compiled on the first try.

Scene	Prompt	What Claude did	Frames really losing pixels	After the report
formation: 2 rows of 10 ships, 16x16	plain	skips ships itself, 3 groups (20 Hz)	1.7%	0% (4 groups)
	warned	kept 10 per row	100%, and 30 fps	100% (now rotated, 60 fps)
brawler: 6 x 16x32 on one line	plain	skips 2 of 5 enemies each frame	0%
	warned	rotates OAM	100%	99.8%
convoy: 10 x 16x8 on one row	plain	rotates OAM	100%	100%
	warned	spaces cars 96 px apart on a 960 px road	0%
boss: 48x48 boss, 8 orbiting fireballs	plain	budgets 6 + 2 per line	0%, but 30 fps
	warned	budgets 6 + 2 per line	0%, but 30 fps
rain: 40 drops, umbrella	plain	rotates OAM	3.2%	0%, but 30 fps
	warned	4 layers of 10 drops, 24 lines apart	0%
snake: 20 x 8x8 segments	plain	rotates OAM	68.2%	68.2%
	warned	rotates OAM	55.8%	56.5%

What I saw once I read the code and not only the percentages:

• Claude states the rule. Eleven of the twelve first versions explain the 8-per-line limit in a comment (the twelfth says the row “fits only 4”), and the boss scenes work out the budget correctly: 6 boss sprites plus at most one fireball on each side per line, 0 lost.
• The warning made some scenes worse. The warned formation keeps 10 ships per row with a comment that says “Hardware fits only 4 per row without dropouts”, then draws all 10 anyway: 6 ships per row are gone in every frame, as in the screenshot. Asked for no dropouts and no flicker, it kept the scene and accepted dropouts, where the plain prompt had produced a working 20 Hz flicker.
• “0%” can still flicker. The plain brawler and formation leave objects out of OAM on alternate frames. The PPU drops nothing, so nessprites reports 0%, yet the enemies flicker. The checker sees what the hardware drops, not what your code skips.
• Rotation fixes the look, not the count. The fixes for the warned formation and the plain snake added or changed OAM rotation. The share of frames that lost something did not move (100% and 68.2%), but by my rough tracking, the longest a single object stayed hidden fell from the whole run to 3 frames on the formation and from 17 to 2 on the snake. For a row of 10 ships that is the best you can do without changing the scene.
• Frame rate is the hidden cost. Both boss programs ran at 30 fps with nothing lost: draw() makes 48 calls to a five-argument put_sprite() with int coordinates, and cc65 passes arguments on a software stack. I did not profile it, but my own test ROM’s 64-call layout was slow in the same way. The rain fix stopped all losses by checking a per-line counter for every drop, and dropped to 30 fps (609 lag frames of 1,200). The warned formation’s first version also ran at 30 fps. The lag counter caught all four. On the Mega Drive, mdprof names the function behind a slow frame; I have no NES equivalent yet.

19 claude -p calls cost USD 1.11 at API prices, on a subscription. One run per scene and prompt is a small sample, so read this as what can happen, not as a rate. The Mega Drive version of this test went the other way: there, the warning cleared every scene, partly by changing the scene. On the NES, with only 8 slots, there was often no way to show 10 ships in a row without either flicker or dropouts, and Claude said so in its own comments.

What I would do differently

• It finds what your input reaches. A clean run does not prove that no line can overflow.
• OAM is read once per frame. A ROM that rewrites OAM during rendering breaks that; the picture comparison would show it as missed lines, and it never did here.
• My “longest invisible” number links lost sprites by position, so it overstates when objects overlap: in the warned snake, 245 of 915 frames with a predicted loss changed no pixels, because segments were stacked on each other. The table above uses the picture-based count.
• Software flicker needs a different check: comparing which objects the game meant to draw with what reached OAM. That is the next thing I would add, along with checking the bug model against a second accurate emulator.

Everything is in the project folder: the checker, the test ROM, per-frame CSVs for both cores, and every program Claude wrote with its reports.