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.
Thursday, February 26, 2009
Saturday, February 7, 2009
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...
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...
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...
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....
- 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
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!)
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.
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.
Subscribe to:
Posts (Atom)