Open bus behavior: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
(reordering paragraphs so that the note about $4016/4017 goes with the rest, and the examples are together in a block, also clarify that Castlevania case seems benign (00, 7F, FF all seem harmless?))
m (Paperboy seems more deliberate, so weaseling out with "most cases")
Line 11: Line 11:
Open bus can be limited to ''part'' of a byte. The controller ports ($4016, $4017) affect only bits 4-0. Bits 7-5 repeat the corresponding bits from the previous read, usually 010 from the high byte $40.
Open bus can be limited to ''part'' of a byte. The controller ports ($4016, $4017) affect only bits 4-0. Bits 7-5 repeat the corresponding bits from the previous read, usually 010 from the high byte $40.


Few games rely on CPU open bus behavior. In those commercial games that do, it seems to be unintentional due to a programming error.
Few games rely on CPU open bus behavior. In most cases of commercial games that do, it seems to be unintentional due to a programming error.


A few games read the region $6000-7FFF but have no WRAM present here. This can be a problem for emulators, as the original [[iNES]] file format had no way to specify a lack of WRAM, leaving the emulator to provide WRAM behavior in that region by default. ([[NES 2.0]] format corrects this by changing the default WRAM size to zero.) Perhaps one way to accommodate these games without needing to recognize their hash values is to fill WRAM with the high byte of the address.
A few games read the region $6000-7FFF but have no WRAM present here. This can be a problem for emulators, as the original [[iNES]] file format had no way to specify a lack of WRAM, leaving the emulator to provide WRAM behavior in that region by default. ([[NES 2.0]] format corrects this by changing the default WRAM size to zero.) Perhaps one way to accommodate these games without needing to recognize their hash values is to fill WRAM with the high byte of the address.

Revision as of 16:54, 27 August 2017

When the CPU attempts to read from an address which has no devices active, the result is open bus behavior. The value that results from a read in such a region is undefined, but on specific hardware predictable results may appear.

CPU open bus

On a standard NES, reading open bus repeats the last value that was read from the bus before this read. Relevant cases:

  • Absolute addressed instructions will read the high byte of the address (the last byte of the operand).
  • Indexed addressing uses the high byte of the base address read from the instruction's operand; the index register does not yet apply when that value is read.
  • Indirect addressing will fetch the high byte of the pointer last. The Y index does not apply.
  • A DMC DMA may also alter the last value read if it interrupts an instruction.

Open bus can be limited to part of a byte. The controller ports ($4016, $4017) affect only bits 4-0. Bits 7-5 repeat the corresponding bits from the previous read, usually 010 from the high byte $40.

Few games rely on CPU open bus behavior. In most cases of commercial games that do, it seems to be unintentional due to a programming error.

A few games read the region $6000-7FFF but have no WRAM present here. This can be a problem for emulators, as the original iNES file format had no way to specify a lack of WRAM, leaving the emulator to provide WRAM behavior in that region by default. (NES 2.0 format corrects this by changing the default WRAM size to zero.) Perhaps one way to accommodate these games without needing to recognize their hash values is to fill WRAM with the high byte of the address.

Examples:

  • Castlevania: Just after the introduction will read a few values from ~$7FFX before the first stage begins. (The consequences appear to be harmless, however.)
  • Low G Man: WRAM instead of open bus behavior may cause a crash in Chapter 1 Scene 3B a few seconds into the boss fight music, or graphical glitches when using the boomerang weapon.[1]
  • Battletoads & Double Dragon: At the end of the first level, reads a values from ~$600X when the Abobo boss finished destroying the wall. A value of $00 read here will crash the game.[2]
  • Paperboy: Relies on the controller port being exactly $41 for a button press to be recognized.[3]

PPU open bus

The PPU has two data buses: the I/O bus, used to communicate with the CPU, and the video memory bus. Their open bus behavior differs.

Writes to any PPU port, including the nominally read-only status port at $2002, load a value onto the PPU's I/O bus. Reading a value from $2004 or $2007 loads a byte from OAM, video memory, or the palette onto this bus. Reading the PPU's status port loads a value onto bits 7-5 of the bus, leaving the rest unchanged. Reading any PPU port, including write-only ports $2000, $2001, $2003, $2005, $2006, returns the PPU I/O bus's value.[4]

Open bus on the video memory bus behaves differently. Video memory's data bus is multiplexed with the low byte of the address bus on pins 31 through 38. Thus a read from an address with no memory connected will usually return the low byte of the address. This is used only for copy protection if at all.

Electrical basis

A data bus behaves as a dynamic latch. Once a low or high voltage is placed on each line of the bus, the capacitance of the long traces that make up the data bus holds it in place to be read again.

See also

References

  1. Forum post: Low G Man "plays nice with emulators" patch
  2. Forum post: Battletoads Double Dragon Powerpak Freeze
  3. Forum post: PowerPAK, Games that don't register input
  4. Forum post: Riding the open bus