USB

I'm sure many of you have seen the new SNES PowerPak. After it was released, I sort of lost interest in some of the stuff I wanted to work on (SDRAM interface, menu system, etc) since none of it was really "new" anymore. Plus my job has been pretty intellectually fulfilling, so I hadn't spent much time on side projects.

Well, we had a week off for Christmas so I finally got bored enough to sit down and work on some things. I finished bringing up the USB port on my prototype, so I can load the FPGA core over usb. It enumerates as a HID device (no drivers, woooo!), and I use a little custom app to transfer the core file. For this FPGA, the cores end up being roughly 277kb max, and take about 4 seconds or so to fully transfer (64kbyte/sec, max speed for HID).

you can see the usb cable sticking out of the side of the prototype:

I also looked into some soft-cpu options to try and understand if it would be feasible to emulate the DSP chip in software on the cart. My main concerns were:

- Ability to fit on the inexpensive 250k gate spartan 3e (turns out the biggest issue is probably the amount of on-chip BRAM)

- Availability of a reasonable C toolchain (avoiding asm if possible.. the project is hard enough as it is)

Since we only have about 27kbyte of BRAM to work with, some of which the soft-cpu will have to dedicate for processing, I was concerned about how much code gets produced from a small C app with the given toolchain.

I played around with the Zylin ZPU. Which has a gcc toolchain, and if you use the larger implementation of the processor, the binaries are very small, merely 54 bytes (demo code) for looping to wait on a register, and then setting another register.

I think that it should be pretty feasible to emulate the DSP with this method. As for the other special chips... I'm not sure. For things like DMA engines, surely it will need a hardware implementation. I am assuming that there are enough hardware parts that it might make sense to just do everything in hardware.

I wish I knew a good book on doing custom CPUs with VHDL/Verilog. I can probably make it up as I go along, but it would be nice to have some background from a knowledgeable source.

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.