SNES ROM access timing

[magno]

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

That's NOT like it sounded... but anyway, I didn't feel offended and I'd rather read somebody's explanation to my doubt than those kind of comments.

Anybody knows the answer?

[3gengames]

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

That's NOT like it sounded... but anyway, I didn't feel offended and I'd rather read somebody's explanation to my doubt than those kind of comments.

Anybody knows the answer?

I think him adding the word AND in there was just a little typo. Hope you find this out!

[kyuusaku]

English is my first language and yes I thought he was being a dick. The OP starts with a somewhat arrogant tone (probably I'm the only one to see because I posted diagrams, including a 257 one, in the thread referenced), then I was replied to with ellipsis, bolded keywords and datasheet parameters. This is an aggressive, argumentative writing style that asserts fact/superiority. Whatever, it's not a big deal, just off-putting for me, someone initially trying to help, not defend my posts.

To put it simply magno, it appears you have /RD and /ROMSEL confused. This is common and persists because of siudym's pinouts. (It looks like he fixed the cartridge pinout but I guess the mask ROM reflects the old one). You may have better results if you exchange them.

It has been my experience after looking at dozens of systems, including the SNES, that ROMs are usually enabled by an address decoder such as /ROMSEL. Both CPU and ROM setup times are designed around this arrangement so using it is the most efficient in terms of power and access time (not so much with the 816 if /RD is asserted throughout the access period, but absolutely critical in other systems).

Yes, /RD is negligible here, but it's because (/OE || /CE) to valid data is generally <50ns (+ the time to decode /RD from R//W and E or whatever assuming unmodified CPU) and long before the /CE-reliant row/column decoders have finished.

There is no question that the default address decoder is /ROMSEL and that the MAD-1 and 139 circuits further decode /ROMSEL. That's why I have proposed these arguments cause for investigation:

-whether /ROMSEL is predecoded before the address latch (unlikely but it would probably save 20ns)
-whether the later mask ROMs are really 120ns since there is probably 40ns of decoding delay between /ROMSEL and the MAD-1 (I personally haven't seen a Nintendo mask ROM with a clear speed grade but I can take magno's word for it to refute the <120ns proposition)

OR (here's a new one)

-whether data really is latched 140ns from the address being valid/end of the clock phase; we're assuming (1 / (21477272.727 / 6)) / 2 or an access time of 139.683ns for "FastROM". Well, IIRC Nintendo recommends 200ns for "SlowROM" whose reciprocal clock would be 2.5 MHz, obviously not suitable for 2.68 MHz operation without even taking address decoding into consideration. There must be a wait state or something else to the access times.

[tepples]

If I were Nintendo, I'd design "SlowROM" to extend the bottom of /ROMSEL by two clocks. So if FastROM is 3 up 3 down, SlowROM would be 3 up 5 down.

[magno]

English is my first language and yes I thought he was being a dick. The OP starts with a somewhat arrogant tone (probably I'm the only one to see because I posted diagrams, including a 257 one, in the thread referenced), then I was replied to with ellipsis, bolded keywords and datasheet parameters. This is an aggressive, argumentative writing style that asserts fact/superiority. Whatever, it's not a big deal, just off-putting for me, someone initially trying to help, not defend my posts.

......Did you piss off because I bolded "/RD" and "/ROMSEL"?? Datasheet parameters is a "agressive argument"?? So If I make a question with no idea at all of what I'm asking, I'm a annoying noob... if I know what I'm talking about because I have some experience, I'm arrogant... I thought this forum could be used to ask technical questions, not to argue about nosenses...

To put it simply magno, it appears you have /RD and /ROMSEL confused. This is common and persists because of siudym's pinouts. (It looks like he fixed the cartridge pinout but I guess the mask ROM reflects the old one). You may have better results if you exchange them.

Maybe you're right... I thought that:

* /ROMSEL is the signal asserted on the shaded adresses:

http://magno.romhackhispano.org/SNES_Memory_Map.jpg

* /RD is the signal asserted when the CPU is on a read cycle: to fetch an opcode or data from ROM, reading from WRAM, reading from SRAM or reading from the registers (altough I'm not sure about the latter)

Yes, /RD is negligible here, but it's because (/OE || /CE) to valid data is generally <50ns (+ the time to decode /RD from R//W and E or whatever assuming unmodified CPU) and long before the /CE-reliant row/column decoders have finished.

Maybe I'm wrong again, but I thought MaskROM's /OE and MaskROM's /CE are not the same:
* /CE (or /CS) enables the chip, so it "begins" looking for the data and it takes to get it 120 ns (or the time access).
* /OE releases the tri-state on the output pins for the data to be present 120ns after /CS is asserted.

-whether /ROMSEL is predecoded before the address latch (unlikely but it would probably save 20ns)

It's not a crazy idea... /ROMSEL could be decoded using A23-A15 (assuming that signal is asserted on the shaded addresses I showed above), so it could be decoded using A23-A16 in the first phase (before the bank latch) and later enabled with A15...

-whether the later mask ROMs are really 120ns since there is probably 40ns of decoding delay between /ROMSEL and the MAD-1 (I personally haven't seen a Nintendo mask ROM with a clear speed grade but I can take magno's word for it to refute the <120ns proposition)

I did a test with an oscilloscope and my FPGA board: I made a program that generates addresses (A20 to A6, the other MaskROM's address pins grounded) every 15 seconds with an "ADDRESS ASSERTED" line used as /CS; /OE was grounded.
When I got data on the output bus 107ns after asserting /CS, I was absolutely sure that MaskROM was not -100ns... maybe -110ns? maybe -120ns? Not sure, but developer's manual is pretty clear about that: ROM's at least 120ns.

-whether data really is latched 140ns from the address being valid/end of the clock phase; we're assuming (1 / (21477272.727 / 6)) / 2 or an access time of 139.683ns for "FastROM". Well, IIRC Nintendo recommends 200ns for "SlowROM" whose reciprocal clock would be 2.5 MHz, obviously not suitable for 2.68 MHz operation without even taking address decoding into consideration. There must be a wait state or something else to the access times.

I didn't understand

[kyuusaku]

No I mean it's obnoxious to have someone disagree in an argumentative manner and yes emphasizing things was unnecessary.

Of course your understanding of /RD (/OE) and /ROMSEL (/CE) is correct, but it conflicts with what you posted earlier and with the cartridge diagram.

If you have the hardware setup for testing, why not test the MAD-1 and access period yourself? Surely you can measure it down to 5ns resolution.

[magno]

Of course your understanding of /RD (/OE) and /ROMSEL (/CE) is correct, but it conflicts with what you posted earlier and with the cartridge diagram.

The cartridge diagram is not a repro... it's actually what is routed on the PCB that host an original Chrono Trigger (Japanese). I mean that I represented on that hand-made schematic a real SHVC-1J3M-20.

If you have the hardware setup for testing, why not test the MAD-1 and access period yourself? Surely you can measure it down to 5ns resolution.

Because I don't know address-to-/ROMSEL delay in a real SNES, so I could measure address to /HI, /LO, /ROM_OE, /SRAM_OE delay and so on, and then measue /ROMEL to /HI, /LO, /ROM_OE, /SRAM_OE delay too, but I still wouldn't know the real timing, because I don't know when /ROMSEL is asserted after addresses.

Edit: wait, /ROMSEL can't be decoded in the prior phase because the high address bits are precisely the ones latched.

Yes, you are right, unless the decoded signal is latched too, although I think that is pretty unlikely.

[kyuusaku]

I understand, but where did you get your mask ROM pinout? This is the only discrepancy. I can't read the diagram clearly but what looks like /OE is connected to the MAD-1 and /CE to /RD, backwards.

All you need is the MAD-1 delay by itself, /ROMSEL's delay can be measured by sampling from A23:15 stable to /ROMSEL asserted. If the lower address bits are stable long before A23:16 we know Nintendo used an edge triggered register. If /ROMSEL changes with A23:16 it's predecoded.

I'm really tired so I shouldn't have posted that about the bank address. I thought about it and if Nintendo used a transparent latch instead of register, predecoding wouldn't even be necessary and pretty much all address decoding would occur within Phi1 or a few ns into Phi2 >.< This could be the case and solve the SlowROM mystery too but it cuts things really close. (I think tepples is onto something with asymmetrical duty-cycles.)

[magno]

I understand, but where did you get your mask ROM pinout? This is the only discrepancy. I can't read the diagram clearly but what looks like /OE is connected to the MAD-1 and /CE to /RD, backwards.

I got the pinout here:

http://nintendoallstars.w.interia.pl/ro ... esroms.htm

And yes, MaskROM's /OE is connected to MAD-1 pin 4, and MaskROM's /CS to /RD.

I think that is the proper wiring, since /RD is asserted first of any other signal (a bit later than A23-A0) so MaskROMs is enabled at that moment. After that, /ROMSEL is asserted, but the MaskROM can't "see" that signal yet... /ROMSEL is decoded along bus address on the MAD-1, and then its pin 4 is asserted, pulling down MaskROM's /OE and enabling its output. When that occurs, probably the MaskROM hasn't got the data yet (because of its time access), but the output is already enabled, so we don't take into account "/OE to data valid" timing in the calculations.

Am I wrong?

[tepples]

and yes emphasizing things was unnecessary.

Often, I've bolded things such as names of programming keywords or what to type at a command prompt because BBCode in phpBB 2 lacks an inline element comparable to HTML's <code>. Instead, the

Code: Select all

 element of BBCode corresponds to HTML <pre>, a block element.

[kyuusaku]

Exactly, I'm 95% sure the signals are swapped in that pinout. Just to be sure I verified that pin 24 is connected to /RD and that pin 33 is connected to /ROMSEL on a game without an address decoder. I have not verified that the functions are correct because this is the normal arrangement and the fact that /RD and /ROMSEL were confused in the past*, I don't see any reason to believe /RD is connected to /CE and /ROMSEL to /OE.

*the ROM pinouts appear to be derived from cartridge wiring on the site, not actually measured, so I believe mask ROM /OE was only verified as being connected to /RD, which was thought to be "/CE" aka /ROMSEL in the old pinout. OK, I think I've gone on enough about this XD

I understand how you think it should be but did you verify that your /OE pin is really /OE? Do you have the timings now? You can justify some reasoning behind it but it's pointless if the pinout is incorrect. Again all I have to go by is what is logical, I really don't want to spend the time building a circuit to test. I did open up a bootleg of Mortal Kombat II though which should be FastROM and its address decoder selected /CEs, not /OEs (verified because they have a JEDEC pinout). The ROM speeds are not on the packages but I still expect that this typical arrangement is also true for Nintendo ROMs.

Often, I've bolded things such as names of programming keywords or what to type at a command prompt because BBCode in phpBB 2 lacks an inline element comparable to HTML's <code>. Instead, the

Code: Select all

 element of BBCode corresponds to HTML <pre>, a block element.[/quote]I understand when the intent is to increase readability, but right now we're getting by without bolding /RD, /ROMSEL and friends. How I interpreted [b]it[/b] would be [u]roughly[/u] equivalent to [b]this[/b]; stressing words makes an explanation sound authoritative, and in the right context (such as a very simple explanation) it can be perceived as condescending.

[magno]

I understand how you think it should be but did you verify that your /OE pin is really /OE? Do you have the timings now?

No, I didn't verify it, I assumed what I found in ROMLab as true... But now I realize you're right, becasue it makes sense: /ROMSEL enables the MaskROM only when it is needed, thus saving power (decreasing consumption)... And there is a prove of that, besides the two you said: SRAM on those cartridges is enabled using the output of MAD-1, which uses /ROMSEL to decode that line. So SRAM is using /ROMSEL to enable it and /RD to enable its output. And now no mistake is possible, as I have SRAM's datasheet...

Well then, that changes everything I believed in I should recheck my repro's schematics to understand why they work anyway and if there should be any other better way of making the wiring.

As for MAD-1 delay, I don't feel like setting up again the proto board to test it, but maybe I'd do it some time in the future, if it is interesting to somebody.

Thank you very much for your help!

How I interpreted it would be roughly equivalent to this; stressing words makes an explanation sound authoritative, and in the right context (such as a very simple explanation) it can be perceived as condescending.

As for that, I don't think it sounds authoritative... in fact, it doesn't "sound"... I bolded all signal names because sometimes is really hard for non-english speakers to follow a conversation full of acronyms... I did it for comprehension's sake, now it is up to you believe it or not.

[kyuusaku]

Yes, I'm glad you agree now. No hard feelings!

I believe the reason exchanging the signals still worked is because the 816 doesn't have picky timing. On another CPU, such as one with many cycles per fetch, /RD might only assert on the last state/phase of a cycle and asynchronously enabling the ROM any earlier could cause a bus conflict with internal operations.

If it is true that Nintendo latches the bank address with a transparent latch, the address will be valid <90ns into Phi1, /ROMSEL will assert maybe <120ns into Phi1 and the 139/MAD-1 will assert <20ns into Phi2 assuming FastROM. I chose 40ns for the 139 because sometimes the individual decoders are chained. This leaves the 120ns before data is sampled.

On the other hand enabling the ROM with /RD starts in Phi2. /RD must be asserted <30ns into Phi2 (it's probably decoded by R//W NAND Phi2) and the ROM data will be valid 120ns after that. Perhaps /RD is asserted 15ns into Phi2 which causes only ROMs faster than their rated 120ns to work when paired with a 15ns 257.

In both proposed explanations the timings are conservative, there must be a little headroom or the working 257 circuit you built wouldn't work. IIRC the WDC datasheet says the address is valid after around 50ns @ 5V (+ ~20ns for the latch) so that could make room for a 257.

[magno]

I believe the reason exchanging the signals still worked is because the 816 doesn't have picky timing. On another CPU, such as one with many cycles per fetch, /RD might only assert on the last state/phase of a cycle and asynchronously enabling the ROM any earlier could cause a bus conflict with internal operations.

I have news about this...
This morning I finished my Chrono Trigger repro using 27C322 and two 74HC257. I followed your advice and did the following rewiring:

* EPROM's /CS -> "ROM /OE" from MAD-1
* EPROM's /OE -> GND
* 74HC257's /OE -> /RD

But it didn't work... Right now I've opened the cartridge and rewired this way:

* EPROM's /CS -> /RD
* EPROM's /OE -> GND
* 74HC257's /OE -> "ROM /OE" from MAD-1

And now IT WORKS! The 27C322 EPROM is -100ns speed grade...

How could it be? What else am I missing?
Does it mean that /RD is asserted before /ROMSEL? That would explain timing is correct using /RD as EPROM enable because the data is available sooner than when using MAD-1's pin 4.

If it is true that Nintendo latches the bank address with a transparent latch, the address will be valid <90ns into Phi1, /ROMSEL will assert maybe <120ns into Phi1 and the 139/MAD-1 will assert <20ns into Phi2 assuming FastROM. I chose 40ns for the 139 because sometimes the individual decoders are chained. This leaves the 120ns before data is sampled.

On the other hand enabling the ROM with /RD starts in Phi2. /RD must be asserted <30ns into Phi2 (it's probably decoded by R//W NAND Phi2) and the ROM data will be valid 120ns after that. Perhaps /RD is asserted 15ns into Phi2 which causes only ROMs faster than their rated 120ns to work when paired with a 15ns 257.

In both proposed explanations the timings are conservative, there must be a little headroom or the working 257 circuit you built wouldn't work. IIRC the WDC datasheet says the address is valid after around 50ns @ 5V (+ ~20ns for the latch) so that could make room for a 257.

I'll recheck 65C816's datasheet and will make some time diagrams to fully understand all these.

[kyuusaku]

The reason the first way didn't work is because you are enabling the 257 with /RD. /RD is asserted on every memory read so you are trashing the bus. In the other thread I used a 139 decoder to create an OR gate (/ROMSEL OR /RD) which is the proper condition. I think you could change around the MAD-1 connections to get this condition too since both ROM decoders aren't used with a single ROM, just replace the "select" address line input with /RD.

The transparent latch theory shows that /ROMSEL (and MAD-1 likely) will be asserted before /RD, I believe that's how it is.