leaving on a jet plane

I've been a bit busy lately as recently I graduated from college in Michigan and returned to my hometown in New Jersey. I'm in the process of packing up all my stuff for a cross-country move to start work in California. Things are a bit hectic, so I haven't done much work on the project, but i will very soon! Most recently, I've been working on some boring freelance webdev work to help recoup some of my expenses on this project which I'm hoping to wrap up within this week.

When I get back to this project I plan to tackle a bunch of stuff (in this order, i think):
- Bring up the usb port on the board: I want to be able to load code to the fpga over usb. This would save me a lot of hassle right now, since my laptop doesn't have a parallel port, and all I have now is a parallel port jtag cable. I've been using a second computer as a "Cable Server" which more or less works, but it's totally not ideal. I realize now that there are actually low-cost usb cables for loading code to this fpga (digilent makes one for ~$40USD) but my board was designed to be programmable from usb using an onboard 18f PIC, and I'll assuredly be using the PIC for some other stuff, so I might as well start with this.

- Start working on the menu to select games from the sd card: The venerable lint_ has spent a good deal of effort writing SNES code to help with reading files from the SD card. He's done a great job so far, and it's about time i start working on the hardware side.

- Special chip support: I'll probably start with the DSP chip (used in super mario kart) just because it's KILLING me that whenever I show off this cart to my friends, we can't play SMK! My plan is to synthesize a small CPU on the FPGA and write some code to emulate it (the original dsp chip was just a microcontroller running some code). I originally planned to use the xilinx picoblaze, but it would be nice if I could use something with a C compiler. My only concern is code size (if the code is too large, it won't fit in the fpga block ram). I also don't know how much block ram i'll end up needing for runtime memory.

debugging sessions, part II

Well, hmm, perhaps this is a bit anticlimactic. I was looking over my work, and for some reason i mapped address bit 23 as the /cart_enable signal. Basically, this means if you access the ROM in banks $80 - $FF, then it would disable my cart. If you're a snes guru, you probably realize what this means. It means that no fastrom games will work properly.

I fixed this, and now fastrom games work! well, sometimes....

I got a big kick out of this. Pictured above is my cart trying to boot Kirby's Dream Course. It has some pirate deterrents built-in that test the sram save functionality. A lot of backup units from '90s would just use a 32kbyte sram chip (since that was the largest needed to support certain games), but Kirby's Dream Course only had 8kbyte (= 8192 bytes) of sram in the real cart. So, if it tries to write the the 8193rd byte.. then it should wrap and write at byte 0. In a copier with 256kbyte of save sram, this wouldn't happen, and this game would detect it and display this message.

In my case, I hadn't implemented saving at all yet. I worked on this for a good chuck of the weekend, and it seems to be working now. I can even boot Earthbound:


There are still some issues. One of the big ones is corrupt graphics in the Captain America game. I talked to Nach, one of the zsnes authors about it, and apparently this is a bug that showed up in many emulators. It had something to do with memory mapping. I'm wondering if this is just an odd cartridge and triggers data outputs on a weird signal. It would be awesome if anyone had a Captain America cart and could check for me. I might buy one on ebay in a few months if I can't figure it out.

I had been reading the bsnes source for a guide on how to do a lot of the mapping. The author, byuu, is a very meticulous, detail-oriented coder, and it really shows in his work. Most of the stuff in his code is accurate enough that I can just go straight from his memory maps to my hardware and it works. I did find some discrepancies, though I'm not sure if they are issues with the code, or just issues in my understanding of the code. I want to email him about it. I wonder if he'll respond.

debugging sessions, part I

So the first thing I tried for debugging the problem was to write some test code for the fpga that would dump the sram over a serial port after loading the rom from the sd card:


You can see from this screenshot that the actual space invaders rom matches the dump i got back from my cartridge over serial. This means it's probably not a ram problem. That's good, because it means that i didn't wreck the ram while soldering or anything like that.

I suppose this means it's most likely a problem with the side of the circuit that goes to the snes cart. Hmm, needs more debugging...

sparkfun prototype demo

It works (kind of)!

My prototype board that plugs into the sparkfun fpga breakout seems to be working to some degree. I can play super mario world, but other games won't boot, even ones that otherwise work in my de2 prototype (same sd card and everything).

I have some debugging to do...

Decoupling

So I've bascially been in my lab non-stop since the last post, trying to figure out why I can't read from the SD card. I tried everything.. adding pull-ups, changing drive currents, putting a decoupling cap across the sd card supply... nothing works, all the signals going into it seem ok. I'm clueless.

The solution? use a BIGGER decoupling cap (1uF vs .1uF). This fixed everything. I seriously want to rip my hair out... in a good way.. i think...

New Disaster

So, I got my new plug-in boards, and I soldered on the SD card slot, plugged it into my sparkfun fpga board, and... didn't work GRRRR. I'm still not sure what's wrong, the same exact code works fine on my de2 board if i wire it up to my plug-in board.

I have a header that breaks out all the sd card pins and on the logic analyzer everything looks fine, except the SD card never puts any responses out on the DAT0 line. My first guess would be something going on with the power supply, which was suspiciously at 3.2v (should be 3.3), but I kind of wrote it off as well within the tolerances. eventually I thought it might be a good idea to maybe bypass the sparkfun power supplies and power the io directly from my bench supply.

This turned out to be a bad idea, as now the FPGA is thoroughly fried. Maybe there was something wrong with it from the get-go? I'm not sure. I put in an order to overnight me a new one to recieve on Friday. I am not feeling very hopeful though... I'm not really sure how to debug the problem further. I'll probably ping some of the lab techs for ideas.

One step at a time...

So I got the sparkfun spartan3e breakout board and parport programmer today. My custom board should arrive tomorrow (it plugs into the breakout board). In the meantime I've been sanding down the female headers so they all fit on the board. The idea is then I can plug stuff into the breakout board and easily detach them so I can reuse the breakout board for other projects later.

I soldered in one side of the header and did a little scrolling led test which you can see below:

I guess you can't really tell from the picture, but each led lights one at a time, scrolling across. I thought it was kind of interesting that sparkfun fails to mention in the product page that this board actually comes with an oscillator (I think 50MHz?). Very handy! It's in their schematic but it's not clearly labeled as an oscillator, just an inconspicuous random box with an enable signal and an "output" signal. Also they supply some fpga code to help flash the on-board PROM but it's targetted at a different fpga (not the one they put on the board). After I finish sanding/soldering the headers, I might post on the forum and ask about that.

In reality you shouldn't even need that stuff, since the Xilinx iMPACT software should be able to flash the PROM over jtag. I'll have to remember to test that soon.

EDIT: I was able to erase/blankcheck the prom over jtag, so I think it works. For instructions, see: xapp974.pdf

I have the world's worst sleep schedule.

So, I finished assembling the board, and apparently all the crucial parts are working, EXCEPT for the parts that talk to the SNES (Grr....)

I have the same code running on my de2 test prototype and it works fine, but on my board, it reads a rom from the sd card (reads it back to verify), then waits for the snes to talk to it... but the SNES just shows a black screen :(
Lockout chip appears to be functioning, since the snes comes out of reset (my tv screen stays blue if there's no lockout chip).

As a test, I wrote some code to directly output to the snes pins and it appears that some of the IO on the fpga is just straight up not working. In my test, I saw that the DATA_0 io line was always grounded (actual output from fpga, not a solder bridge). This is consistent with the behavior I observed when the SRAM wasn't working properly, too. Also, randomly, the FPGA will just start chewing up current as if there's a short in the IO supply. I am very suspicious of the buffer chips, perhaps feeding back into the FPGA outputs, but it sometimes happens before I even configure the fpga (which means all the fpga output pins should be in hi-z). VERY SNEAKY. My conclusion is that this fpga is just toasted, and I have been trying to somehow bring up another board.

I was able to successfully solder at least one fpga by hand and it appears to be working with an led test, but the board is a little shady since I had used it in an experiment with a griddle. I am hoping it might work, but I guess I'll have to see how it goes tomorrow. when I populate it with a memory chip and the buffers. To be honest, I am not very hopeful.

Perhaps it wasn't the best idea to combine my first pcb design with my first time soldering fine-pitch surface mount components. I have learned a lot over the course of this project, and I think my next plan of action (assuming this board doesn't end up working) is to redesign the whole board and try again.

In the intermediary time, I think I am going to design another board with sram and an sd card slot to plug-in to the sparkfun xilinx fpga breakout board. This way I can avoid soldering a new fpga, and avoid spending extra for thin pcbs (to fit inside the snes). Also, if I can get that to work, then I should be able to just migrate the design to a new pcb 1:1. Since I'll know if the design originally worked, it will take a lot of the guesswork out of "well, maybe this line needs a pullup resistor..." and save much mangling of my pcbs.

hmm.. back to the lab again in the morning...

Board Bringup

Well, I have made some progress. I have at least one board with an fpga that i can program from my PC.
You can sort of see in the picture that 3 of the 4 leds are illuminated. I wrote a small core for the FPGA to test the two SRAMs that I soldered on. The top one is passing (led #3), but the bottom one is isn't (led #2). led #1 tells me that the test did start and led #4 signals that the test finished. It's just a sanity check (does two writes and checks the first one), I need to do a real integrity check soon.

Not sure what's wrong, yet. I'm hoping It's something simple, like I fried the sram chip, then I can just slice it off and solder up a new one. I guess it's not that big of a deal anyway, I should at least be able to test it with just the 2mbyte of sram. That's more than I had on the de2 at least. Plus I can still solder one more for another 2mbyte.

jeeze it's late. gonna head to bed and head back to my lab in the morning.

From Shenzhen, With Love

Got the boards yesterday. Here's a nice pic of my pcb alongside an original snes cart pcb, competely with educational labels (click to enlarge):

I got 5 boards and I started testing the basic stuff. you can see in the picture that i've populated the board so far with the regulators and the usb port. I am able to power the board over usb and the regulators give off the right voltages (3.3v and 1.2v). So far so good.

I tried to put on the FPGAs though, and that was a nightmare. The thing has so many pins, and they're so close together. my first board try was an absolute disaster. My second try went better, but apparently i shorted the 1.2v supply vcc and ground. From visual inspection of the board it seems like the relevant pins are unconnected, so I'm not sure what's wrong. Maybe I fried the FPGA?

I'm tempted to just try again and potentially torch another board but I don't want to waste the 3 good bords that I have left. I might be able to get access to a hot-air rework station which would be easier to deal with than just a soldering iron, I think. There's also the griddle/toaster oven option. I'm going to e-mail the guy in my building who has the hot-air station and see what he thinks (or see if he even responds to me).

ordered first batch of pcbs

So I ordered my first batch of printed circuitboards today. It's sort of a bummer because SNES pcbs are a little bit thinner than the standard issue pcbs. This means I pretty much couldn't use any of the online specials for cheap pcbs. Also, the FPGA has pretty tiny half mm pitch on the pins, so that is just another extra crazy requirement.

On the upside, since I had to do a special custom order anyway, I made the PCBs have blue soldermask instead of the standard green. That's right, blue PCB, totally awesome.

People are telling me that I won't be able to solder something with such thin pitch. I don't really know if I can either. I guess we'll see when I get the boards in next week.

SRAM vs. SDRAM

So apparently I misread the digikey catalog and the biggest reasonable sram is something like 2mbytes (not big enough!) and it's kind of expensive at 13$ per chip. I guess I can put like 3 of them on the cart to support the largest possible game, but it would be cool if I could use the much cheaper SDRAM ($5 for 8mbyte).

The DE2 board that i' m using has 8mbyte of sdram on it already, which is more than I need, but I'm unsure about the timing. The datasheet shows the whole situation to be pretty dicey. SNES FastROM needs 120ns response time. In the worst case, the SDRAM could be in the middle of a REFRESH (60ns), then it needs an ACTIVE (row select) and the full CAS delay (column select), and finally a PRECHARGE before the next command. The datasheet shows tRC (active->active cycle time) as 60ns. I'm not sure abuot how accurate that number is, because you don't neccessarily need a precharge if you do a refresh, but no matter what, it's cutting it extremely close (60ns+60ns = 120ns). I would want some slack time for the controller logic.

The original copier devices had problems with FastROM games, which leads me to believe that it's sort of a hard problem. Part of the issue for me is that I haven't actually written an SDRAM controller core, I've been messing around with a few random ones that I've found. If I needed to make some shady optimizations, I'd have to probably end up writing a lot of the stuff from scratch. Another option might be to use 2 SDRAMs, this way if one is refreshing, I can fall back to the other one. The logic for this would be tricky, and I would need to make my own board just to test anything, so I'm not that keen on it. At least not for a first pass...

I would do it, but I'm not sure I have time. I graduate at the end of this semester, and then I won't have access to this sweet lab. Just getting the basic SDRAM test code working has been a huge ordeal for me. The timing is really tight, and my original code took some (bad) liberties in clocking logic. In the interest of getting my own board semi-working, I think I will just use expensive SRAM for now. Now to finish the design...

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...

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....

FPGA or CPLD?

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:

CPLD:
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.