CPU Address Decoding

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

Post Reply
Great Hierophant
Posts: 778
Joined: Tue Nov 23, 2004 9:35 pm

CPU Address Decoding

Post by Great Hierophant »

As I tried to figure out the nitty-gritty of PPU Addressing in my last post, I thought I would try my hand with CPU Addressing in this post. The external memory map areas are CPU RAM $0000-#1FFF, $4018-$5FFF, WRAM $6000-7FFF, and PRG ROM $8000-$FFFF. Much of these addresses are decoded by the 74HC139. Address lines A0-A14 go to the cartridge, allowing for 32KB of memory at first blush. This would put the PRG ROM at $0000-$7FFF. This would not do, so A15 is fed into one of the inputs of the '139, and M2 is fed into the other. When both are high, then the output pin connected to the /CS of the PRG ROM inside the cartridge is low and the ROM is enabled, at least until M2 falls. I don't understand the need for M2.

Now, to continue our digression. The CPU RAM is connected fully and directly to the CPU's address bus. Its /CS is tied to anohter pin of the '139. When M2 is high and A15 is low, one of the pins becomes low and activates the other decoder. The inputs of this decoder are attached to A13 and A14. When both address lines are low, then an output pin activates the /CS and enables the CPU RAM. This signifies a value in the $0000-$1FFF range. (In this state A11 and A12 would be unattached, which causes the CPU RAM to be repeated.) Interestingly, when A13 is high and A14 is low, another output pin goes to the PPU, which is in the $2000-$3FFF range.

Now, for WRAM inside the cartridge, things become a bit trickier. In order for the WRAM to appear at the right place, A13 and A14 must be high while A15 low. An 8KB chip only has A0-A12 connected, so its /CE must be enabled through inversion. Fortunately, when A15 is low, the PRG ROM is disabled, which avoids bus conflicts. A '139 would do the trick if the PRG CS line is inverted and used as the enable.

That just leaves $4018-$5FFF. Obviously, the NES CPU could have mirrored the APU, Sprite and I/O registers across this space, but it did not. This area seems to be just a big hole which the odd size made it too complex for your average mapper. Apparently Namco didn't see it that way with its 106 mapper, nor did Kevtris in his CopyNES.
tepples
Posts: 22345
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: CPU Address Decoding

Post by tepples »

Great Hierophant wrote:That just leaves $4018-$5FFF. Obviously, the NES CPU could have mirrored the APU, Sprite and I/O registers across this space, but it did not.
It would almost have been better to put the I/O in page $3F00, but Nintendo designs of the day weren't nearly as orthogonal as the GBA.
This area seems to be just a big hole which the odd size made it too complex for your average mapper. Apparently Namco didn't see it that way with its 106 mapper, nor did Kevtris in his CopyNES.
Nor did Nintendo with MMC5 ($5000-$5FFF) or FDS ($41xx IIRC).
User avatar
Bregalad
Posts: 8036
Joined: Fri Nov 12, 2004 2:49 pm
Location: Caen, France

Post by Bregalad »

I don't know what is your goal here as you do more information than questions, but I just can tell M2 is here to tell if the adress bus is stable or not (and when it's not stable, all external memories are disabled).
Cartridge WRAM is very usually decoded in $6000-$7fff, but there is stricly no rule : The cartridge can make whathver use it want with the $4018-$ffff range, the only restriction is that $fffc-$fffd must be ROM at power-up for the programm to boot somewhere. A evil cartridge could even decode $fffc and $fffd, feed the data bus with a vector got from discrete logic when those place are read to simulate ROM and have the cart boot at the actual ROM wich could start at, say $6000.

Now, most cart uses ROM at $8000-$ffff because this is already decoded to the /ROMSEL signal (or PRG /CE, but I don't like this appelation because it confuses with the output of some mappers). If you want to decode for WRAM at $6000-$7ffff, you have to AND all of A13, A14, M2 and /ROMSEL together (feeeding the positive CE of the SRAM), a simple 7408 or 7420 usually does the trick. If the WRAM is battery backed, then the 7408/7420 would go mad when the power fails, enabling the chip and corrupting it's data, so you'd want to add another circuit along with that.
dvdmth
Posts: 354
Joined: Wed Mar 22, 2006 8:00 am

Post by dvdmth »

All meemory accesses require M2 to be high (that's the way the CPU indicates a read/write request). For WRAM at $6000-7FFF, you want to activate the chip when A13, A14, PRG /CE, and M2 are all high. The NES memory map does not define anything from $4018-7FFF, so anything can be mapped there. Though $8000-FFFF was intended for PRG-ROM, mapper hardware can override this mapping setup by doing its own address decoding. You can reassign $8000-FFFF to something other than ROM, or you can add ROM to the $4018-7FFF range if desired.
"Last version was better," says Floyd. "More bugs. Bugs make game fun."
Great Hierophant
Posts: 778
Joined: Tue Nov 23, 2004 9:35 pm

Post by Great Hierophant »

Now, most cart uses ROM at $8000-$ffff because this is already decoded to the /ROMSEL signal (or PRG /CE, but I don't like this appelation because it confuses with the output of some mappers). If you want to decode for WRAM at $6000-$7ffff, you have to AND all of A13, A14, M2 and /ROMSEL together (feeeding the positive CE of the SRAM), a simple 7408 or 7420 usually does the trick. If the WRAM is battery backed, then the 7408/7420 would go mad when the power fails, enabling the chip and corrupting it's data, so you'd want to add another circuit along with that.
The SRAM Nintendo used has negative enable pins. That would explain the what the '20 in the Family Basic cartridge does. With an '08, you would need to feed the outputs of two AND gates into the input of a third and use SRAM with a positive enable. I believe I read that SXROM carts have a 74 chip that is battery powered in addition to the W-RAM to allow for a smoother method of preserving the RAM contents.

M2 runs at the CPU clock speed, 1.79MHz (NTSC), so it would make sense that it would be used to sychronize memory accesses.
User avatar
Bregalad
Posts: 8036
Joined: Fri Nov 12, 2004 2:49 pm
Location: Caen, France

Post by Bregalad »

I believe I read that SXROM carts have a 74 chip that is battery powered in addition to the W-RAM to allow for a smoother method of preserving the RAM contents.
I think you read that from what I wrote to the wiki, and unfortunately I don't have a cart with that myself, but I shown very detailed pictures of it somewhere where you could see the traces well.
In summary, the MMC1 chip only uses the positive chip enable (wich is internally tied to the AND logic of M2, /ROMSEL, A13, A14) and then is internally passed trough a powerfail protection circuit (I think the resent MMC1s have a better one that the olds), that will make the signal goes low (or just floating ?) if VCC is not established. An external pulldown resistor is used on all MMC1 boards with a battery I've seen, so that the signal is effectivly grounded when the MMC1 is NOT powered at all, and the SRAM is.
The particular MMC1 board with more SRAM (SXROM) has only SRAMs with a negative chip-enable input, and a low-power 74HCU04 has been added to invert the signal, the chip is itself battery-pwered, and comes after the pull-down resistor. So the singal is buffered one more time, and is probably more secure.

Doing a discrete logic board with SRAM is easy, as does the family basic cart, a simple 74HC08 or 74HC20 can decode it (depending if you want positive or negative enable). Since family basic used 2 KB SRAM, there were only a negative chip enable (only 8 KB and 128 KB has both as far I know). If you want it battery backed, things becomes complicated, as you'd need a resistor and a second battery-backed chip to buffer the signal, or even better, a integreated SRAM protection circuit like the MM1026. On the other hand, connecting such circuits to the battery decrease the time it will take for the power of the battery to decay.

The MMC3 seems to have full control over both enables of the SRAM, maybe the positive is for securiy only and the negative for decoding ?

EDIT : I just remembered that I had a SNES board SHVC-1J3B-01 (or something like this), that only had ROM, WRAM, 74HC139 and a battery. I don't know if the '139 is battery backed, but I doubt it is, so there should be a discrete battery back-up circuit made with resistors, diodes and transistor that is enough to not loose saves (on the SNES anyways). I don't know if a similar circuit could be done on the NES (instead of using MMC1/3/5 internal backup circuit).
Great Hierophant
Posts: 778
Joined: Tue Nov 23, 2004 9:35 pm

Post by Great Hierophant »

Is this why the MMC1 games require you to press reset as you turn the power off?
User avatar
kyuusaku
Posts: 1665
Joined: Mon Sep 27, 2004 2:13 pm

Post by kyuusaku »

Bregalad wrote: EDIT : I just remembered that I had a SNES board SHVC-1J3B-01 (or something like this), that only had ROM, WRAM, 74HC139 and a battery. I don't know if the '139 is battery backed, but I doubt it is, so there should be a discrete battery back-up circuit made with resistors, diodes and transistor that is enough to not loose saves (on the SNES anyways). I don't know if a similar circuit could be done on the NES (instead of using MMC1/3/5 internal backup circuit).
IIRC this circuit isn't for protection, it's to switch current from the battery to the console when it's turned on.
User avatar
Bregalad
Posts: 8036
Joined: Fri Nov 12, 2004 2:49 pm
Location: Caen, France

Post by Bregalad »

Yes, but the circuit seemed more complex than circuit on MMC1 and MMC3 games made with 2 diodes, 1 resostor and one capacity.
Post Reply