SGDK DMA queue limit: how many bytes fit in VBlank

How many bytes can SGDK’s DMA queue send per frame? On an NTSC Mega Drive in 320-pixel mode, SGDK 2.11 got 6,907 to 6,932 bytes out during VBlank in my runs when the queue held 1 KB entries, and 7,150 to 7,168 with one big entry. SGDK’s own default limit is 7,200 bytes, so a queue that SGDK accepts without a warning can still run into the visible screen. In my test a 7 KB queue of 1 KB entries spilled 305 bytes into lines 0 to 17, and the sprite table landed at line 13. To see this per frame without playing the ROM, I built mddma, a headless DMA budget checker for SGDK ROMs.

It reports what SGDK queued, what the VDP really got in VBlank and during the display, which scanlines the late bytes landed on, and where they went: tiles, plane maps, sprite table, scroll tables or palettes. Everything here ran in the Genesis Plus GX emulator, which models the VDP’s DMA slots line by line. None of it was checked on a real console.

This is the fifth tool in the retro series. mdprof first measured the VBlank window. This post asks what SGDK’s queue does when you go past it.

How many bytes of DMA fit in VBlank on the Mega Drive?

The emulator’s model is a fixed number of bytes per scanline. Genesis Plus GX’s dma_timing table gives 204 bytes per line with the display blanked in H40 (166 in H32) and 18 per line during the display (16 in H32). An NTSC frame has 38 lines of VBlank, so the ceiling is about 7,750 bytes in H40 and 6,300 in H32. A game gets less, because its own VBlank code runs first. In my runs SGDK’s first DMA write came at line 225 or 226, one or two lines after VBlank starts at 224. How much got through then depended on how many entries the queue held:

Console and mode	Ceiling (38 lines, emulator rates)	Measured, 1 KB entries	Measured, one entry	SGDK default limit
NTSC, H40 (320 px)	~7,750	6,907 to 6,932	7,149 to 7,168	7,200
NTSC, H32 (256 px)	~6,300	5,656 to 5,675	5,822 to 5,844	7,200 (same constant)
PAL, H40 and H32	more than twice NTSC	all 16,448 bytes I queued	all of it	8,000

The difference is setup time. For each queue entry the 68000 writes a handful of VDP registers, and no DMA runs while it does. With 1 KB entries, about seven entries fit in VBlank and cost about 240 bytes between them, roughly 34 bytes per entry. That also explains the 7,140 bytes mdprof measured earlier: that ROM queued one big copy. I reran that ROM in mddma and got 7,136 to 7,144 again, and the same test ROM built with SGDK 2.09 gave the same table as 2.11.

SGDK sets the limit in DMA_setMaxTransferSizeToDefault(): DMA_TRANSFER_CAPACITY_NTSC is 7200, _PAL_LOW 8000. SGDK uses the same NTSC number in H32 mode, where my measured VBlank was 1.5 KB smaller. In the PAL runs the hardware had time to spare: 16 KB went out inside VBlank in both modes.

During the display, DMA trickled at about 17 to 18 bytes per line in H40 and 16 in H32 in my runs. The 68000 is locked off the bus until the transfer ends, as Mask of Destiny put it in an old SpritesMind thread. So each KB past the budget costs about 57 lines, a fifth of an NTSC frame, of CPU time.

What happens when the SGDK DMA queue goes over the limit?

My test ROM has 20 phases. Each phase queues a known number of tile bytes per frame, in 1 KB entries the way a game uploads sprite frames. It then queues the sprite table (64 bytes for 8 sprites) and burns a fixed amount of CPU, about 45% of a frame. Here is NTSC, H40:

Queued per frame	Policy	Game loops/s	VBlank	During display	Last DMA line	Sprite table
6 KB	default	60.0	6,208	0	-	in VBlank
7 KB	default	60.0	6,927	305	17	line 13
8 KB	default	35.6	6,912	1,344	83	line 71
10 KB	default	30.2	6,908	3,396	189	line 186
12 KB	default	30.2	6,915	4,016	223, then the next frame	next VBlank
8 to 16 KB	ignore over capacity	60.0	6,922 to 6,930	238 to 246	13	never sent

SGDK has two policies when the queue passes the limit. By default it only logs a warning (in a debug build) and sends everything. Maintainer Stef said as much in a 2018 thread: “it’s just a warning as you can see, at worst you may get some slowdowns”. The table shows what that means. The spill is small at 7 KB. At 8 KB the late bytes reach line 83, the CPU loses those lines, and a game that used 45% of a frame drops to 35.6 loops per second. From 10 KB on, it runs at 30.

Late bytes also land on screen. In this frame of the 8 KB phase, the tiles should all be blue. The red streaks are tiles that were still on their way when the beam drew those lines:

This is the same failure as the 2015 SpritesMind thread “Garbled graphics”. There, the tile DMAs started at line 0xE2 and the sprite table update came at line 0x13, well into the display.

Does DMA_setIgnoreOverCapacity fix it?

It fixes the frame rate and breaks something else. With DMA_setIgnoreOverCapacity(TRUE), SGDK stops at the first queue entry that would pass the limit and drops that entry and every one after it. Here is the check, in SGDK 2.11’s dma.c:

// we are above the defined limit ?
if (queueTransferSize > maxTransferPerFrame)
{
    // first time we reach the limit ? store index where to stop transfer
    if (queueIndexLimit == 0)
        queueIndexLimit = queueIndex - 1;
    // return FALSE if transfer will be ignored
    return (flag & DMA_OVERCAPACITY_IGNORE) ? FALSE : TRUE;
}

With 1 KB entries, the game ran at 60 loops per second at every size, but the sprite table, queued last, never reached the VDP (0 of the 87 or 88 frames in each phase): the sprites froze. The tiles stopped at 7,168 bytes, so part of the picture never updated. And because 7,168 is still above the 6,930 that fit with seven entries, even this mode spilled about 240 bytes into lines 0 to 13 on every frame.

The first entry is never dropped

That check has a catch. queueIndexLimit is 0 when no limit was hit, and also when the very first entry is the one that crosses it, because then queueIndex - 1 is 0. So when one big upload is the first thing in the queue, the limit is not applied to it. The next entry that is over the limit (the sprite table, here) then sets the limit at index 1. The flush sends the oversized first entry and drops everything after it.

I ran the same ROM with each phase’s tiles queued as one entry to check:

Queued per frame (one entry)	Policy	Game loops/s	VBlank	During display	Last DMA line	Sprite table
7 KB	default	60.0	7,164	68	3	line 0
8 KB	default	60.0	7,168	1,088	60	line 57
8 KB	ignore over capacity	60.0	7,166	1,026	57	never sent
10 to 16 KB	ignore over capacity	30.2	7,149 to 7,156	3,084 to 4,032	171 to 223	never sent
12 KB, sprite table first	ignore over capacity	60.0	64	0	-	sent; all 12,288 tile bytes dropped

So with one oversized upload, ignore over capacity gives you the spill, the slowdown and frozen sprites at once. And if the sprite table goes first, the whole upload is dropped every frame, not trimmed to what fits. Whether that counts as a bug or as “split your uploads” is SGDK’s call. The same lines are in the 2.09 build I tested and on SGDK’s master branch (dma.c last changed 2025-06-05), and I found no issue about it.

Two things helped, both measured in the same ROM:

• Queue the sprite table first. With ignore on, 1 KB entries and the sprite table queued before the tiles, the sprites updated in 87 of 87 frames and nothing spilled. 6,144 bytes of tiles were still dropped every frame, so the art behind them never finished changing.
• Spread uploads across frames. The same 12 KB sent half per frame ran at 60 with no spill. The cost is that a 12 KB change takes two frames to show.

On PAL, the ignore policy is worse than it needs to be. SGDK’s 8,000-byte PAL limit froze the sprites in 87 of 87 frames, although the console sent 16 KB inside VBlank when allowed to. If you ship a PAL build and turn on ignore, raise the limit with DMA_setMaxTransferSize().

For your own budget on NTSC, 6.9 KB in H40 and 5.6 KB in H32 left nothing to spare in these runs with 1 KB entries, and every extra entry costs a few dozen bytes. Any VBlank work before the flush (music, palette fades, your own V-int code) comes off the top.

How the checker works

mddma is a libretro frontend in about 460 lines of C. It loads Genesis Plus GX built with its CPU hook (HOOK_CPU=1) and runs the ROM headless, the same base as mdsprites. Two hooks do the work.

When the 68000 enters SGDK’s flushQueue, mddma reads SGDK’s own static variables. It finds their RAM addresses in symbol.txt. They give the queue as the game left it, before SGDK trims or clears it:

if (a_flush && (address & 0xffffff) == a_flush) {
  cur.flushes++;
  cur.queued += ram16(a_qsize);                       /* queueTransferSize */
  if (a_qindex) cur.qentries += ram16(a_qindex);
  if (a_qlimit && ram16(a_qlimit)) cur.qlimit_hit = ram16(a_qlimit);
}

I first hooked DMA_flushQueue. It found nothing, because link-time optimization had inlined it into SYS_doVBlankProcessEx. The assembly helper flushQueue survives in every build, so the checker falls back to it.

Every VRAM, CRAM and VSRAM write then goes through the second hook. A 68000 DMA stalls the CPU, and the core moves the CPU’s cycle counter to the end of the transfer before it runs it. So any write made while that counter is still at or before the DMA end comes from DMA. The scanline (v_counter) says whether it landed in VBlank or on a visible line. The address is checked against the VDP’s current table bases (satb, hscb, ntab, ntbb, ntwb) to say what it hit.

The output is a per-frame CSV plus a short report. Here is part of the report for the whole test ROM (all 20 phases):

NTSC 60 Hz, 262 lines per frame, 2670 frames checked (from frame 30)
mean CPU load 75.3%, dropped frames 822
largest SGDK queue: 16448 bytes (frame 1148)
VBlank used in full: up to 6932 bytes went out before line 0
frames with DMA during active display: 1511
frames that ended with a DMA still running (it finishes in the next frame): 351
frames where SAT (sprite table) DMA landed during display: 450

frames with the most DMA during display:
  frame 956: queued 12352, sent 6902 in VBlank + 4016 during lines 0-223, tiles 4016

The checker also counts game loops and CPU load the way mdprof does, because a DMA problem usually shows up first as a lost frame.

Does Claude stay within the Mega Drive DMA budget?

I gave Sonnet 5.5 five scenes that tempt you to stream graphics every frame: a 128x128 boss with 8 animation frames, two 96x112 fighters, a title logo of 640 unique tiles with 4 animation frames, a brawler with five 48x64 characters, and a scroller with line parallax. Each ran with two prompts: plain, and “warned” (it must run at a steady 60 fps on a real NTSC console with no glitches). It had no tools and had to make all art in code. All 10 scenes built on the first try. Each then ran for 1,500 frames with a scripted pad, and I measured steady play from frame 700, after every scene had finished making its art.

Scene	Prompt	Steady fps	Largest queue (bytes)	DMA during display	Mean CPU load
boss	plain / warned	60 / 60	264 / 136	0 / 0	12.1% / 10.6%
fighters	plain / warned	60 / 36.0	5,568 / 3,776	0 / 0	6.2% / 70.5%
title logo	plain / warned	60 / 32.0	0 / 3,840	0 / 0	4.2% / 59.8%
brawler	plain / warned	60 / 60	160 / 1,696	0 / 0	8.7% / 11.1%
scroller	plain / warned	60 / 60	112 / 0	0 / 0	10.7% / 17.3%

No scene went over the DMA budget. Mostly Claude avoided streaming. The boss scenes and the plain brawler loaded their frames into VRAM once and switched tile indexes (the warned boss animates only a 64x64 core). The warned brawler streamed each character’s 48 tiles when its frame changed, up to 1,696 bytes in a frame. The plain title animated by rotating palettes. The plain fighters kept the idle frames in VRAM and streamed one 5.4 KB punch frame at a time.

The warned prompt made two scenes worse. Both comments plan around the budget correctly. The fighters scene says “two fighters changing frame in the same vblank would need 10752 bytes, which is more than the ~7 KB an NTSC vblank can move”, and it double-buffers and staggers the uploads. But both scenes also drew their art in software every frame. mdprof put 40.7% of the fighters scene’s cycles in fillRect. The DMA side was clean. The CPU side cost a third of the frames.

I sent the mddma report back once for those two. The title scene came back at 60 fps. The fighters scene came back at 26.0, worse. That is fair to the report: it said DMA was fine and frames were dropping, but it cannot say why. For that cause the right report is mdprof’s. I tested that two days later, and it was not enough: with the CPU profile, or both reports, the one-shot fix still never reached 60 in 15 tries. Letting Claude Code run the checkers itself did, in 3 of 3 runs.

Two plain scenes took a long time to start: 8.6 s (boss) and 10.6 s (title) of generating tiles at boot before the first steady frame. That is outside the DMA question but worth knowing if you let a model make art in code.

One run per scene and prompt is a small sample, so read this as what can happen, not as a rate. The 14 claude -p calls would have cost USD 3.53 at API prices; they ran on a subscription.

What I would do differently

• Check the budget numbers on hardware. Genesis Plus GX is accurate about DMA slots, but 6,930 is an emulator number. A second emulator (BlastEm) or a real console with a flash cart is the next check.
• Test SGDK’s sprite engine too. My ROM queued the sprite table by hand with VDP_updateSprites(n, DMA_QUEUE). SPR_update also queues sprite tile uploads, and the order it uses decides what ignore-over-capacity drops first.
• Give the report a cause. mddma and mdprof should be one run: per frame, the DMA spill next to the functions that used the CPU. The fighters fix round failed for lack of that.
• My first test ROM burned about 5x more CPU than I meant, because I reused a cycle count from another build. The 0 KB phase showed 88% load, and I recalibrated against it. Keep an empty phase in any ROM like this.

The checker, the test ROM, both runs’ per-frame data, and every Claude scene with its report are in the project folder.