If you appreciate the work done within the wiki, please consider supporting The Cutting Room Floor on Patreon. Thanks for all your support!
This article has a talk page!

Dr. Mario (NES)

From The Cutting Room Floor
Jump to navigation Jump to search

Title Screen

Dr. Mario

Developer: Nintendo R&D1
Publisher: Nintendo
Platform: NES
Released in JP: July 27, 1990
Released in US: October 1990
Released in EU: June 27, 1991
Released in AU: 1991

CodeIcon.png This game has unused code.
GraphicsIcon.png This game has unused graphics.
DebugIcon.png This game has debugging material.
PiracyIcon.png This game has anti-piracy features.

ProtoIcon.png This game has a prototype article
NotesIcon.png This game has a notes page
BugsIcon.png This game has a bugs page
DCIcon.png This game has a Data Crystal page

To do:
There appears to be some evidence that the extended string in Fever from the Game Boy version is in the game, but is unused.

Dr. Mario is a puzzle game featuring Mario, who throws colored pills into a bottle to match with like-colored viruses and destroy them. It's also been remade several times since.


Read about prototype versions of this game that have been released or dumped.
Prototype Info
Miscellaneous tidbits that are interesting enough to point out here.
Read about notable bugs and errors in this game.

Unused Graphics

These sprites were intended to appear in the cutscenes shown between levels.


Either a soccer ball or a meteor. Nobody knows.

Frosty the Airman?

A snowman in boots? Whatever it is, it does have a proper tilemap and behavior, and its placement in the sprite list suggests it was meant to appear in the Level 20 HIGH cutscene before the final UFO scene was implemented.

Dr-Mario-ball0.png Dr-Mario-ball1.png Dr-Mario-ball2.png

Some strange colorful lines, possibly an early virus-deletion animation. The final game uses a much simpler starburst graphic. This sprite appears in later prototypes of the arcade version.


What looks to be half of a large pill. This was added sometime after the PlayChoice-10 Virus prototype.

Unused Gameplay Behavior

The game has two leftovers from its earliest days of development, when it was called Virus.

  • Normally, Megavitamin halves fall down after the other halves are matched. In the first two builds of Virus, the options menu allowed players to turn this off, letting them stay in mid-air. In any version of the final, changing RAM address $724 to a non-zero value will cause the Megavitamins to stay in mid-air.
  • Normally, 2-Player mode continues until a player wins three times. In the first two builds of Virus, this number could be set in the options menu. Similar to the above, the number of games needed to win can be changed at RAM address $725.

Famicom Disk System Remnants

The game appears to have been originally developed for the Famicom Disk System, as many FDS BIOS routines and their associated variables are present in the final game.

Unused Alternate Controller Polling Routines

(ROM addresses are for the Rev 1 release but these are present in all final releases.)

The game contains unused alternate controller polling routines which originate from the FDS BIOS.

  • $B7E1 contains the polling routine used in the final game. It polls the controllers twice (including the Famicom's expansion port) and bitwise ANDs the results to work around DMC input corruption.
  • $B812 contains a routine which rereads the standard controllers in a loop until two polls match, which is a more typical workaround.
  • $B828 contains a routine which is identical to the previous one but combines inputs from the expansion port.
  • $B844 contains a polling routine which only reads the controllers once but treats expansion port inputs separately from standard controllers.

See the notes page for more details.

Disabled Demo Recording Mode

To do:
Demonstrate the recording mode on an FDS port, and include a video.

The game checks the memory address $0741 against a constant value of FF to determine if the demo inputs should be recorded instead of replayed. This address is normally set to 00, disabling this feature. Even if the check passes, inputs cannot be recorded in the final game as the game attempts to write these to ROM on the cartridge. Since the FDS loads code from disks into PRG-RAM instead, the recording mode would have been functional (and therefore used) during development.


The game features a simple anti-piracy check that will intentionally crash the game if the title screen is altered. On reset, the game performs an 8-bit checksum of the area of ROM containing the title screen tilemap data ($B900-$BDFF). If the check passes, RAM address $740 is set to 00 and the game runs normally. However, if it fails, $740 is set to FF instead. This address is checked whenever a pill lands; if it's set to FF, the game pulls whatever value is stored at RAM address $53, pushes it to the stack three times, and performs an RTS. This causes the CPU to jump somewhere in RAM, and since there's no valid program code there, the game soon crashes.

Interestingly, a very similar 8-bit checksum routine (and method of crashing) appears in Final Fantasy. Perhaps the programmers drew inspiration from NASIR?

(Source: Rachel Mae)