Blargg's test roms

I found Blargg's cpu test roms on the "Emulator Tests" page of the wiki - the test are at: http://blargg.8bitalley.com/parodius/ne ... est-v3.zip
I thought these would be perfect for testing my cpu core. I ran into a strange problem, was wondering if anyone could explain it to me. I started with the "official_only.nes" file, but quit on that because it uses mapper #1 (SxROM), buy my emulator is very new and only handles NROM. So I moved on to the individual tests, and started with "01-implied.nes" which is in fact NROM. This was great, I found several bugs, but eventually I got segfaults in my emulator when the ROM accessed memory address $6000. This is the Save RAM area. Based on the iNES specification in the wiki, bit 4 of flags_10 in the iNES header determines if there is any RAM located at address $6000. This ROM has the value of 0 in flags_10 - so no RAM. I therefore didn't allocate any, and when the rom went to read it I got a segfault.
My question is: Should this ROM have bit 4 in flags_10 set? Am I misinterpreting? I looked at older iNES specifications (before flags_10 existed) and it sort of implied that bit 1 of flags_6 was used to indicate the existence of SRAM - the ROM in question has this set to 0 as well though.

I already know that:
- my emulator should support SxROM
- my emulator should not crash if a ROM claims to not have SRAM, yet writes to it anyway

Mapper 0 includes NROM and Family BASIC. The only functional difference between these is that in NROM, $6000-$7FFF is open bus, but it's RAM in Family BASIC, decoded by a 4-input NAND gate (half of a 74LS20 or 74HC20). Emulators following the original iNES spec generalize the circuit found in Family BASIC to other popular discrete mappers.

The battery bit in flags 6 just indicates whether or not the game contains some persistent memory. It'd be true for Family BASIC, but it'd be false for a cart with no RAM or (apparently in this case) a cart with RAM that isn't battery-backed.

Flags 8, 9, and 10 might not be accurate in old iNES ROM images. NES 2.0 headers are more likely to be correct about RAM size.

Any NES program can try to read and write $6000-$7FFF. If your emulator crashes, it's got a bug. My test ROMs write to $6000-$7FFF a copy of everything printed, as well as test result, to help with emulators that don't even support the PPU. It's fine if that region is open-bus. And yes, the official_only.nes compilation does require a mapper that supports bank selection, as it runs each sub-test ROM separately.

The bit in the header simply indicates whether or not RAM should be battery-backed. Some games (e.g., Metroid) have RAM that is not battery-backed, but there is no flag for this in the header.

You can get away with just always emulating RAM in that region. I'm unaware of any games that will break if it's there when it shouldn't be.

There are a couple of games that will not work with RAM present at $6000-$7FFF.

Oops -- forgot about Low G Man (which I just have a CRC check for). Any others?