nesdev.org

For whatever reason, I felt the need today to figure out how a Holy Diver cart could be made. (I'll never go anywhere near a soldering iron, so this is all hypothetical).

I don't know much EE, so bear with me:

You would need an 8 bit latch. You could hook up three bits of the latch to the PRG mask rom through a 7432 just like in UxROM. You could hook up 4 bits of the latch directly to the CHR mask rom just like in CNROM. So you're left with 1 latched bit, interpreted as H\V, for mirror control.

This is where I get a bit fuzzy. From what I've jotted down, it seems a simple 2:1 mux will do the job. The two inputs are CHR A10 and CHR A11, the output is CIRAM A10. This corresponds to how you would do fixed mirroring control using H and V solder pads. So the mux's input select would be the last bit on the latch.

I think you can do a 2:1 mux using a 7400 quad NAND, like this:

1A - H
1B - H
2A - 1Y
2B - CHR A10
3A - H
3B - CHR A11
4A - 2Y
4B - 3Y
4Y - CIRAM A10

When H is low, CHR A10 is propagated to CIRAM A10 ("Vertical Mirroring")
When H is high, CHR A11 is propagated to CIRAM A10 ("Horizontal Mirroring")

So that is all of Holy Diver (I think), implemented in a 74377, a 7432, and a 7400.

But looking at the cart on bootgod: http://bootgod.dyndns.org:7777/profile.php?id=4038, there's a 74245 as well. What would that be for?

The 74'245 is serving as a buffer to compensate for a too-slow CHR ROM. One or the OR gates in the 74'32 is used to form (PPU_A13 OR PPU_nRD) which then tells the '245 to copy the ROM's data to the PPU's data bus.

I can't tell what the ROM's /CE line is tied to; it might be grounded.

Got it; thanks! I assume the CHR ROM responds a few ns faster when /CE is always low? Seems like a bit of a hack.

With mask ROMs with two enables, PPU A13 changes at the beginning of the first pixel, and is tied to /CE. PPU /RD is tied to /OE, and most ROMs seem to respond to /OE twice as fast as /CE (related to the corresponding power consumption difference). So even though the PPU needs a Time-of-/OE-true-to-data-out of 186ns or faster, a two-enable 350ns ROM will probably work.

So maybe when they bought to 28-pin one-enable ROM, they either forgot to pay attention, or forgot which number they needed to care about, and so it was too slow. By keeping it enabled all the time, the relevant time for the datasheet is the (Time-of-address-change-to-data-out), which is usually as fast as the (Time-of-/OE-true-to-data-out). Hence the workaround with the '245.

Or, to summarize a lot of words into a few: Yup, it was a hack, and one that saved the manufacturer from having to spin an entirely new set of mask ROMs.