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.
Monday, May 11, 2009
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...
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...
Subscribe to:
Posts (Atom)