The EEPROMS (Atmel 28C040 for the 4 Megabit and Atmel AT28HC64B for the 64 Kilobit) Use the same read/write process as SRAM, so they should be writable by the Nintendo directly without any problems. Plus, they retain data with no power, so I don't need to worry about batteries. I was thinking that the /WE signal would be held low for the PRG and CHR ROMs when the load was finished and the uC went offline, but it would be possible to tie these in through the mapper chip.... Possibly as a sort of bastard hack for demo writers who want to use the bonus space as RAM? The ROMs have a life of 10k cycles, and the BRAM has a life of 100k cycles, but this stuff is cheap anyway.

Anyway, as for the CPLD info, you might try these addresses:

http://www.atmel.com/atmel/acrobat/doc0784.pdf
(Info for the Atmel ATF1508AS)

http://direct.xilinx.com/bvdocs/publications/9500.pdf
(Info for the Xilinx XC9500 series)

http://www.altera.com/literature/ds/m7000.pdf
(Info for the Altera Max 7000 series)

It should be possible to dodge using Verilog/VHDL; from what I've seen, most NES mappers were very simple ASICs or small PAL/GALs, so schematic-based design should be possible. I don't know of a good how-to site, unfortunately, but the chip vendors usually give the design software out for free.

One last thing, it may even be possible to add a few MB (4 or 8 should be possible) of actual DRAM on the device and have it bankswitched in with a custom mapper, but that is more of a "version 2.0" idea.

-Regards, Matt

"Meddle not in the affairs of dragons, for you are crunchy and good with ketchup."