nesdev.org

l_oliveira wrote:I used an 62256 chip instead of 6264 [...] This resulted on all 32KB of the SRAM being visible for the PPU through the CHR banking mechanism of the MMC3 chip. Non standard I know

Non-standard? Yes. Awesomely flexible combination of the best of both worlds (CHR RAM and MMC3 tile bank animation)? F███ YEAH. But of course you'll need an emulator supporting NES 2.0's expanded CHR RAM to make it work.

tepples wrote:But of course you'll need an emulator supporting NES 2.0's expanded CHR RAM to make it work.

That's why I prefer the real thing ...

For what it's worth I've used these: http://www.radioshack.com/product/index ... =468196883

To add that trace to a board with success. It's not a great option though at $20 and the pen dried out after a few months after opening. So it was a one time deal. Far from preferred but an option none the less.

tepples wrote:But of course you'll need an emulator supporting NES 2.0's expanded CHR RAM to make it work.

The NESDEV1 will support this also but with 256/512KB of CHR RAM. If I'm not mistaken Member's 8T-ROM board also supports at 32KB.

An personal comment about ROMLABS "Mobile SRAM" module after I read through this thread:

I had an loud laugh when I saw that on ROMLABS. I know that there's real products which operate like that (for example the DALLAS Timekeeper series of real-time clock chips has one of them match the 6264 SRAM pinout and simulates perfectly that chip while adding RTC function) but ROMLABS circuit is completely devoid of logic because the simple act of disconnecting it from the game board circuit would cause the data to corrupt as there's no method to disable the chip when the main power is off. The data stored on the RAM chip would be damaged from simply a person touching the pins as the chip would be powered on and have it's pins floating. Not good at all.

Even for a chip with two CS pins.

A lot of things being shown on ROMLABS only work due to sheer luck.