Castlevania (NES) / GAME HISTORY

Why Can NES Castlevania Crash During the Death Fight?

The early US revision can return from an interrupt with the wrong ROM bank selected. Busy scenes expose more than sprite flicker.

By Patchlo Editorial Desk · Published October 21, 2026 · Sources checked October 21, 2026

Scope: Original NES Castlevania, US revision 0. This is separate from the Nintendo DS Portrait of Ruin dialogue softlock.

A crowded screen does not explain the whole freeze

The Death fight fills the room with threats the player must track while attacking. If the game freezes there, sprite overload is an easy diagnosis. Ordinary sprite limitations, however, are not the same failure as execution resuming with the wrong part of the game’s program available.

The NESdev bug entry identifies the latter problem in the early US revision. An NMI is an interrupt normally used for work associated with the next display frame. Bank switching selects which section of cartridge data or code is accessible. If the selection is wrong when game logic resumes, execution can fail. [1]

The revision belongs in the bug’s name

Calling this “the Castlevania crash” hides an important boundary: the technical entry singles out US revision 0. A different release failing to reproduce it is not automatically evidence that a player imagined the original fault.

It also prevents a misleading shortcut. A freeze in a later collection could have another cause; this historical explanation is not a diagnosis of every emulator, ROM modification or modern port.

The distinction from Portrait of Ruin is equally useful. There, skipping a scene and returning to a room can block progress. Here, the documented issue concerns interrupt handling and the selected ROM bank. Both stop a run, but they leave very different evidence behind.