Detailed NES Timing Diagram? Or Details on M2, PRG_CE Timing

[qbradq]

Does anyone know if there is a detailed NES timing diagram anywhere? I can't seem to find this.

The specific timing question I have is when does M2 and PRG_CE transition? Which comes first? And is there some sort of race condition? I've seen mention of corrupting WRAM due to writes to $E000-$FFFF. Is that only for U*ROM carts?

[Memblers]

PRG_CE is M2 gated with A15 by a separate 74xx part (not sure of the exact schematic). So M2 will always be ahead of PRG_CE.

The 2A03 is a direct clone of the MOS 6502, so the timing diagram in the original 6500/6502 datasheet is useful.

U*ROM carts don't support WRAM, so I'm not sure about that part of the question. I've made a cart before that decoded WRAM with a 74hc139 and (part of) a 74hc00 and it worked fine. But if writing to $E000+ would be problematic somehow, the simple solution is to not write there. Assuming that it's ROM there.

[Drag]

U*ROM carts don't support WRAM, so I'm not sure about that part of the question. I've made a cart before that decoded WRAM with a 74hc139 and (part of) a 74hc00 and it worked fine. But if writing to $E000+ would be problematic somehow, the simple solution is to not write there. Assuming that it's ROM there.

Well, here's the thing: the cart only has access to $4018-$FFFF. Everything else is internal, as far as I know. Since A15 has a delay attached to it, then writes to 8000-BFFF could be misinterpreted as writes to 0000-3FFF, which is harmless, since writes to 0000-3FFF can never reach the cart through any normal means, which should mean you don't have anything on the cart mapped at that address.

The trouble comes from writes to 4018-7FFF / C018-FFFF, which could be misinterpreted as each other.

So the absolute easiest way to cope with the A15 race condition is to never have something writable mapped at BOTH the 4xxx-7xxx and the cxxx-fxxx range. (readable is ok)

[kevtris]

U*ROM carts don't support WRAM, so I'm not sure about that part of the question. I've made a cart before that decoded WRAM with a 74hc139 and (part of) a 74hc00 and it worked fine. But if writing to $E000+ would be problematic somehow, the simple solution is to not write there. Assuming that it's ROM there.

Well, here's the thing: the cart only has access to $4018-$FFFF. Everything else is internal, as far as I know. Since A15 has a delay attached to it, then writes to 8000-BFFF could be misinterpreted as writes to 0000-3FFF, which is harmless, since writes to 0000-3FFF can never reach the cart through any normal means, which should mean you don't have anything on the cart mapped at that address.

The trouble comes from writes to 4018-7FFF / C018-FFFF, which could be misinterpreted as each other.

So the absolute easiest way to cope with the A15 race condition is to never have something writable mapped at BOTH the 4xxx-7xxx and the cxxx-fxxx range. (readable is ok)

If that were the case, half the mappers wouldn't work. MMC3 for example can map WRAM at 6000-7fff and registers all through 8000-ffff

The standard way is to check if /CE is high meaning the CPU is accessing 0000-7fff, then M2 has to be high, and finally your other address lines of interest. for decoding WRAM, you basically need to detect this condition:

M2 high
/CE high
A13 high
A14 high

Then R/W connects to /WE on the RAM, /OE is grounded, and /CE connects to the above logic.

Note, when using a 6264, one of those can be connected to +CE on the RAM (pin 26, I suggest M2) leaving only three lines to decode.

Address and R/W are always valid when M2 is high (and a little while after M2 falls).

[qbradq]

Thanks for the explanation Drag! I understand this race condition now that I know A15 is delayed.

EDIT: From here down I am completely off-base.

I don't think this will have an impact on the design I am working on. I am not edge-triggered on PRG /W. I am using combinational logic that checks PRG /W, M2, PRG /CE and the address lines. So the race condition will not impact me. If /W goes low before /CE does I won't issue a write, but then on the falling edge of /CE I will. The opposite case also works fine.

[kevtris]

Thanks for the explanation Drag! I understand this race condition now that I know A15 is delayed.

I don't think this will have an impact on the design I am working on. I am not edge-triggered on PRG /W. I am using combinational logic that checks PRG /W, M2, PRG /CE and the address lines. So the race condition will not impact me. If /W goes low before /CE does I won't issue a write, but then on the falling edge of /CE I will. The opposite case also works fine.

There is no race condition.

[Memblers]

Well, here's the thing: the cart only has access to $4018-$FFFF. Everything else is internal, as far as I know. Since A15 has a delay attached to it, then writes to 8000-BFFF could be misinterpreted as writes to 0000-3FFF, which is harmless, since writes to 0000-3FFF can never reach the cart through any normal means, which should mean you don't have anything on the cart mapped at that address.

I think I see what you mean, but the solution to the problem is using PRG_CE AND M2 as the enable for your WRAM (and anything $7FFF and under). I looked at my old Squeedo schematic, and the important part is that it uses M2 NAND PRG_CE as the enable to (first part) of the '139. It includes A13,A14 to make the WRAM enable, and the second part of the '139 brings in A12 so the control registers are at $5xxx. But $5000-$FFFF is all safely writable with a setup like that ($8000-$FFFF is FlashROM) .

[tepples]

The standard way is to check if /CE is high meaning the CPU is accessing 0000-7fff, then M2 has to be high, and finally your other address lines of interest. for decoding WRAM, you basically need to detect this condition:

M2 high
/CE high
A13 high
A14 high

Family BASIC runs exactly this function on one side of a 74HC20 (two 4-input NANDs), leaving the other half to invert R/W to produce PRG /OE. (See wiki page.)

A 74HC139 can do the same thing, but without the bus conflict prevention. How much do 74HC20 and 74HC139 cost?

[Memblers]

How much do 74HC20 and 74HC139 cost?

About the same and cheap, I'd say around 10 cents.

[qbradq]

OK, so I don't think I fully understand. I thought that PRG /CE's transition was after M2's transition. That means that the following race condition is a possibility on a write to a mapper register at $E000-$FFFF, wouldn't it?

Code: Select all

                |       |
               ,------------
M2            / |       |
         ----'  |       |
                |       |
         ------------,  |
PRG /CE         |     \ |
                |      '----
                |       |
                ,       |
WRAM Enabled---/        ,
      WRAM Disabled----/

MMC3 for example can map WRAM at 6000-7fff and registers all through 8000-ffff

Exactly why I am worried about this. I am working on a CPLD implementation of MMC3 as a exercise on learning HDL

[Memblers]

If you're writing to $E000-$FFFF, you don't use M2 because it's logically built into PRG /CE. You really only need M2 for a chip enables below $8000, and like I mentioned earlier, in that case you would AND M2 with PRG /CE to get your "A15 = low, M2 = high" part of the logic.

[Drag]

If that were the case, half the mappers wouldn't work. MMC3 for example can map WRAM at 6000-7fff and registers all through 8000-ffff

I was only going off of the information I found on the Wiki, on this page:

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 pointed out by loopy.

Address and R/W are always valid when M2 is high (and a little while after M2 falls).

So yeah, the A lines would change before /CE changes, but this entire issue of concern is completely moot if M2 always clocks after the A lines and /CE are stable. If this is the case, then this information needs to be corrected before others (like me) get the wrong idea.

Edit:
Also, if PRG /CE is the result of !(M2 * A15), then wouldn't PRG /CE always change after M2 clocks, since the signal has to go through a logic gate before reaching the cart? In that case, you'll always have a split instant where, if you're accessing address E000 for example, 6000 will be on the A lines while M2 is high. Even though PRG /CE will change an instant later, which will give me an address of E000, the damage will be already (potentially) done if I was performing a write, because (write something at 6000) will be fed to the cart for one instant before the correct (write something at E000) is sent.

If this is the case, wouldn't my previous solution be a viable workaround, for discrete mappers?

[qbradq]

If you're writing to $E000-$FFFF, you don't use M2 because it's logically built into PRG /CE.

Good point

in that case you would AND M2 with PRG /CE to get your "A15 = low, M2 = high" part of the logic.

That's what I'm worried about. For a write to $E000 there will be an instant where the M2 line is high and the PRG /CE line is also high. If this is not taken into consideration then writes to registers mapped in this range will cause unintended writes to PRG-RAM.

I guess that can be compensated for with a delay, but I don't know how long this lag time is. Has anyone ever looked at this with a logic analyser? I have neither the skill or equipment

If this is the case, wouldn't my previous solution be a viable workaround, for discrete mappers?

Yes, not having any reason to write to $E000-$FFFF is the easiest solution Unfortunately I can't do that because I am trying to recreate the MMC3, which does have registers there.

Hey Memblers, what ever happened to your MMC3 CPLD board? You mentioned it on some old threads I've recently read.

[qbradq]

Alright, I got the low-down on this now, I think. Someone with some experience correct me if I'm wrong

According to the NES schematic diagram The PRG /CE signal is generated by sending the /M2 and PRG A15 lines through one half of a 74LS139 two-to-four line decoder.

The maximum propagation delay for the 74LS139 is 33 ns. The minimum /WE pulse time for a 6264 120ns SRAM is 70ns. So this should be a non-issue using that RAM chip.

I also took a look at the cart database to see what faster RAM chips were common. I see the MN4464-08LL 8Kx8 SRAM from Motarola which has a TWP of 50ns.

*scuttles off to update the Wiki*

[Memblers]

Hey Memblers, what ever happened to your MMC3 CPLD board? You mentioned it on some old threads I've recently read.

It's not MMC3, but I finished the Verilog for it (rewrote it probably 5 times, but it was my first HDL) and making the board is the next step, which I'll be starting on this month. I prefer putting the mapper registers at $5xxx because I like having writable FlashROM for the PRG memory. With a CopyNES you could program a cart even if it's blank. I'm using a xc9536xl which has 34 I/Os, a quick check shows that the MMC3 needs 37 I/Os. I tacked on 5 more inputs to mine by adding a cheap 74hc part, so maybe a trick like that could help MMC3 squeeze into a smaller part.

I'm pretty sure my first Squeedo board didn't have any problems writing to $E000+, I didn't check for that specifically but the main program was running in the WRAM while entirely rewriting the chip, and it surely would have crashed or left noticeable stuff in SRAM when I tested the SRAM uploading.