From the wiki:
Code:
Registers **BUS CONFLICTS**:
--------------------------
$8000-FFFF: [.PPP ...E]
P = PRG Reg (16k @ $8000)
E = CHR RAM enable (write 1 here for normal operation)
How does
bit E work? If E=0, writes to CHR RAM are
forbidden!? Why? Any games with CHR ROM? How do they work??
Mapper 93 is
exactly the same as mapper 89, with two caveats:
1- the 128 KiB CHR ROM has been replaced with an 8 KiB RAM
2- the jumper for "1scA/1scB" mirroring is instead hardwired to H or V.
When you replace a 28-pin 128 KiB mask ROM with a 6264-class 8 KiB SRAM, the RAM's +CE pin is where CHR A13 used to be. Writing with that bit clear not only disables writes; it disables reads too. No game will write to the register with that bit clear, because it would be rendering open bus.
How might I rephrase
http://wiki.nesdev.com/w/index.php/INES_Mapper_093 to have made that clearer?
lidnariq wrote:
Writing with that bit clear not only disables writes; it disables reads too. No game will write to the register with that bit clear, because it would be rendering open bus.
What is the open bus value? $00 or $FF, or whatever?
AFAICT, it should be the lower 8 bits of the address, because of how the PPU multiplexes.
It won't be the same in famiclones without that multiplexing; there it should be a repeat of the attribute byte during rendering, or whatever random crap came before, the rest of the time.
By "lower 8 bits of the address", you mean "lower 8 bits of loopy_v" on $2007 reads when loopy_v < $2000, correct?
I ... have no idea? I'm thinking about it from a hardware point of view. The lower octet of PPUADDR, when not rendering, and ((TileNumber<<4)|(FineY&7)|(Bitplane?8:0))&255 during rendering.
This is the same PPU open bus you would find on mapper 185, for whatever that's worth.
"while rendering"... of course.
I had forgot this detail. No, wait, how's possible to disable CHR RAM during rendering? It's fine for writes, but reads!? What kind of data is fetched? Garbage? If so, wouldn't be glitched pixels?
The data that's fetched is the low byte of the address, so long as your cart doesn't have pull-ups on the CHR data lines. So yes, glitched.
Would I be wrong to assume it may be for protection from static noise by keeping it unreachable until actually used? (although that's pointless if you aren't using non-volatile RAM... or am I missing something?)
It's an emergent behavior, not a designed one. The Sunsoft-2 IC is basically a 74'377 and 74'32 in the same package; the Sunsoft-3 and Sunsoft-3R are just two ways of jumpering that same board. q.v.
http://wiki.nesdev.com/w/index.php/Sunsoft_2_pinout
The contents of the wiki are from me. I have verified them by inspecting the PCB.
Disch has publicly stated that he was trying to aggregate things together, not actually do any research.
Fine, fine...
I just mentioned the source of my mapper 93 info.