Monday, May 11, 2009

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.

Friday, May 1, 2009

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