Myths: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
 
(48 intermediate revisions by 13 users not shown)
Line 2: Line 2:


== NTSC picture height ==
== NTSC picture height ==
'''Myth:''' The NTSC NES picture is 224 pixels tall.
'''Myth:''' The NTSC NES picture is only 224 pixels tall. (Seen in [http://nesdev.org/nesfreq.txt nesfreq.txt], [http://ngemu.com/threads/true-resolution-of-psx-320x224.59392/#post-826552 a post by chaotic_thought on ngemu.com], and elsewhere)


'''Fact:''' The NTSC NES picture is 240 pixels tall.
'''Fact:''' The NTSC NES picture is 242 pixels tall: 240 lines of picture and 2 lines of vertical border.
The PPU fetches and generates a signal for all 240 lines, even if TVs [[overscan|cut off the edges]].
The PPU fetches and generates a signal for all 240 lines, even if TVs [[overscan|cut off the edges]].


Some emulators simulate overscan in order to hide nametable [[mirroring]] glitches. For example, PocketNES for Game Boy Advance hides the top 16 pixels, the bottom 11, and 8 on the left and right sides. The Mega Man Anniversary Collection (GameCube/XBOX/PS2) '''does not''' display the top/bottom 8 pixels, plus an extended left/right clipping in order to hide the attribute color warp "glitch" in both sides.
Ideally, NES games place nametable [[mirroring]] glitches in the overscan, and some emulators simulate overscan in order to hide these glitches. For example, PocketNES for Game Boy Advance hides the top 16 pixels, the bottom 11, and 8 on the left and right sides. The Mega Man Anniversary Collection (GameCube/XBOX/PS2) likewise hides the top/bottom 8 lines, plus an extra left/right clipping to hide the attribute color glitch on scrolling. Also, the Wii Virtual Console (NES) does not display the top and bottom 8 lines.


== Scrolling registers ==
== Scrolling registers ==
'''Myth:''' You always need to use the VRAM address register ($2006) to scroll.
'''Myth:''' Usage of the [[PPUADDR]] ($2006) register is needed to scroll. (Seen in [[Nestech.txt#Programming the NES|Nestech.txt section 10: Programming the NES]])


'''Fact:''' The proper way to set the scroll position is to write the upper bits of the X and Y coordinates to PPUCTRL ($2000), and then bits 0-7 of the X and Y coordinates to PPUSCROLL ($2005). The NES will update the VRAM address register for you near the end of the pre-render scanline (261 on NTSC, 311 on PAL).
'''Fact:''' The proper way to [[PPU scrolling|set the scroll position]] is to write the upper bits of the X and Y coordinates to [[PPUCTRL]] ($2000), and then bits 0-7 of the X and Y coordinates to [[PPUSCROLL]] ($2005). The NES will update the VRAM address register near the end of the pre-render scanline (261 on NTSC, 311 on PAL).


The only time you need to use $2006 to scroll, as described in Loopy's document "The skinny on NES scrolling", is if you're trying to change the vertical part of the scroll position during rendering time. This could happen if you turn rendering on late to free up more VRAM update time or if you are splitting the screen.
PPUADDR ($2006) is needed to scroll only when changing the vertical part of the scroll position during rendering time. This could happen if rendering is turned on late to free up more VRAM update time, or the screen is split.
 
''Super Mario Bros.'' appears to zero out PPUADDR after writing a buffer to PPUDATA, but this was later discovered to be a workaround for a rare [[PPU registers#Palette corruption|palette corruption]] bug instead.


== Mappers ==
== Mappers ==
=== MMC4 ===
'''Myth:''' The [[MMC4]] is used in the Japanese version of ''Mike Tyson's Punch-Out!!'' (source: [https://gamefaqs.gamespot.com/nes/916386-nes/faqs/2949 Nintendo Entertainment System Documentation v0.40 by Y0SHi])
'''Fact:''' The MMC4 is used only in three Japan-only games published by Nintendo in the ''Famicom Wars'' and ''Fire Emblem'' series. Known Japanese versions of ''Mike Tyson's Punch-Out!!'' use the same [[MMC2]] as their American and PAL counterparts.
=== MMC5 ===
'''Myth:''' The [[MMC5]] supports [[mirroring#4-Screen|memory for 4-screen nametables]] (source: [https://gamefaqs.gamespot.com/nes/916386-nes/faqs/2949 Nintendo Entertainment System Documentation v0.40 by Y0SHi])
'''Fact:''' MMC5 uses the 2 KiB of RAM in the Control Deck for two nametables. It has its own 1 KiB ExRAM, and one of the four possible modes for ExRAM uses it as a third nametable. It also supports fill mode, a fourth limited-function nametable filled with 960 copies of a single tile number. So in total, while the MMC5 supports four different modes for each nametable, it does not support memory for the sort of 4-screen nametables seen in ''Napoleon Senki'' and ''Gauntlet''.
=== VRC6 ===
'''Myth:''' The VRC6 is a very complex mapper even superior to the MMC5.
'''Myth:''' The VRC6 is a very complex mapper even superior to the MMC5.


'''Fact:''' The VRC6 is a decent mapper able to do standard PRG and CHR bankswitching, a pseudo-scanline counter, and have extre 3 sound channels. The MMC5 have extended video possibilities, a true scanline counter, and countless features that the VRC6 lacks, but only have 2 extra sound channels. Rumor has been made that the VRC6 was supperior to the MMC5 because the MMC5 Castlevania III was censored, and didn't use extra sound. For the truth Castlevania III doesn't even come close to using all MMC5 capabilities.
'''Fact:''' The [[VRC6]] is a decent mapper able to do standard PRG and CHR bankswitching, a CPU cycle counter, and 3 extra sound channels. The [[MMC5]] has extended video possibilities, a true scanline counter, and countless features that the VRC6 lacks, but only has 2 extra sound channels. Rumor has been made that the VRC6 was superior to the MMC5 <!-- To do: find a source for this rumor --> because the MMC5 ''Castlevania III: Dracula's Curse'' was censored, and (like other 72-pin games) didn't use extra sound. But in fact, ''Castlevania III'' doesn't even come close to using all MMC5 capabilities, and it likely used MMC5 because it supported the VRC6's PRG ROM and CHR ROM bankswitching modes and was cheaper than Konami getting the VRC6 approved through Nintendo of America and Nintendo of Europe.


== Largest game ==
== Largest game ==
'''Myth:''' Dragon Quest/Warrior IV is the largest NES game, having 1 MiB (1048576 bytes) of ROM.
'''Myth:''' ''Dragon Quest/Warrior IV'' (DQ4) is the largest NES game, having 1 MiB (1,048,576 bytes) of ROM. (Source: [http://nesdev.org/NESTechFAQ.htm#biggestgame NES Technical/Emulation/Development FAQ version 1.4] via [https://www.reddit.com/r/todayilearned/comments/2qdz5q/til_the_biggest_offical_nes_game_ever_made_was/ Reddit])
 
'''Fact:''' Both the Japanese ''Dragon Quest IV'' and the American ''Dragon Warrior IV'' releases use [[SxROM|SUROM]], as pictured at [http://bootgod.dyndns.org:7777/profile.php?id=1276 NesCartDB's entry for ''Dragon Warrior IV'']. They use 512 KiB PRG ROM and 8 KiB CHR RAM, which is not larger than quite a few other licensed games. This rumor was due to a 1MiB overdump of ''Dragon Quest IV'' floating around.


'''Fact:''' Dragon Quest/Warrior IV is as big as Mega Man VI, with 512 KiB PRG ROM. This rumor was due to a 1MB overdump floating around.
Games larger than ''Dragon Quest IV'' include the following:
* The largest licensed Famicom game is ''Metal Slader Glory'' (512 KiB PRG + 512 KiB CHR + [[MMC5]]).
* The largest licensed NES game is ''Kirby's Adventure'' (512 KiB PRG + 256 KiB CHR + [[MMC3]]).
* The largest unlicensed non-pirate NES game from the original era is ''Action 52'' (1,536 KiB PRG + 512 KiB CHR + [[iNES Mapper 228|custom mapper]]).
* The largest unlicensed non-pirate NES production from the modern era is ''A Winner Is You'' (64 MiB), which is a music cartridge and not a game.
* One large "Hong Kong Original" port is ''[[wikipedia:Final Fantasy VII (NES video game)|Final Fantasy VII]]'' (2 MiB PRG + CHR RAM).
* Some pirate multicarts are 4 MiB or larger.
<!-- Any 1 MiB+ non-pirate modern 72-pin games? -->


Games larger than DQ4 include the following:
The largest games cannot be represented in the the original [[iNES]] format, which has a practical limit of 2 MiB PRG ROM and 1 MiB CHR ROM. [[NES 2.0]] should be used instead.
* The largest licensed Famicom game is Metal Slader Glory (512 KiB PRG + 512 KiB CHR + MMC5).
* The largest licensed NES game is Kirby's Adventure (512 KiB PRG + 256 KiB CHR + MMC3).
* The largest unlicensed non-pirate NES game is Action 52 (1536 KiB PRG + 512 KiB CHR + custom mapper).
* One large "Hong Kong Original" port is [[wikipedia:Final Fantasy VII (Famicom)|Final Fantasy VII]] (2048 KiB PRG + CHR RAM).
* Some pirate multicarts are 4 MiB or larger. These cannot be represented in the the original [[iNES]] format, which has a practical limit of 2048 KiB PRG ROM and 1024 KiB CHR ROM. Use [[NES 2.0]] instead.


== Old programs ==
== Old programs ==
'''Myth:''' If a binary file has a .nes file extension, it will work as intended on an NES, and I should tweak my emulator to match how it is supposed to work.
'''Myth:''' If a binary file has a .nes file extension, it will work as intended on an NES, and emulators should be tweaked to match how it is supposed to work.


'''Fact:''' No. Especially older NES programs tend to have been tested only on bad emulators. Your college-project emulator should match the behavior of an NES or at least that of an accurate emulator.
'''Fact:''' No, especially older NES programs tend to have been tested only on bad emulators. Emulators should match the behavior of an NES or at least that of an accurate emulator. Dirty iNES headers might break it.


A lot of emulators, especially prior to about 2005, were based on incomplete knowledge of how the NES works.
A lot of emulators, especially prior to about 2005, were based on incomplete knowledge of how the NES works. Some old demos expect all internal memory ($0000-$07FF) to be $00. Since then, public knowledge of the [[errata|quirks of the NES hardware behavior]] has grown, and emulators such as Mesen and Nintendulator more faithfully reproduce the misbehaviors in sloppy or [[wikipedia:Cargo cult programming|cargo-cult-programmed]] code.
Since then, public knowledge of the quirks of the NES hardware behavior has grown, and emulators such as Nintendulator and Nestopia more faithfully reproduce the misbehaviors in sloppy or [[wikipedia:Cargo cult programming|cargo-cult-programmed]] code.
See [[Program Compatibility]] for a list of homebrew known to have problems on an NES.
See [[Program Compatibility]] for a list of programs known to work and known not to work on an NES.


== Old tutorials ==
== Old tutorials ==
'''Myth:''' [http://patater.com/gbaguy/nesasm.htm GBAGuy's NES tutorial] is worth following.
'''Myth:''' [http://patater.com/gbaguy/nesasm.htm GBAGuy's NES tutorial] is worth following.


'''Fact:''' Old tutorials like these are full of cargo-cult programming because the authors apparently didn't fully understand the hardware. A lot of the programs from the tutorial don't even work on an NES. [http://nesdev.parodius.com/NES101.zip NES 101] and [http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=7155 Nerdy Nights] are considered better.
'''Fact:''' Old tutorials like these are full of cargo-cult programming because the authors apparently didn't fully understand the hardware. For example, this tutorial in particular treats the [[PPU registers|OAM address]] register as 16-bit (just like [[PPUADDR]]) and attempts to initialize variables in [[wikipedia:.bss|system RAM]] using .db statements - a lot of the programs don't even work on a NES. [http://nesdev.org/NES101.zip NES 101] and [https://nerdy-nights.nes.science Nerdy Nights] are considered better. Even the webmaster of Patater.com now recommends Nerdy Nights.
 
== PPU details ==
'''Myth:''' [[OAMADDR]] ($2003) must be cleared on VBlank ending.
 
'''Fact:''' The PPU itself sets the sprite address to zero at the end of VBlank, but due to a design flaw it can result in minor sprite RAM corruption if it was nonzero beforehand - in particular, it can cause values from one 8-byte "page" of sprite RAM to leak into another due to its lack of proper memory refreshing. Some Chinese games actually rely on this behavior and will lock up otherwise.
 
'''Myth:''' "There is 16k of internal VRAM" (source [https://www.gamefaqs.com/nes/916386-nes/faqs/2949 Nestech.txt 0.40 by Y0shi])
 
'''Fact:''' The PPU has an address range of 14 bits addressing 16 KiB, but there's only 2 KiB of internal VRAM, typically used for nametables. This was corrected to "16 kbits" in later editions of [[Nestech.txt]].
 
== Color emphasis ==
'''Myth:''' Enabling more than one [[Colour emphasis|color emphasis]] bit at once will damage the PPU, or at least cause the TV to lose sync. (Source: [http://fms.komkon.org/EMUL8/NES.html Nintendo Entertainment System Architecture] by Marat)
 
'''Fact:''' Enabling multiple color emphasis bits is perfectly safe - in fact, [[Colour-emphasis games|some licensed games]] including ''Felix the Cat'' and ''Just Breed'' enable all of them simultaneously to dim the screen. On the other hand, enabling all emphasis bits results in an unreadable white screen on an RGB PPU, such as that in the Famicom Titler or the Sharp C1 (Famicom TV). Worse, setting the PPU into ''slave'' mode (by setting the ''master/slave'' bit in [[PPUCTRL]]) is theoretically capable of causing actual damage, as it results in high current draw from the EXT pins (due to them trying to output +5V despite being wired to GND).

Latest revision as of 17:58, 25 February 2024

This page documents some myths about the NES hardware that originate in obsolete documents and emulators.

NTSC picture height

Myth: The NTSC NES picture is only 224 pixels tall. (Seen in nesfreq.txt, a post by chaotic_thought on ngemu.com, and elsewhere)

Fact: The NTSC NES picture is 242 pixels tall: 240 lines of picture and 2 lines of vertical border. The PPU fetches and generates a signal for all 240 lines, even if TVs cut off the edges.

Ideally, NES games place nametable mirroring glitches in the overscan, and some emulators simulate overscan in order to hide these glitches. For example, PocketNES for Game Boy Advance hides the top 16 pixels, the bottom 11, and 8 on the left and right sides. The Mega Man Anniversary Collection (GameCube/XBOX/PS2) likewise hides the top/bottom 8 lines, plus an extra left/right clipping to hide the attribute color glitch on scrolling. Also, the Wii Virtual Console (NES) does not display the top and bottom 8 lines.

Scrolling registers

Myth: Usage of the PPUADDR ($2006) register is needed to scroll. (Seen in Nestech.txt section 10: Programming the NES)

Fact: The proper way to set the scroll position is to write the upper bits of the X and Y coordinates to PPUCTRL ($2000), and then bits 0-7 of the X and Y coordinates to PPUSCROLL ($2005). The NES will update the VRAM address register near the end of the pre-render scanline (261 on NTSC, 311 on PAL).

PPUADDR ($2006) is needed to scroll only when changing the vertical part of the scroll position during rendering time. This could happen if rendering is turned on late to free up more VRAM update time, or the screen is split.

Super Mario Bros. appears to zero out PPUADDR after writing a buffer to PPUDATA, but this was later discovered to be a workaround for a rare palette corruption bug instead.

Mappers

MMC4

Myth: The MMC4 is used in the Japanese version of Mike Tyson's Punch-Out!! (source: Nintendo Entertainment System Documentation v0.40 by Y0SHi)

Fact: The MMC4 is used only in three Japan-only games published by Nintendo in the Famicom Wars and Fire Emblem series. Known Japanese versions of Mike Tyson's Punch-Out!! use the same MMC2 as their American and PAL counterparts.

MMC5

Myth: The MMC5 supports memory for 4-screen nametables (source: Nintendo Entertainment System Documentation v0.40 by Y0SHi)

Fact: MMC5 uses the 2 KiB of RAM in the Control Deck for two nametables. It has its own 1 KiB ExRAM, and one of the four possible modes for ExRAM uses it as a third nametable. It also supports fill mode, a fourth limited-function nametable filled with 960 copies of a single tile number. So in total, while the MMC5 supports four different modes for each nametable, it does not support memory for the sort of 4-screen nametables seen in Napoleon Senki and Gauntlet.

VRC6

Myth: The VRC6 is a very complex mapper even superior to the MMC5.

Fact: The VRC6 is a decent mapper able to do standard PRG and CHR bankswitching, a CPU cycle counter, and 3 extra sound channels. The MMC5 has extended video possibilities, a true scanline counter, and countless features that the VRC6 lacks, but only has 2 extra sound channels. Rumor has been made that the VRC6 was superior to the MMC5 because the MMC5 Castlevania III: Dracula's Curse was censored, and (like other 72-pin games) didn't use extra sound. But in fact, Castlevania III doesn't even come close to using all MMC5 capabilities, and it likely used MMC5 because it supported the VRC6's PRG ROM and CHR ROM bankswitching modes and was cheaper than Konami getting the VRC6 approved through Nintendo of America and Nintendo of Europe.

Largest game

Myth: Dragon Quest/Warrior IV (DQ4) is the largest NES game, having 1 MiB (1,048,576 bytes) of ROM. (Source: NES Technical/Emulation/Development FAQ version 1.4 via Reddit)

Fact: Both the Japanese Dragon Quest IV and the American Dragon Warrior IV releases use SUROM, as pictured at NesCartDB's entry for Dragon Warrior IV. They use 512 KiB PRG ROM and 8 KiB CHR RAM, which is not larger than quite a few other licensed games. This rumor was due to a 1MiB overdump of Dragon Quest IV floating around.

Games larger than Dragon Quest IV include the following:

  • The largest licensed Famicom game is Metal Slader Glory (512 KiB PRG + 512 KiB CHR + MMC5).
  • The largest licensed NES game is Kirby's Adventure (512 KiB PRG + 256 KiB CHR + MMC3).
  • The largest unlicensed non-pirate NES game from the original era is Action 52 (1,536 KiB PRG + 512 KiB CHR + custom mapper).
  • The largest unlicensed non-pirate NES production from the modern era is A Winner Is You (64 MiB), which is a music cartridge and not a game.
  • One large "Hong Kong Original" port is Final Fantasy VII (2 MiB PRG + CHR RAM).
  • Some pirate multicarts are 4 MiB or larger.

The largest games cannot be represented in the the original iNES format, which has a practical limit of 2 MiB PRG ROM and 1 MiB CHR ROM. NES 2.0 should be used instead.

Old programs

Myth: If a binary file has a .nes file extension, it will work as intended on an NES, and emulators should be tweaked to match how it is supposed to work.

Fact: No, especially older NES programs tend to have been tested only on bad emulators. Emulators should match the behavior of an NES or at least that of an accurate emulator. Dirty iNES headers might break it.

A lot of emulators, especially prior to about 2005, were based on incomplete knowledge of how the NES works. Some old demos expect all internal memory ($0000-$07FF) to be $00. Since then, public knowledge of the quirks of the NES hardware behavior has grown, and emulators such as Mesen and Nintendulator more faithfully reproduce the misbehaviors in sloppy or cargo-cult-programmed code. See Program Compatibility for a list of homebrew known to have problems on an NES.

Old tutorials

Myth: GBAGuy's NES tutorial is worth following.

Fact: Old tutorials like these are full of cargo-cult programming because the authors apparently didn't fully understand the hardware. For example, this tutorial in particular treats the OAM address register as 16-bit (just like PPUADDR) and attempts to initialize variables in system RAM using .db statements - a lot of the programs don't even work on a NES. NES 101 and Nerdy Nights are considered better. Even the webmaster of Patater.com now recommends Nerdy Nights.

PPU details

Myth: OAMADDR ($2003) must be cleared on VBlank ending.

Fact: The PPU itself sets the sprite address to zero at the end of VBlank, but due to a design flaw it can result in minor sprite RAM corruption if it was nonzero beforehand - in particular, it can cause values from one 8-byte "page" of sprite RAM to leak into another due to its lack of proper memory refreshing. Some Chinese games actually rely on this behavior and will lock up otherwise.

Myth: "There is 16k of internal VRAM" (source Nestech.txt 0.40 by Y0shi)

Fact: The PPU has an address range of 14 bits addressing 16 KiB, but there's only 2 KiB of internal VRAM, typically used for nametables. This was corrected to "16 kbits" in later editions of Nestech.txt.

Color emphasis

Myth: Enabling more than one color emphasis bit at once will damage the PPU, or at least cause the TV to lose sync. (Source: Nintendo Entertainment System Architecture by Marat)

Fact: Enabling multiple color emphasis bits is perfectly safe - in fact, some licensed games including Felix the Cat and Just Breed enable all of them simultaneously to dim the screen. On the other hand, enabling all emphasis bits results in an unreadable white screen on an RGB PPU, such as that in the Famicom Titler or the Sharp C1 (Famicom TV). Worse, setting the PPU into slave mode (by setting the master/slave bit in PPUCTRL) is theoretically capable of causing actual damage, as it results in high current draw from the EXT pins (due to them trying to output +5V despite being wired to GND).