These sprites were intended to appear in the cutscenes shown between levels.
IT'S COMIN' RIGHT AT US!
Either a soccer ball or a meteor. Nobody knows.
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.
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.
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 or using the following Game Genie codes below will cause the Megavitamins to stay in mid-air.
Revision
Codes
JP/USA Rev 1
XVLEAE+AELEPA
JP Rev 0
XVZEZE+AEZELA
EU
XVLALE+AELAGA
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 or using either the following Game Genie code below.
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.
(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.
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?
This article has a talk page!
