Playpower.org

We support affordable, effective, fun learning games. We're starting with an existing $10 TV-computer as a platform for learning games in the developing world.

We need your help!

Join the Playpower project »
Artists, academics, developers, engineers, educators, hackers, musicians—everyone!
Twitter | Facebook | Contact us

Flash Memory Integration

Flash memory is incredibly important for our educational TV computer. This would enable us to keep hundreds of high quality games on one cartridge, and we might even able to remove the flash memory so it is easy to put new content on the machine.

Additionally, Flash is necessary if you want people to be able to save their work. Imagine writing BASIC programs, but not having a place to store it!

What’s a first step, in terms of figuring out how to build this ourselves? Here is a useful wiki p age about the issue.

Flash Memory Cartridge
http://www.retrousb.com/index.php?productID=133

Tools for NES hacking, including FLASH cartridges
http://www.retrousb.com/index.php?categoryID=86
Make a FLASH cart
http://ameba.lpt.fi/~hataarto/nes/

This entry was posted on Monday, September 15th, 2008 at 2:32 PM and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Bruce McFarling

What is the target here?
(1) Storing a large quantity of original NES cartridge ROM files on a single cartridge, or
(2) Making an NES cartridge that is able to provide a lot of inexpensive storage, that is good programming target for new software

(2) is a lot less constrained a design target than (1): (1) has to cope with the many different designs of memory management controllers built into different NES cartridges. (2) can design a simple, "clean" design that works with a small start-up ROM, a larger RAM that acts as banked ROM, and the stored file information that the start-up ROM loads into the cartridge on power up.

SD is the cheapest widely available flash card format, and all SD cards allow "SPI" mode (serial peripheral interface) access, as long as the port can be access between 100kHz and 400kHz. Running at 1.7MHz, a Famicom clone might be able to work with a simple programmable I/O latch and big banging the SPI port. A single 8-bit GPIO latch would also provide sufficient additional lines to control multiple SPI devices.

6502 is more comfortable with memory mapped access, and the cartridge has R/W access in the 8K RAM space. I'll suppose that the whole top page is taken over, for simplicity of addressing.

32K x 8 Static RAM is available, avoiding all the intricacies of working with dynamic RAM and memory refresh issues.

Taking a few bytes at the top of the upper 256 byte page for I/O allows plenty of register space for the small parts that can implement an SPI interface, and also allow register space for memory mapping.

Two latches:
Latch one: The top 16K of ROM space are divided into two 8K windows, each of which are located in the 32K RAM with two bits. The bottom 4K of the RAM address space can be placed in any one of the 8 4K banks with three bits. The top 4K of RAM (including the I/O page) is fixed to the very top of the 32K physical memory.

Two (or three) 8K banks of ROM space can easily be filled using the bottom 4K RAM address space. This is how the cartridge gets by with so little RAM ... serial access at 100kHz or faster is 12.5K/second. Even at 60% overhead, that is 5K per second, so filling up one of the two 8K pseudo-ROMs will only take a couple of seconds. With support facilities provided by the 16K ROM, a master module in one pseudo-ROM bank, shared with high-RAM, one 8K module in progress can be running while a second 8K module is loading in the background and the bottom 8K is available as RAM.