PRG RAM circuit: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
(→‎Using 7420: kevtris agrees)
(Added M2 and PRG /CE Race Condition heading to help elaborate on the $E000-$FFFF write issues)
Line 1: Line 1:
The [[iNES]] format implies 8 KiB of PRG RAM at $6000-$7FFF, which may or may not be battery backed, even for [[:Category:Discrete logic mappers|discrete boards]] such as [[NROM]] and [[UxROM]] that never actually had SRAM there.
The [[iNES]] format implies 8 KiB of PRG RAM at $6000-$7FFF, which may or may not be battery backed, even for [[:Category:Discrete logic mappers|discrete boards]] such as [[NROM]] and [[UxROM]] that never actually had SRAM there.
This inspired some people on the nesdev.org BBS to come up with '''circuits to add PRG RAM''' to the original boards, so that games relying on it can run on an NES.
This inspired some people on the nesdev.org BBS to come up with '''circuits to add PRG RAM''' to the original boards, so that games relying on it can run on an NES.
Some gotchas to watch out for include the fact that PRG /CE and M2, used together to decode $6000-$7FFF, don't change at the same time.
Writes to a mapper register at $E000-$FFFF can cause spurious writes to PRG RAM, as [http://nesdev.parodius.com/bbs/viewtopic.php?p=70539#70539 pointed out by loopy].


== kyuusaku's circuit ==
== kyuusaku's circuit ==
Line 80: Line 77:
|}
|}
See [http://nesdev.parodius.com/bbs/viewtopic.php?p=75739#75739 further suggestions from kyuusaku].
See [http://nesdev.parodius.com/bbs/viewtopic.php?p=75739#75739 further suggestions from kyuusaku].
== M2 and PRG /CE Race Condition ==
One thing that can complicate adding PRG-RAM to a board is the fact that PRG /CE and M2, used together to decode $6000-$7FFF, do not change at the same time. PRG /CE is the logical NAND of M2 and PRG-A15. This is accomplished by sending M2 and PRG-A15 into a [[74139|74LS139]] two-to-four line decoder on the NES main board. This introduces a small delay (MAX 33ns) between the time M2 rises and the time PRG /CE rises.
If this delay is too long it can cause unintentional writes to PRG RAM when writing to mapper registers $E000-$FFFF.
This is not a problem for the original cartridge hardware because the SRAM chips used require a /WE (SRAM Write Enable) pulse of at least 50ns to 70ns depending on the chip. This means that the spurious /WE signal generated by this delay (MAX 33ns) will not be sufficient to trigger a write on the SRAM chip. The circuits above give even more head-room as they tie SRAM /WE to ground and decode to SRAM /CE. The SRAM /CE to end of write timing is typically longer than the minimum /WE pulse width.
Care must be taken to use SRAMs that conform to these timing specifications, or the PRG /CE delay must be accounted for in the decoding logic (possibly by delaying the M2 line).
=== References ===
Loopy pointed out the PRG /CE delay [http://nesdev.parodius.com/bbs/viewtopic.php?p=70539#70539 here].
Further investigation performed in [http://nesdev.parodius.com/bbs/viewtopic.php?t=7618 this thread].
[https://www.jameco.com/Jameco/Products/ProdDS/42930.pdf 6264P-12 8Kx8 SRAM Data Sheet]

Revision as of 13:25, 5 April 2011

The iNES format implies 8 KiB of PRG RAM at $6000-$7FFF, which may or may not be battery backed, even for discrete boards such as NROM and UxROM that never actually had SRAM there. This inspired some people on the nesdev.org BBS to come up with circuits to add PRG RAM to the original boards, so that games relying on it can run on an NES.

kyuusaku's circuit

On the forum, kyuusaku and Bregalad discussed SRAM decoder circuits built from 7400 series parts to approximate this behavior in an NES cartridge board. The first tries took two chips[1] or had possible timing problems.[2][3] They settled on the following circuits:

Using 7410

kyuusaku suggested a circuit based on a 74HC10 (triple three-input NAND) stick a pulldown on CE2 to take advantage of Phi2 going high-impedance during reset in order to "offer some write protection".[4]

           ,-------------- ROM /CE
          |   ____
/ROMSEL --+--|    `-.
             |       \
A14 ---------|        )o-- RAM /CE
             |       /
A13 ---------|____,-'

              ____
+5V ------+--|    `-.
          |  |       \
          `--|        )o-- ROM /OE
             |       /
R/W ------+--|____,-'
          |
          `--------------- RAM /WE

Phi2 ---------+----------- RAM CE2
              |
              <
              < "big R"
              <
              |
GND ----------+----------- RAM /OE

Using 7420

He also suggested a circuit based on a 74HC20 (double 4-input NAND), which appears to be the same one in Family BASIC:

Or you could just use a NAND4 to decode any active low memory, also using the /WE priority method. If this is done with a two gate 7420, the second gate could be used to invert r/w to prevent bus conflicts as in the circuit above. This is probably the *final* best way unless you happen to need the extra AND3 from the 7410 and have a positive CE.

The pinout:

  • A = Phi2
  • B = /ROMSEL
  • C = A14
  • D = A13
  • Y = WRAM /CE
  • WRAM /OE = GND
  • WRAM /WE = Vcc or R//W, depending on the Family BASIC cart's write-protect switch

Kevin Horton suggested the same circuit.

You could also use the other gate to invert R//W and use that for /OE (for /OE on the ROM too to prevent bus conflicts).

Using 74139

If you don't need bus conflict prevention, you can use a 74HC139 (double 2-to-4 decoder), which may be cheaper than a 74HC20.

  • 1/E = GND
  • 1A0 = M2
  • 1A1 = A14
  • 2/E = 1/Y3
  • 2A0 = A13
  • 2A1 = PRG /CE
  • PRG RAM /CE = 2/Y3

Proof:

1A0 1A1 1/Y3 2A0 2A1 2/Y3
0 x 1 x x 1
1 0 1 x x 1
1 1 0 1 x 1
1 1 0 0 1 1
1 1 0 1 1 0

See further suggestions from kyuusaku.

M2 and PRG /CE Race Condition

One thing that can complicate adding PRG-RAM to a board is the fact that PRG /CE and M2, used together to decode $6000-$7FFF, do not change at the same time. PRG /CE is the logical NAND of M2 and PRG-A15. This is accomplished by sending M2 and PRG-A15 into a 74LS139 two-to-four line decoder on the NES main board. This introduces a small delay (MAX 33ns) between the time M2 rises and the time PRG /CE rises.

If this delay is too long it can cause unintentional writes to PRG RAM when writing to mapper registers $E000-$FFFF.

This is not a problem for the original cartridge hardware because the SRAM chips used require a /WE (SRAM Write Enable) pulse of at least 50ns to 70ns depending on the chip. This means that the spurious /WE signal generated by this delay (MAX 33ns) will not be sufficient to trigger a write on the SRAM chip. The circuits above give even more head-room as they tie SRAM /WE to ground and decode to SRAM /CE. The SRAM /CE to end of write timing is typically longer than the minimum /WE pulse width.

Care must be taken to use SRAMs that conform to these timing specifications, or the PRG /CE delay must be accounted for in the decoding logic (possibly by delaying the M2 line).

References

Loopy pointed out the PRG /CE delay here.

Further investigation performed in this thread.

6264P-12 8Kx8 SRAM Data Sheet