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.