I'll be staging information here before finding a place to move it to on the wiki.
CPU / APU
- When the CPU comes out of reset, it is random whether it is aligned on the first or second half of an APU cycle (and thus random whether it begins on a GET or PUT cycle).
- The state of the CPU's OUT pins is only updated when transitioning from a GET to PUT cycle. Thus, changes to OUT state lasting only 1 cycle (such as when toggled with an INC instruction) may be missed by the joypad device. This can be used to determine CPU/APU alignment, but poses a problem for expansion port devices that use OUT bits to signal when to snoop the data bus.
- Readable APU registers ($4015 and, if modded, the test registers) drive the internal CPU bus, but not the external CPU bus, so they do not affect external open bus state. Therefore, a dummy read from one of these registers on the cycle before a read from external open bus (such as by using page crossing on an indexed read) will not change the external open bus value.
- The CPU clock divider is not affected by reset. Therefore, resetting the CPU does not change CPU/PPU sub-cycle alignment.
APU register reads
The CPU has an internal address bus onto which separate 6502, OAM DMA, and DMC DMA buses are multiplexed. APU registers can only be read when bits [15:5] of the 6502 address bus match the $4000-$401F range. When they match during a read, bits [4:0] of the internal CPU address bus will be checked for a matching register. If those bits are $16 or $17, the relevant joypad is clocked, and if they are $15 or the CPU test pin is asserted, the internal data bus is isolated from the external data bus (preventing the register read from affecting external open bus) and fed from any matching APU register.
Some unexpected edge cases result from this. Whether APU registers can be read depends on whether the 6502 address bus is in the APU register range, so if it is not, then OAM DMA from the $4000-40FF page will be unable to read them and will not clock joypads. However, if it is in that range when DMA occurs (because the CPU is currently executing from or reading from this range), then any DMA from an address with bits [4:0] matching a readable register or with the test pin asserted will trigger a register read, either overriding the value that would normally be read by the DMA or, in the case of non-test joypad reads, potentially causing a bus conflict.
This has relevance to real workloads. If a joypad register is read at the same time as a DMC DMA from an address matching an APU register, the DMA will perform a register read, possibly with a bus conflict. Though not yet tested, this should also be able to cause an additional joypad clock, at least for the other joypad (as it is unknown whether additional same-joypad reads are ignored if on consecutive cycles). Thus, an audible glitch may occur if using the repeated-read method of avoiding joypad bit deletion.
- 4-cycle DMA glitches do not occur.
- When DMA collides with a joypad read, one extra read occurs on each halt. Behavior is not yet fully understood.
- Writes to OAM during rendering are ignored.
- Disabling rendering outside of vblank can cause OAM to be corrupted when rendering next begins. If the disable write occurs approximately in the ranges of dots 0-125 or 254-318, then 2 sprite tiles (1 row) will be corrupted with the value of row 0 when rendering is next enabled. If the disable write occurs in the range 126-253 and rendering is enabled again outside of vblank, then corruption can occur on some CPU/PPU alignments, though this corruption is poorly understood. Dots 319-340 appear safe under all circumstances. This behavior also applies to the rendering-disable caused by resetting the PPU, so the first rendered frame after a PPU reset is likely to have OAM corruption. Note that these values may not be exact to the dot.
- Signal reflection from a cartridge on the CPU data lines can cause OAM to corrupt. Cartridges with long or thin traces should include 30-100 ohm termination resistors in-series on these lines to suppress signal reflection. This issue has been observed on the FDS, PowerPak, and original Everdrive N8. https://forums.nesdev.org/viewtopic.php?p=232140#p232140
- On revisions that support reading from palette RAM, doing so via the PPUDATA register at the same time as forced greyscale, as seen in the NTSC border at dot 326, disables forced greyscale for that dot, presumably to prevent the greyscale from clearing the low 4 bits of the value. Greyscale is actually forced everywhere outside of draw range, but can only be seen at the start of the border.
- Reads from palette RAM do not set bits 7-6, so these will return PPU open bus.
- The background palette hack ignores bit 14 of v.
- When rendering ends at the end of scanline 239, if the value left in v from rendering points into palette RAM, the NTSC border on scanlines 240-241 will automatically display the color pointed to by v (the "background palette hack"). This can be seen in the first corridor of Metal Storm.
- The auto-increment behavior when writing to $2007 is delayed 1 dot after the write becomes effective. This means writing to palette RAM will show the newly-written color for 1 dot before advancing to the next color.
- Disabling rendering mid-screen appears to be capable of corrupting palette RAM, but the specifics are not yet entirely known. The corrupted entry appears to depend on the value of v. https://forums.nesdev.org/viewtopic.php?f=2&t=23209
- Writing to v on the first dot of a fetch can result in the low 8 bits being latched from the old v and the high 6 bits coming from the new v, resulting in a fetch from the wrong location. This can happen naturally at dot 258, where the low bits latch on dot 257 before the horizontal component of v is updated and the high bits on 258 after the update. Note that this applies to all fetches, but should only result in mixed addresses on nametable and attribute table fetches.
- The PPU clock divider is affected by reset. Therefore, resetting the PPU changes the CPU/PPU sub-cycle alignment.
- Writes to $2001 disrupt rendering similar to toggling it off and on.
- PPU bus write timing differs from later revisions in a way that causes glitches on the Everdrive Pro. (Normal cartridges seem unaffected.)
- The scanline counter clocks when A12 rises after at least 3 M2 clocks with PPU A12 low.
- With background using the $1000 table, the scanline counter behavior depends on the aborted fetch performed by the PPU on the idle dot. The skipped dot on the prerender scanline can cause an extra clock because it overrides this dot 0 behavior, creating a large enough window with PPU A12 low for 3 M2 clocks to fit on some CPU/PPU whole-cycle alignments.
- Writing to $C001, clocking the counter, and writing to $C001 again will cause the counter to be OR'ed with value $80 on the next clock and neither decremented nor reloaded.
$5000-57FF: VRAM window bank $6000-6FFF: TV-NET registers $7000-7FFF: Game card RAM bank $8000-BFFF: First 4 game card or firmware ROM banks $C000-DFFF: Game card or firmware ROM banks $E000-EFFF: Firmware ROM bank $F000-FFFF: Last firmware bank
$8000-DFFF map firmware banks if a game card is not present.
8 registers, mirrored across $6000-6FFF. These are work-in-progress.
UART register select ($6000)
- Register $00 seems to be incoming (serial?) data bytes when read, outgoing data bytes when written.
- Register $02 seems like a 1-hot encoded status when read, $04 means something to do with data transmission, $02 some other special condition.
- Register $05 seems to have something to do with the incoming and outgoing data validity?
- Bits 1, 2, and 3 are to do with incoming data.
- Bits 5 and 6 are to do with outgoing data.
- Possibly required after selecting a register but before reading from that register? Could be purely timing effects, or could be doing something else. Not required for writing to modem registers.
UART data ($6001)
Likely read/write data for register selected by $6000.
VRAM window bank / Game card status ($6002)
Write: 2 KB VRAM window bank. Unknown if bit 0 ignored.
Read: $00 if a game card is present and non-$00 otherwise.
Game card ROM bank ($6003)
7 bit 0 ---- ---- xxDD DDDx || ||| ++-+++-- Game card ROM bank at $C000-DFFF.
Unknown if bit 0 ignored.
Game card RAM bank ($6004)
7 bit 0 ---- ---- xxxx xDDD ||| +++- Game card RAM bank at $7000-7FFF.
Firmware ROM bank ($6005)
7 bit 0 ---- ---- xxxx xDDD ||| +++- Firmware ROM bank at $E000-EFFF.
VRAM window bank ($6006)
Appears to control what is mapped into the $5000-57FF window. Observed writes are 4 before writing to what appears to be 1 KB of special graphics memory (MMC5-style ExRAM?) at $5000 and 3 after, and 5 to map in CHR-RAM, which is 32 KB and can be banked using $6002 in 1 KB amounts (unknown if bit 0 ignored).
Game card connector
Card | | TV-NET -----+--+-------- 1 |--| GND 2 | | n/c 3 |--| +5Vcc 4 |<-| /CS 5 |<-| RAM/ROM 6 |<-| R/W 7 |<-| ROM /OE 8 |<>| CPU D0 9 |<>| CPU D1 10 |<>| CPU D2 11 |<>| CPU D3 12 |<>| CPU D4 13 |<>| CPU D5 14 |<>| CPU D6 15 |<>| CPU D7 16 |<-| CPU A0 17 |<-| CPU A1 18 |<-| CPU A2 19 |<-| CPU A3 20 |<-| CPU A4 21 |<-| CPU A5 22 |<-| CPU A6 23 |<-| CPU A7 24 |<-| CPU A8 25 |<-| CPU A9 26 |<-| CPU A10 27 |<-| CPU A11 28 |<-| A12 29 |<-| A13 30 |<-| A14 31 |<-| A15 32 |<-| A16 33 |<-| A17 34 |--| n/c in JRA-PAT, +5Vcc in MC-1200 host 35 |<-| /RAMSEL 36 |--| +5Vcc 37 |->| Card /present 38 |--| GND
RAM/ROM selects whether /CS is sent to RAM or ROM. If it is sent to ROM, /RAMSEL is send to RAM.
Card /present affects /CE for the TV-NET firmware ROM and tells the mapper it's present via U6.98.
Game card header
Game cards are expected to have a pointer at $8000-8001 to a validation signature that must match a string at $F223 in the firmware, null-terminated on the firmware side. The game card start vector is located at $8004-8005.
Covered on the forums here. Japanese is naively translated with a dictionary. Uses 3 shift registers; every button can be pressed simultaneously. Strobes with $4016.0.
$4016.1 0 - P/T switch (1 if T) 1 - 終了 (Shuuryou / End) 2 - F3 3 - (Always 1) 4 - F1 5 - F2 6 - F4 7 - F5 8 - 1 9 - 4 10 - 7 11 - (Always 1) 12 - 2 13 - 3 14 - 5 15 - 6 16 - * 17 - Left 18 - 実行 (Jikkou / Run) 19 - Right 20 - 8 21 - 9 22 - 0 23 - . 24+ - (Always 1)
Included with the TV-NET Rank 2, this controller offers the same functionality as the base TV-NET controller plus 8 additional buttons. Strobes with $4016.0.
$4016.1 0 - P/T switch (1 if T) 1 - • / 実行 (Jikkou / Run) 2 - 後退 (Koutai / Backspace) / F3 3 - (Always 1) 4 - F1 5 - 番組 (Bangumi / Program) / F2 6 - 印字 (Inji / Typing?) / F4 7 - 取消 (Toke / Cancel) / F5 8 - 1 9 - 4 10 - 7 11 - (Always 1) 12 - 2 13 - 3 14 - 5 15 - 6 16 - * 17 - Left 18 - # / 実行 (Jikkou / Run) 19 - Right 20 - 8 21 - 9 22 - 0 23 - , 24 - 入力 (Nyuuryoku / Input) 25 - Up 26 - Down 27 - 文字 (Moji / Character) 28 - 機能 (Kinou / Function) 29 - 切替 (Kika / Exchange) / F6 30 - 再送 (Saisou / Resend) / F7 31 - 停再 (Tomasai? / Stop again?) / F8
This controller is equivalent to a Famicom keyboard with only 16 keys. The mapping to Famicom keyboard keys is described below. Note that this information is based on a FAM-NET I controller, but the controller bundled with the FAM-NET II is believed to be the same device.
LINE - F1 ← - ← • - . EB - F7 0 - 0 1 - 1 2 - 2 3 - 3 4 - 4 5 - 5 6 - 6 7 - 7 8 - 8 9 - 9 * - space # - RETURN
Super Famicom NTT data keypad
Bits 0-15 match a standard SNES controller. Bits 16-31 match bits 8-23 of a Famicom Network Controller.
0 - B 1 - Y 2 - 前ページ (Mae peeji / Previous page) 3 - 次ページ (Ji peeji / Next page) 4 - Up 5 - Down 6 - Left 7 - Right 8 - A 9 - X 10 - L 11 - R 12 - (Always 0) 13 - (Always 1) 14 - (Always 0) 15 - (Always 0) 16 - 0 17 - 1 18 - 2 19 - 3 20 - 4 21 - 5 22 - 6 23 - 7 24 - 8 25 - 9 26 - * 27 - # 28 - . 29 - C 30 - (Always 0) 31 - 通信終了 (Tsuushin shuuryou / End communication)