User:Lidnariq/Mapper thoughts

EtherNES 1

A cartridge designed to provide ethernet in as simple a manner as practical, for use with Contiki.

Option 1

The design is intentionally similar to the 64NIC+ ethernet cartridge for the Commodore 64, even though the CS8900A is comparatively expensive.

Parts

• 1 × SST39SF010A, 128 KiB FLASH EEPROM, for booting
• 2 × AS6C1008, 128 KiB static RAM, one each for PRG RAM and CHR RAM
• 2 × 74'161, both set up to clear on reset.
  • One selects a 32 KiB slice of PRG
  • The other selects an 8 KiB slice of CHR RAM.
• 1 × 74'139
• 1 × 74'20
  • One NAND4 produces /INTSEL=NAND4(M2,/ROMSEL,A14,A13) and one decoder produces /RD6xxx, /WR6xxx, /RD7xxx, and /WR7xxx.
  • Other NAND4 produces /RD.
  • 2nd decoder selects RAM or ROM as appropriate.
• CS8900A or LAN91C96 already have drivers in the Contiki source tree
  • Other cheaper options: RTL8029, CP2200, ENC424J600, AX88796
• Ethernet transformer

Memory map

• $7xxx - CS8900A
  • http://www.cirrus.com/en/products/cs8900a.html
  • Unlike the C64 NIC, use the memory-mappable portion of the CS8900A.
  • CS8900A does not have a separate enable, just /{MEM,IO}{R,W}; the address bus must be stable before these signals fall.
  • Why does the 64NIC+ not connect /IRQ ?
  • Obviously no DMA controller.
• READS from $6xxx - latching CPU A0..A3: PRG bank '161 (0,1,2,3 = ROM; C,D,E,F=RAM). Q3 determines which IC. Cleared on hardware reset.
• WRITES to $6xxx - latching CPU D0..D3: CHR bank '161
• $8000-$FFFF: PRG ROM or RAM, according to value at $7xxx.

Option 2

The ENCx24J600 is a still-actively manufactured parallel I/O network IC made by Microchip. Fortunately, it can support the 6502's R/W interface, but unfortunately it uses +ve sense signalling for all other signals.

1. Possibility: This IC supports a 15-bit address memory-mapped form; allowing mapping the NIC into $8000-$FFFF.
   • Problem: the 6502 vectors now point at garbage. Ask Microchip what reading from those addresses do? If not acceptable, invert A14?
   • Another problem: The driver has to either fit in the NIC's RAM, or do everything via trampolines
   • Nifty feature: stream DPCM over ethernet. (Packets will have to be realigned, but this IC has an internal DMA feature that could do copies accordingly)
2. Possibility: Re-use the PRG or CHR bank to select a 4 KiB slice to map.
   • Weird feature: stream OAM over ethernet (why?)
3. Possibility: Only allow I/O to the the 512 bytes starting at $7Exx; all access to the internal memory is via the indirect registers.
   • If the NIC's A9..A11 are tied high, a latch and an OR gate lets us hijack OAM DMA (which writes to $2004) to write data to the NIC (pointer writes via 0x7E84) ... but is it useful to be able to transfer data to the NIC rapidly?
4. Possibility: Use multiplexed bus, latching the 8 LSBs while directly driving the 7 MSBs. Need a 4th write trigger (ethernet ALE, ethernet CE, CHR bank, PRG bank) or to combine PRG/CHR banking register.
5. Simplest possible option #1: self-writable NROM with a 74'21 (quad AND) to map the NIC from $6000-$7FFF. Slightly clever rewiring (CPU A12→NIC A14,CPU A11→NIC A13,12,11) allows 6 KiB of the 24 KiB of RAM inside the NIC (0x0000-0x07FF, 0x3800-0x47FF) to be directly available to the NES, while ensuring that the NIC registers (0x7E00-0x7FFF) are always available.
6. Simplest possible option #2: use NIC RAM in lieu of CHR-RAM. Addressing NIC becomes a total PITA because of the PPU's auto-increment. But streaming graphic data becomes very easy.

Unfortunately, the shape of the front-loader means that the ethernet jack itself will have to be mounted both rotated 90°, and at the very top of the cartridge (22mm clearance, 16mm wide jacks)

Easier nametables, finer palette zones

Replace standard PPU nametable/attribute table with just one nametable, 32x30 tiles in size, each tile is 16x16 and uses 8x1 palette zones.

• using 32×30 allows us to reuse the scroll registers, rather than having fine X be magically somewhere else
• Each tile is thus 72 bytes (256 pixels × (18 bits/8 pixels)).
• Total memory for tiles in this manner: 18 KiB.

Pixel-perfect IRQs with clockslides

An interface to fire an IRQ at a specific X/Y coordinate that works by

• firing the IRQ approximately 14cy too early
• uses an injected clockslide to fix up any slop in initial IRQ firing time

Since there's already 3 pixels of intrinsic slop, the two axes can be X/2 and Y. Y is ever-so-slightly larger than a byte, so setting (255=scanline before NMI) and not allowing interrupts during the first 6 scanlines of vblank is an ok compromise.

Fake sprite 0 IRQs

1. IRQ when PPU address reads from a specific address, or
2. Snoop on CPU reads, monitoring for reads from $2002, and fire an IRQ

Very fine-grained CHR banking

64 banks of 64 bytes (4 tiles) each, allowing changing the bank a sprite comes from mid-render. Not clear if useful for anything but masking sprites.

Could be combined with some amount of address-line math to prevent sprite pop-on on PAL systems, and with a barrel shifter to prevent sprite pop-on on the left side of the screen without using the PPU's native masking.