Thursday, January 22, 2009

Prototype Success!

It works!
If only I knew more 1992 pop culture trivia! Maybe then I could actually enjoy playing this game.

You can see a picture of my setup here. It's the cannibalized Pinocchio cart. I desoldered the mask rom ic, and replaced it with a socket. The socket has some wires that connect to a ribbon cable, which connects to the DE2 board. The DE2 board maps the on-board SRAM to the rom socket on the cart. The board loads the ROM data from the SD card into the SRAM when it turns on. Then, when you turn on the SNES, it can play the game that was loaded from the SD card.

There's so much stuff I want to add! I think now that I've proven it can work, I'll start working on making a pcb and building a self contained version. Then i can start adding cool features like support for as many games as you can fit on the sd card, special chip emulation, and who knows what else...

Sunday, January 18, 2009

Building the prototype, Part I (SD Cards)

So I started working on building my prototype. I'm using an Altera DE2 board that I found in the lab. The main components of the board I'm using are:
- CycloneII FPGA
- 512kb SRAM
- SD card slot
- Breakout headers (to connect to the snes cart)

So, the first thing I need to do is load the contents of the SD card (the rom) into SRAM on the DE2 board. I originally wanted to use the 8MB SDRAM (512kb SRAM isn't enough to hold a real game!) but Brehob (my faculty advisor) suggested it would be a bad idea. SDRAM is really complicated to interface with, and I will soon likely have my hands full with lots of other problems. Also, when I design my own board later, I can just use bigger SRAM, which isn't really that expensive anyway. For now, I can just load a small demo rom.

First, I looked for some example SD card code that came with the board. Sadly, the samples I found used the FPGA to instantiate a full processor, and then used software to interface with the SD card. This seemed like overkill, and I didn't plan to need a real CPU for anything else. I opted to write my own Verilog to synthesize hardware for the SD Card.

After about 3 days, I got it working pretty reliably. It outputs the first 16-bits of the first block of the card to the LEDs on the board. I had never been happier to see 0xBEEF spelled out in binary in my life.

Unfortunately, the hardware uses 120 registers right now. On the CycloneII, this is less than 1% utilization. However, the cheapest Altera MAX7000 CPLD only has 64 macrocells, and I think there is only 1 register per cell. So I'm already past the limits of the simpler hardware option. I can probably scale down my design, but I don't think I can get it less than 70-80 registers. Even if I opt for the more expensive MAx7000 parts, the biggest one is still only 160 macrocells. I think 160 registers may not be enough, especially given that I have barely begun writing the hardware I need. I'll probably end up using a full blown FPGA.

The FPGA option is actually cheaper per-part but they are only offered in crazy TQFP packages with tiny pins. I am not looking forward to soldering that...

Next up, writing more hardware to push the SD Card data into SRAM....

Sunday, January 11, 2009


So after talking to Brehob (my advisor) about my initial design, he brought up a bunch of interesting points.

1. I absolutely need to find a way to prototype this before I build my own device. Somehow, I thought I was going to design a PCB, solder it up, and then test after I made it. In retrospect that would be absolutely insane. In our lab, we have a bunch of demo boards from Altera with SD card slots, SDRAM, and expansion headers. I think this will be a good way to get started. I plan to cannabalize my Pinnochio SNES cartridge, desolder the rom, put some wires in place, and interface the demo board to that.

2. The core of my project will be an FPGA/CPLD, but I need to pick a specific model. I totally dismissed the idea of having through-hole parts, but Brehob thinks this might be a viable option with a CPLD. In my mind, CPLD is synonymous with "like an FPGA, but not as powerful", so I am skeptical since I don't have a sense of scale for how many gates my designs will need. Ideally, I would have room to try and emulate some of the special chips found in some game carts. The most complex of which is a core that descends from the 6502, with a bunch of crazy extra stuff. At the very least, it would be nice to emulate some of the simpler chips that weren't full CPUs.

I am still unsure, but I did find these two CPLDs which could be suitable granted that my design would fit on them:

Xilinx XC9572-15PCG84C ($7.35 @ digikey) IC CPLD 72MCRCELL 15NS 84PLCC
- 15ns propogation delay
- 1,600 usable gates
Altera EPM7064SLC84-10 ($15.25 @ digikey) IC MAX 7000 CPLD 64 84-PLCC
- 10ns propogation delay
- 1,250 usable gates
Both have:
- Selectable 3.3v/5v IO
- ISP capability (always handy)
- 68 IO pins
- 84-pin PLCC package. (This isn't technically through-hole, but there are dirt-cheap sockets available that breakout to through-hole pins!)

My Project

This semester I'm starting a project as an independent study under Mark Brehob at University of Michigan. I'm trying to build a Super Nintendo cartridge with an SD card slot. The idea is that you can copy ROM images to an SD card, and then you can play them on your real Super Nintendo.

Around the internet, I've seen similar projects before. The general hobby solution to this problem is to use 5v NOR (parallel) flash chip wired as drop-in replacement for the mask ROM chips on an existing Super Nintendo cartridge. Basically, you write some ROM data to the flash chip, and then solder it up to the cart in place of the old ROM chip. This isn't very sustainable, as parallel NOR flash is being phased out in favor of serial NAND, and for the most part the 5v parts have already been phased out (digikey doens't even sell them anymore). This solution sucks anyway, because carts can't easily support multiple games. Also, there isn't an easy way to reprogram the cart without more custom hardware.

There are some more advanced commercial solutions. During the heyday of the SNES, there was a number of "copier" units. As far as I know, the only one still in production is the Super Flash Card from ToToTek. It is a flash based solution, and needs to be programmed over the parallel port (yuck!) using a seperate programming device. that plugs into the cart. The programming device has a USB port, but don't be fooled. It's only for power. This product supports one of the special chips found in some SNES carts, the DSP-1, using some sort of pass-through method (you plug in a working dsp-1 game with a t-connector). I don't own one.

I see the Super Flash Card as an extension of the hobbyist carts. It takes things one step further, using a Xilinx CPLD (or FPGA?) for memory mapping, so you can load multiple games on one cart. The cart includes battery-backed SRAM and the mapper can deal with the different types of SRAM saving (the size and memory address of sram is different across games). Unfortunately, you can only hold saves from one game on the cart at a time.

I can understand why the product made these design decisions, as it simplifies the product drastically. My design will require a more complex FPGA/CPLD core. It will have to use SDRAM to store the game after loading it from the SD card so that I can meet the bus timing requirements of the SNES. Also, because I am using modern 3v parts, I will most likely need level converters to deal with the 5v input from the SNES.

It should be interesting, I think.