Exciting Developments for NES ROMs

When it comes to the NES, everybody at one point or another has emulated the NES.  NES emulation has been around for a long time and has improved so much that often the experience of playing a game on an emulator is indistinguishable from playing the game on real hardware (accounting for video improvements via emulation.)  But NES emulation is continually evolving as we find more games to dump and understand better the hardware found inside previously-dumped games.  In this blog post let me share some recent developments regarding NES ROMs.




History of NES ROMs

Sometime in the mid 1990s, the first NES emulator. Pasofami, used split PRG and CHR ROMs with a third file (with a .PRM extension) to tell the emulator how to make the game work.  (In this format you would have Super Mario Bros.prg and a Super Mario Bros.chr files).  Then came the  iNES emulator, which used a different format.  The iNES format combined the PRG and CHR (if any) ROMs into one file and added a 16-byte header to the beginning of the file to tell the emulator what hardware the game used.  PasoFami and iNES were emulators you had to pay for, but when the free emulator NESticle adopted the iNES format, that format's dominance was assured.

By the mid 2000s, it became apparent that iNES, in its current form, was not able to accurately describe the vast hardware of NES and Famicom games.  The main problem is that it allowed only 256 mappers to be assigned, and with various individuals making new assignments, the available pool of mappers would disappear.  In addition, some games which use the same mapper number have subtle differences in the way they work but those differences are sufficient to break the game unless it is emulated the variant way it expects to run.  Other games have unusual hardware that cannot be defined by the mapper alone such as EEPROM, partially battery backed W-RAM or CHR-RAM and extra data that is not  PRG or CHR ROM.

The first important attempt to address the problem was the creation of the UNIF format in 2000.  UNIF described hardware in terms of PCB names and used various labels to designate the place in the file where the PRG and CHR ROMs are stored.  For several reasons, UNIF never displaced iNES for emulators.  Flash carts have never supported it.  The second attempt was the establishment of the NES 2.0 format in 2006.  NES 2.0 was compatible with iNES 1.0 headers, unlike UNIF.  Nintendo also developed an iNES-like format called TNES, but that was only used for 3DS Virtual Console.

The NESDev community has taken to NES 2.0 and have assigned new mappers above the 256 barrier and gave more submapper definitions and expanded on the original NES 2.0 standard.  While there have been more NES emulators released than for any other system, (Zophar's Domain lists 94 emulators for Windows alone) many of them are old or not particularly accurate.  There are at least six emulators, BizHawk, FCEUX, Nintedulator, MAME, no$nes and puNES which now support some form of NES 2.0.

Benefits of NES 2.0 : Increased ROM Size, More Flexible RAM Support and Submappers

Normal iNES 1.0 can support up to 4MB of PRG ROM and 2MB of CHR ROM.  There are ROMs which exceed this limit (PocketStation Coolboy 150-in-1 is 32MB).  NES 2.0 originally maintained those limits but now can designate up to 64MB of PRG ROM and 32MB of CHR ROM.  There is an alternate proposal that provides for even greater amounts of storage.

Some cartridges contained extra W-RAM that may or may not have been battery backed.  Other cartridges used CHR-RAM instead of CHR-ROM.  Normal iNES 1.0 assumes no more than 8KB of W-RAM or CHR-RAM.  Sometimes mappers can imply the presence of additional W-RAM (Mapper 5), additional CHR-RAM (Mapper 13) or a combination of CHR-ROM and CHR-RAM.  NES 2.0 allows you to designate from 128 bytes to 1MB of W-RAM and CHR-RAM and explicitly allows CHR-ROM and CHR-RAM games.  The smallest sizes of W-RAM can be assumed to be EEPROM (used by Bandai Famicom games).  NES 2.0 also alows you to designate how much of each type of RAM is and is not battery backed.  There are ROMs (Racermate Challenge II) that backed up a portion of CHR-RAM to save game information.  There is also at least one ROM (Low-G-Man) which will crash if any W-RAM is present.

Submappers is key to improving emulation accuracy.  Games were given iNES 1.0 mapper assignments in a haphazard way.  Games were often lumped together based on assumptions that later turn out to be untrue.  One of the most famous examples is Mapper 78, used by Holy Diver and Uchuusen - Cosmo Carrier.  These games have incompatible mirroring methods, so emulating one type of mirroring will lead to incorrect graphics for the other game.  Another famous example is using Mapper 4 to include the Startropics games.  Mapper 4 games use the MMC3 chip, but the Startropics games use MMC6.  MMC6 is an MMC3 with some embedded S-RAM.  The problem comes into play when you have a game that requires the absence of S-RAM, like Low-G-Man, to function correctly. 

Emulators can get around this issue by using CRC checks to emulate the games properly, but CRC checks fail the moment the ROM is changed.  Submappers ensure that whatever hacks or translations are done to the ROMs, the games will work as intended.

Submappers can also be used to set the mixing volume for Namco 163 expansion audio games.  It has been found that for the ten games that use Namco 163 expansion audio, they mix their audio with the Famicom's internal audio at different volume levels.  The submappers will ensure that the proper mix is used.

Benefits of NES 2.0 : Improved Vs. System, Clone and Peripheral Support

The NES 2.0 standard now gives a great deal of information for emulator authors wanting to support the Vs System.  It will identify the type of PPU required (13 known non 2C02/2C07 PPUs exist), the protection used if any (6 known types) and the control scheme (4 variations).  Vs. Dual System emulation used to be solely implemented in MAME, but now Nintendulator-NRS and Mesen support Dual System games.

The NES 2.0 standard also allows you to designate the console type, whether an NTSC, PAL or Dendy console.  Dendy consoles are something of a mix between NTSC and PAL consoles and some ROMs will only work properly on a Dendy.  There are also Famiclone consoles that do not behave as original Famicoms should and some games only work with those console variants.

Finally, with NES 2.0 as currently expanded, ROMs can be set to designate a default input device.  There are many input devices, some of which are very obscure, which do not function like a standard controller or light gun.  This is very helpful when people try to play these games and take a while to discover that the game requires a special but obscure peripheral to work.

Benefits of NES 2.0 : Support for extra, non PRG & CHR ROMs

All NES games require PRG ROM, and the majority use a separate CHR ROM for graphics tiles.  However, some games require additional data for them to function fully.  The best example is the PlayChoice-10 ROMs, which have an additional 8K tacked called the INST ROM onto the end of them and another 32 bytes used for decrypting the INST ROMs.  Most emulators know about these and there is a PC-10 flag in iNES 1.0 to distinguish them.  One hopes that the extra ROM field will be used by emulators other than MAME to support the PC-10 in the future.

Other games also require extra ROM information.  The best examples are the Jaleco Moero!! games.  These games use an ADPCM chip with a fair amount of ROM in the chip to store samples.  Family Trainer 3 : Aerobics Studio uses another type of ADPCM chip.  One day these chips will be decapsulated or the ROM within them will be read via other means and then their audio can be emulated properly.  A bootleg version of Moero!! Pro Yakyuu used a similar DPCM chip and was able to be dumped because the data was stored in an external ROM.  It uses a submapper and can now be played in Nintendulator-NRS. The samples sound similar to but are not identical to the genuine Moero!! Pro Yakyuu cartridge.  Until the other games are dumped, emulators will have to use pre-recorded samples to playback the digital audio.

Two games (3D Block by Hwang Shinwei and Block Force) were found recently to contain PIC microcontrollers for their IRQ controller.  Nintendulator-NRS can simulate what the microcontroller does to get the Block Force running, but a true emulation of 3D Block will require the program code from the microcontroller, which has a protection feature preventing easy dumping.

Support for Famicom Disk System Cartridge Conversions

Almost 200 games were released for the Famicom Disk System, but not everyone had a disk system.  In Taiwan, pirate outfits were pirating all the Famicom games they could get their hands on.  Two pirate companies in particular, Whirlwind Manu and Kaiser, also converted several FDS games to cartridge.  While companies like Nintendo and Konami also did FDS to cartridge conversions, they had the benefit of the original source code.  The pirates did not and had to get creative to make these games work.

One benefit to these cartridge conversions is the disk loading times are gone.  However, there are several drawbacks.  Any game that saves to disk will not save to cartridge.  Some games have hacked title screens, missing features and at least one will fail partway through the game.  The original pirate cartridges did not do anything with FDS audio, so the music will sound noticeably inferior in those games which use FDS audio.  However, most of those games still have their FDS audio included in their data.  Nintendulator-NRS has a feature to play back expansion audio on bootleg cartridges.

FDS games came on disk which used a rudimentary file system.  To get these games working on cartridges, which have no file system, they often had to design custom hardware for each game.  This custom hardware required breaking into the mapper numbers above 256 to accomodate this hardware.  Nintendulator-NRS can handle all the FDS Cartridge conversions and produce the FDS audio generated by each ROM.  The Nt Mini can theoretically also allow FDS channels while a cartridge ROM is running, but most of the FDS conversions use mappers above 255, which the Nt Mini does not support. 

You can find some of the more recent FDS conversion dumps and Nintendulator-NRS http://masterdisk.byethost15.com/blog/libg/index.php  Other FDS conversions can be found in GoodNES, NonGoodNES and here http://cah4e3.shedevr.org.ru/

Action 52 and Flash Carts

One of the only games released during the NES's lifespan that the available flash carts, the NES PowerPak and EverDrive N8, was Action 52.  Action 52 contains a huge amount of PRG-ROM, 1.5MB and CHR-ROM, 512KB.  The flash carts only support up to 512KB of PRG-ROM and 512KB of CHR-ROM.  So it appeared for the longest time that Action 52 would have to wait until the next generation of NES and Famicom flash carts.

Recently, SmokeMonster asked me if I knew of any way to play or split Action  52 to work on a flash cart.  I replied that I did not.  However, his question made me wonder if I had acquired enough knowledge about the NES to try to figure it out.  The first stop was the NESDev wiki, which explained how the Mapper, 228, for Action 52 worked.  I had looked at the documentation previously but did not really understand it.  Now I looked at it again and understood that bankswitching is reliant not just on the data written but the address to which the data is written. 

Having understood how the bankswitching worked, I was assisted by the very inefficient memory layout of the Action 52.  The PRG is setup as 3 banks consisting of 16 32KB banks.  There is no "last bank" in this Mapper which holds program kernels, leading to a lot of code duplication.  I then found that almost every one of the 52 games is contained within a single 32KB bank, but some games contain two games, so splitting each game into a 32KB PRG-ROM + 512KB CHR-ROM would not work. 

When the 2MB ROM is split into 3 512KB PRG-ROM + 512KB CHR-ROM, the 2nd ROM will work with the games contained within that 512KB PRG-ROM bank.  The menu is contained in the 2nd main bank, 1st 32KB.  The menu will also work if transplanted into the 3rd main bank, 1st 32KB without any further alteration.  That does mean that the game that was located in that bank has to be made its own game, but using the menu to select games is the best way to get the games in the 2nd and 3rd bank working. 

Between the 2nd and 3rd bank, we have most of the games working.  I edited the menu entries for each ROM to show only those games the ROM contains.  The other entries can still be selected, but they will just pick another game within the ROM.

That leaves the games in the 1st bank and the displaced game from the 3rd bank.  The 1st bank contains the Lights, Camera, Action "Make Your Selection Now" sequence.  It also contains 1 32KB game, the Cheetamen game (7 32KB banks) and Billy Bob (7 32KB banks).  I was able to get Cheetamen to progress through all six levels and play the opening cutscene by combining all the banks into one ROM and editing a reset vector.  I attempted to do the same for Billy Bob but the game was too frustrating to playtest.  If you play Billy Bob from the menu on a real cartridge, you only go up to Level 5.  I found more levels that are not playable from the real cart, so I split all the levels or level pairs into their separate ROMs. 

You can download an archive containing all the split ROMs here : http://www.mediafire.com/file/dx6v9o9ye6tbj9h/Action_52.7z/file

Fixing a Bus Conflict

Cybernoid is the only licensed NES game that could fail if your emulator or flash cart fails to implement bus conflicts properly.  A bus conflict results when two sources on a bus assert the bus in different ways.  Typically if a CPU writes a value to a location where ROM resides, and the ROM is not disabled, and the ROM contains a different value, the device with the lowest impedance wins.  When dealing with CPUs and ROM chips of the same vintage, the CPU almost invariably wins.  A flash cart operates rather differently and the CPU may lose the conflict. 

In the NES, the CPU typically writes to the memory area inhabited by a ROM chip to initiate a bankswitch.  Many cartridges had ASICs or extra hardware that would disable a ROM during a memory write so the CPU could send a value to the bankswitching hardware without the ROM's value interfering.  However, many cartridges used cheaper bankswitching hardware that did not disable their ROMs.  Programmers could avoid the bad effects of bus conflicts by having the CPU write a value to a ROM memory location which already contained that value.  When that happened, the value would be guarateed to reach the bankswitch circuit intact. 

Cybernoid uses a simple Mapper, 3, which has no provisions for disabling the ROM to prevent bus conflicts.  Usually the game behaves, but if you switch the game's audio from sound effects to music, a stray unintentional write to the ROM will result in a bus conflict.  If the CPU loses the conflict, the wrong CHR-ROM will be banked and you will see nothing but glitchy graphics, even if you change the audio back. To fix this for good, change the byte in the ROM at $76BA from 8D to AD and save the resulting file.  This will result in the game playing properly in an EverDrive N8 regardless of whether audio is playing back sound effects or music.

While I can't take credit for the Cybernoid fix, I did independently discover a fix for another game with a bus conflict issue.  Nintendo released a hack of Donkey Kong called Donkey Kong: Original Edition for the Wii in Europe and later made it available in various regions for Club Nintendo members and later on the 3DS eShop.  The game added the cement factory level back into the NES game and included animations of Donkey Kong climbing up with Pauline.  The game was dumped from a Wii and found its way into GoodNES.

The original Donkey Kong ROM consisted of a 16KB PRG-ROM and an 8KB CHR-ROM.  In order to add the new features, Nintendo doubled the PRG-ROM and quadrupled the CHR-ROM.  This 32KB/32KB ROM now required a mapper, and Nintendo used Mapper 3, which allows switching CHR-ROM. 

When Nintendo did their hack, it forgot that Mapper 3 has no bankswitch conflict prevention circuitry.  Its bankswitching routine wrote values which were not identical to the location in ROM where they were written.  As a result, there can be unnecessary graphics corruption when Donkey Kong grabs Pauline.  This was first noted when people made reproduction cartridges for the game.  I decided one day to try and fix it.  I loaded up Mesen's debugger, set breakpoints for all the bankswitch writes and examined the value being written by the CPU and the value present in ROM.  The areas which were being written did not appear to be crucial, so I changed those bytes to match the values written.  Here are the values you should change to fix this problem :

$03A6: 00 to 01
$0A4D: 00 to 12
$0B5A: 00 to F7