nesdev.org

Posted: **Tue Feb 01, 2011 12:16 am**

Hi everybody,

I'm doing a repro of Chrono Trigger using 27C322. I've read the thread about this and analyzed the scematics, but I prefer my solution of using 74HC257 muxers to convert the EPROM's 16bit data-bus to the SNES' 8 bit data-bus.

Anyway, my questions are related to timing:

* which input-to-output delay does the MAD-1 add? I mean, how long does it take the chip to assert ROM /OE, ROM /HI or ROM /LO when the address appears in the input?

* why does my Seiken Densetsu 3 repro work using -120ns memories, but not Chrono Trigger? Both are FastROM but Chrono Trigger only works with -100ns EPROMs. I'm nor using any external decoder, just using MAD-1 outputs as needed.
I guess that Chrono Trigger uses lots of MVN and MVP instructions, which move data from ROM at 6 cycles per byte (i.e. 120ns per byte) and Seiken Densetsu uses more DMA transfers (i.e. fixed 8 cycles per byte)... Am I wrong? Is there any other reason?

* which one is faster? 74HC257 ot 74LS257? which one is the proper one for muxing 27C322 data bus? Both have aprox. 20ns of propagation delay, so timing from address on SNES bus to data back on the SNES bus is:

100ns (27C322 access time) + 20ns (74HC257 propagation delay) = 120 ns

I only take into consideration propagation delay on 74HC257 because both muxers are enabled using ROM /OE output from MAD-1 (pin 4), and it is asserted before data on 27C322 bus appears.

Thanks!

Posted: **Tue Feb 01, 2011 6:42 am**

magno wrote:I guess that Chrono Trigger uses lots of MVN and MVP instructions, which move data from ROM at 6 cycles per byte (i.e. 120ns per byte)

My Apple IIGS book says MVN and MVP take 7 CPU cycles, which is a lot longer than 6 master clocks. (Each CPU cycle is usually 6 or 8 master clocks.)

[EDIT: remembered wrong, and we have no s, strike, or del tag]

Posted: **Tue Feb 01, 2011 7:04 am**

tepples wrote: My Apple IIGS book says MVN and MVP take 6 CPU cycles, which is a lot longer than 6 master clocks. (Each CPU cycle is usually 6 or 8 master clocks.)

From http://wiki.superfamicom.org:

A CPU internal operation (an IO cycle) takes 6 master cycles. A memory access cycle takes 6, 8, or 12 master cycles, depending on the memory region accessed and bit 0 of CPU register $420d.

I think the advantage of using MVP/MVN is that instruction code is fetched (6 master cycles), executed (6 master cycles) and then, each byte read by the instruction is 6 master cycles (on FastROM) long; there is no need of executing the opcode again when each byte is read from ROM.

Any answer to my other questions? Any idea?

Posted: **Tue Feb 01, 2011 7:15 am**

tepples wrote:
magno wrote:I guess that Chrono Trigger uses lots of MVN and MVP instructions, which move data from ROM at 6 cycles per byte (i.e. 120ns per byte)
My Apple IIGS book says MVN and MVP take 6 CPU cycles, which is a lot longer than 6 master clocks. (Each CPU cycle is usually 6 or 8 master clocks.)

"7 [cpu] cycles per byte moved" according to WDC's 65816 programming manual.

Posted: **Tue Feb 01, 2011 11:38 am**

If the source and/or destination is system work ram, it should take longer than 7 cycles (42 master cycles) per byte, no? 2 more master cycles if the destination is work ram on top of the base 42 master cycles. And another 2 more if the source is work ram on top of that? Assuming out of those 7 cycles, only 1 is for a read and 1 is for a write (no dummy access cycles, so no penalty slower memory access cycles).

Also, I don't see why the block transfer instructions would make any difference. Even if it was 6 cycles master cycles a byte, 120ns is within range of that. 3.579545mhz is 279ns. And given the multiplexed bus and the requirement for the data bus to be valid in half that time, that's 139ns. So 120ns looks fine. Unless I've missed something.

Posted: **Tue Feb 01, 2011 2:46 pm**

tomaitheous wrote:Also, I don't see why the block transfer instructions would make any difference. Even if it was 6 cycles master cycles a byte, 120ns is within range of that. 3.579545mhz is 279ns. And given the multiplexed bus and the requirement for the data bus to be valid in half that time, that's 139ns. So 120ns looks fine. Unless I've missed something.

I can't see the difrerence either, but there should be some difference because the fact is the game didn't work using 27C322 -120ns. And Radical Dreamers didn't work using two M27C801 -120ns, but it did using -100ns...

Nintendo's Developer Manual (Chap 21.1) states that all memories MUST be faster than 120ns in FastROM mode, but I can't figure out why... As you say, CPU clock is 3.58MHz (that's the same frequency referred to in register $420D documentation), so that makes 280ns per memory access, supposing 1 cycle per access... where in the world does "120ns" come from?

Posted: **Tue Feb 01, 2011 5:57 pm**

so that makes 280ns per memory access, supposing 1 cycle per access... where in the world does "120ns" come from?

Because the original 65816 is pin compatible with the 6502 - it takes advantage of the two phase bus access system of the original 6502. In order to get the full 24bit address on a 16 pins, the data bus is used to hold the upper 8bits. This is attached to an external latch. The phase switch from 1 to 2, sets the latch and the memory device is accessed. That means the data bus must be valid at half the time of the cpu clock cycle. So is PH1+PH2 = 280ns, external memory/device needs to have valid data on the data bus in half that time ~140ns. But timing for such things are tight, so you need to have the memory/device a little faster than that. 120ns sounds right. From what I understand, this wasn't changed on the SNES processor package.

But what you found is interesting. Maybe your 120ns memory chip is faulty at that speed or aren't to spec? Usually you can run memory a little faster than what it's rated at (for these slow speeds). So the difference of 100ns to 120ns seems a little suspect. If it was a difference of 100ns to 150ns, then I could see there could be some issues. I bet someone will chime in with a the reason why (some special case bus access timing thing or such

).

Posted: **Tue Feb 01, 2011 6:48 pm**

Internal /ROMSEL propagation + 139/MAD-1 propagation.

Posted: **Tue Feb 01, 2011 11:41 pm**

tomaitheous wrote: Because the original 65816 is pin compatible with the 6502 - it takes advantage of the two phase bus access system of the original 6502. In order to get the full 24bit address on a 16 pins, the data bus is used to hold the upper 8bits. This is attached to an external latch. The phase switch from 1 to 2, sets the latch and the memory device is accessed. That means the data bus must be valid at half the time of the cpu clock cycle. So is PH1+PH2 = 280ns, external memory/device needs to have valid data on the data bus in half that time ~140ns. But timing for such things are tight, so you need to have the memory/device a little faster than that. 120ns sounds right. From what I understand, this wasn't changed on the SNES processor package.

Yes, you're right! I knew that but never thought about its implications

Thanks!

kyuusaku wrote:Internal /ROMSEL propagation + 139/MAD-1 propagation.

So... how much is that?

Posted: **Wed Feb 02, 2011 3:40 pm**

~140ns - 120ns = <20ns which seems right for the logic being two gates deep + I/O buffers.

Possibly /ROMSEL could be predecoded and latched along with the address bus but it's unlikely they'd modify the mask so maybe Nintendo's 120ns specification is actually assuming /ROMSEL decoding only (probably also ~20ns). That would make the mask ROMs used with an address decoder actually 100ns.

Posted: **Thu Feb 03, 2011 1:18 am**

kyuusaku wrote:That would make the mask ROMs used with an address decoder actually 100ns.

Umm... don't think so... The MaskROM is usually enabled by /RD, which I think it's not decoded from the address bus, but it is a signal from the 65C816. That means MaskROMs are enabled just when the address appears on the bus. From that moment, it takes 120ns for the data to be present on the MaskROM output data bus.

/OE can be asserted any moment during those 120ns and this signal is decoded from /ROMSEL (MAD-1 decodes the bus address and asserts MaskROM's /OE). So the total time for /OE is:

Code: Select all

time to assert /ROMSEL (let's assume 20 ns) + time to MAD-1 to decode it (unknown) < MaskROM's tacc (120 ns by specifications) - MaskROM's time from /OE to data on the bus (tipically 20 ns)

That makes MAD-1 decoding time is something around 70ns, but I would like somebody to confirm it...

Posted: **Thu Feb 03, 2011 1:53 am**

You're free to think what you like..

I think you should recheck some boards/your cart pinout (and not be a dick).

Posted: **Thu Feb 03, 2011 2:21 am**

kyuusaku wrote:(and not be a dick).

Why are you insulting me? You could correct me if I'm wrong, instead... Just like I did with you, because MaskROMs used with a decoder AREN'T -100 ns speed grade, I checked it...

And I also checked that -120ns EPROMs work with some games and not with others... And I prove what I said about /OE and /ROMSEL:

My doubt is about /RD, which I suppose it should be some decoding from 65C816's RWB output pin, without taking into account address bus. That would make negligible the /RD delay.
My aim is finding out which time delay adds MAD-1.

Posted: **Thu Feb 03, 2011 11:07 am**

He wasn't insulting you. He was giving you a recommendation and saying he's not trying to "be a dick" to you.

Posted: **Thu Feb 03, 2011 11:38 am**

Is English not kyuusaku's first language? It sure sounded to me like he was telling the poster to not be a dick.

nesdev.org

SNES ROM access timing

SNES ROM access timing

Re: SNES ROM access timing

Re: SNES ROM access timing

Re: SNES ROM access timing