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