SlowROM vs FastROM

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

SlowROM vs FastROM

Post by Near »

So the idea was that some games had 200ns ROM access speeds at 2.68MHz, which were cheaper but you couldn't enable FastROM mode via $420d.d0 = 1. And then you had the 120ns or better ROM access speeds for 3.58MHz access, where you could enable FastROM.

FastROM speeds only apply to $80-bf:8000-ffff and $c0-ff:0000-ffff.

So the question becomes ... what happens if we try enabling FastROM anyway on these SlowROM boards?
I had expected that two sequential reads in a row would end up returning the same value or something along those lines.
In practice ... I can't find any difference at all!

I wrote code that performs a 16-bit checksum of 32KB of ROM data from 00:8000-ffff and 80:8000-ffff. With FastROM enabled on a SlowROM board, I get the same results. Tried on a dozen boards. Also compared 40:0000-ffff to c0:0000-ffff.

It's obviously more difficult for me to execute code from commercial game ROMs for more frequent ROM access (I literally can't automate it to test all my games), but hitting the ROM twice in as many cycles 16,384 times should be enough to trigger even a single glitch one time. Yet, nope.

And further expanding on this behavior ... is there any such thing as SlowRAM? Because RAM can appear in areas that are subject to FastROM speeds, eg the 1AxB boards that put RAM at $f0-ff:0000-ffff. But, so far no difference there either.

If there's a difference, I want to catalog it in my database. But so far, it appears there isn't ...
Last edited by Near on Fri Dec 07, 2012 1:57 pm, edited 1 time in total.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: SlowROM vs FastROM

Post by tepples »

I'm not an electrical engineer, but I have written memtestARM, a program for Nintendo DS that tests the speed of external memory that fits in SLOT-2 (the GBA slot) and is used by DSLinux, Nintendo DS Browser, and GBA compatibility modes offered by SuperCard and M3 flash adapters. There's a register in the GBA and DS that controls timing for this memory region. Most games have to be patched to run on a SuperCard because after the GBA boots into what is essentially slow ROM mode, most games immediately shift to a faster mode that works on GBA mask ROMs but the SuperCard's DRAM can't handle. The patch keeps the GBA in slow ROM mode but turns on program prefetching, which minimizes the speed hit from operation in slow ROM mode.
byuu wrote:So the question becomes ... what happens if we try enabling FastROM anyway on these SlowROM boards?
The ROM might occasionally not return a stable result in time. Even if it works for you, it might not work in warmer temperatures when the console is left on for days at a time (because the game has no save) during the summer in a house with no air conditioning. How long did you run your checksum program? Besides, it's not the board as much as the ROMs that are soldered to it.

So the master clock period is 8800/189 = 46.56 ns. As I understand it, the difference is that a fast ROM guarantees that all lines stabilize within three master clocks (140 ns) after chip enable and address stabilize; a slow ROM may need five (210 ns). Individual specimens of a ROM rated for slow operation may be faster, but some manufacturers may impose a safety margin on their parts so that they can meet the guarantee. So even if one ROM from a batch might work, that doesn't mean all ROMs from all batches from all manufacturers will work.
And further expanding on this behavior ... is there any such thing as SlowRAM?
Both ROM and RAM have access speeds guaranteed by their manufacturers. RAM accessed through a fast address space has to be rated 140 ns or faster for reliable operation.
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: SlowROM vs FastROM

Post by Near »

> How long did you run your checksum program?

Couple minutes.

> it's not the board as much as the ROMs that are soldered to it.

Of course. The ROM header has a flag ($ffd5.d4) to say whether FastROM is required, but in about three games the value was overwritten with longer than allowed titles. And I don't trust header information anyway. I want to determine whether the ROM is fully capable of FastROM or not, and so far I can't find a way to do this. They all seem like they'll work just fine.

> As I understand it, the difference is that a fast ROM guarantees that all lines stabilize within three master clocks (140 ns) after chip enable and address stabilize; a slow ROM may need five (210 ns)

Yes, but it's 120ns and 200ns.

> So even if one ROM from a batch might work, that doesn't mean all ROMs from all batches from all manufacturers will work.

I've tested over a dozen boards now.

> Both ROM and RAM have access speeds guaranteed by their manufacturers. RAM accessed through a fast address space has to be rated 140 ns or faster for reliable operation.

Of course. My question was if there were any 200ns RAM chips used in any SNES games. I've only ever seen 70, 100, and 120; but I don't like ruling things out without verification.
User avatar
TmEE
Posts: 960
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Re: SlowROM vs FastROM

Post by TmEE »

In case of MD, I have found the ROMs to be vely tolerant to faster access. Overclocking works great mostly !
At one time when I tested a method that allowed bypassing of TMSS screen I got problems with DMAs. My modification made timings a bit faster on cycle start and there were plenty of games that had garbled GFX from time to time.
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: SlowROM vs FastROM

Post by Near »

In the SNES' case, DMA is forced to 2.68MHz (200ns) access time always, so I can't use that for testing, either.

I think you basically have it right. They're being rated for 200ns, but they are extremely capable of responding at 120ns or less.
Which makes it basically impossible for me to analyze the carts and emulate the behavior fully.
There may be a couple boards that will do strange things, especially with prolonged hammering of actual code, but it could vary from cart to cart.

All the same, it saves me the work of retesting 722 cartridges, so I guess I shouldn't complain too much.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: SlowROM vs FastROM

Post by koitsu »

Why does fast vs. slowrom mode matter in any way/shape/form when it comes to emulation? Yes, I'm asking a serious question here. It's going to take the same number of cycles to read (via 65816) from the actual mask ROM regardless of what mode you're in, so what exactly, emulation-wise, is gained from giving a shit about this?

Edit: And an addendum: your (byuu's) experience with fastrom vs. slowrom testing completely, 100%, mimics that of my own back during the days of writing my SNES documentation. From what I could find, there was absolutely no difference from the CPU perspective. And as you already covered, DMA runs at 2.68MHz no matter what, so all in all I concluded that the fastrom shit is something that matters only to EE folks and really has little to no bearing in actual practise (and especially WRT emulation).

The one exception was Caution #15 in the official SNES developers manual, but that really isn't a "Caution" as much of a "FYI" (on power-on and reset, P=$00, so a long jump (e.g. JML $xxxxxx or JMP $xxxxxx or in Nintendo's assembler JMP ~) to something in bank $80 allows for continued usage of memory timings pertaining to 3.58MHz rather than in bank $00 where you'd be using 2.68MHz. But again: when it comes to the CPU, I cease to see how this matters, because you're limited by cycle times anyway, so the whole slow/fastrom thing always seemed like somewhat of a gimmick to me. To EE folks it probably matters, but when it comes to actual "overall system operation" (from a programmer's perspective) there's no difference.

Edit #2: I wonder if the clock speed adjustment plays a role with regards to the hardware multiplication/division registers and how many CPU cycles they take to return results? The docs have always said "this op takes N cycles" (referring to CPU cycles), but I wonder if $420D bit 0 would affect that or not. The SNES CPU internally always runs at 3.58MHz, but I can't remember if the hw mul/div stuff was offloaded onto a separate chip (on a private bus) or was actually part of the CPU itself (or maybe it was in a separate section of the die/CPU itself). I'm inclined to think $420D wouldn't have any bearing on this, but hell if I know. I'm just a simple caveman! ;-)
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: SlowROM vs FastROM

Post by Near »

> Why does fast vs. slowrom mode matter in any way/shape/form when it comes to emulation?

That's what I do. I simulate anything that can be detectable, regardless of whether or not any games rely on the behavior.
I similarly emulated mul/div cycles, so you can read it early and get partially calculated results. No game does this because it's useless.
Recently a few people used it to detect emulators though.

I don't emulate the SNES hardware solely to play games. I emulate it because I find it interesting to understand how it works.
It may be pointless, but one could say anything were pointless. I'm having fun, that's all that matters.

> JMP to something in bank $80 allows for continued usage of memory timings pertaining to 3.58MHz rather than in bank $00 where you'd be using 2.68MHz

It's possible the chips would choke if they were fetching a tight loop that constantly read from the ROM chips. But I can't automate a test because every game will have different code. The ROM stamps don't say their speed. And the ROM headers are often overwritten by overly long titles. So yeah ... even if there is a difference, I have no reliable way to detect it.

> Edit #2: I wonder if the clock speed adjustment plays a role with regards to the hardware multiplication/division registers and how many CPU cycles they take to return results? I'm inclined to think $420D wouldn't have any bearing on this, but hell if I know. I'm just a simple caveman!

I'm sorry if my world frightens and confuses you.

But if there's one thing you should know, it's that $420d has no effect on MUL/DIV cycles. After each cycle (for others: a cycle is 6, 8 or 12 master clocks depending on the memory area and FastROM setting), one extra step is executed. The multiplication is an eight step Booth algorithm, division is a 16-step algorithm. blargg figured it out bit-for-bit, because he's freakin' awesome like that.

A fun side effect that nobody emulates: If you start a DIV during a MUL or vice versa, the chip goes absolutely berserk on the output values. It's not as simple as both running at the same time, there's some shared gates or something. We can't make heads or tails of the data. It's amusing how the rabbit hole never ends.

Another fun aside: Taz-Mania reads the MUL results way too soon. But since it only multiplies small values, the correct results are ready.
I wanted to emulate the delays because ROM hackers were writing code that didn't work on hardware, eg BS Zelda and Parallel Worlds.
I just set a dummy delay and returned 0 if you read too soon, and it broke Taz. Gotta do it right =)
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: SlowROM vs FastROM

Post by infiniteneslives »

byuu wrote: They're being rated for 200ns, but they are extremely capable of responding at 120ns or less.
The other thing to realize is the speed rating is usually only what the part was tested to, not what the maximum of what the part was found to be capable of. If it takes less test time to test a part to lower speed standards, and that's all the customer wants, the part only gets tested to the lower speed even if it's much more capable. Additionally, memory speed is dependent on voltage and temperature, your probably not at the worse case for these either. That and your data pattern probably isn't the worst possible case for the die. So really in practice it's not surprising at all that your 200ns rated memory can perform close to twice as fast as it's rated.

If the people making the memory didn't take the time to fully characterize the memory speed it's probably not worth your time either... ;)
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: SlowROM vs FastROM

Post by lidnariq »

This is just an anecdote, but maybe it might be useful?

I set my NES up with a copy of SMB2, which has 250ns rated ROMs, and my oscilloscope to look at M2 and D7 with the oscilloscope in "infinite persistence" mode. I triggered on both falling and rising edges on D7 in turn, and waited to see the longest delay from M2 high to D7 change. The longest delays I saw were 190ns (D7 rising) and 130ns (D7 falling), and the shortest I saw were 70ns both ways. This includes the /ROMSEL delay.

If it's useful, I can try to do the same test with my SNES with one of the few random games I have. (surface mount will make it harder)
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: SlowROM vs FastROM

Post by Bregalad »

byuu wrote:[...]
So the question becomes ... what happens if we try enabling FastROM anyway on these SlowROM boards?
[...]
With FastROM enabled on a SlowROM board, I get the same results. Tried on a dozen boards.
I stop your right there. The board has no relation to the speed of the ROM.
It's the ROM itself which is fast or slow.

I think it's probably impossible to find slow ROMs anymore today, so of course you can't observe what happens if you force fast access to slow ROMs, but obviously the data would not have arrived on time when the CPU fetch it, and the would crash, reading wrong opcodes.
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: SlowROM vs FastROM

Post by nocash »

Bregalad wrote: I stop your right there. The board has no relation to the speed of the ROM.
It's the ROM itself which is fast or slow.
That's true. But the ROM is on the board.
Knowing that, it should be possible to find the ROM. Even nowadays :-)
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Re: SlowROM vs FastROM

Post by blargg »

I made several SRAM devcarts out of games that had save memory and had no problem executing in FastROM mode out of SRAM. I agree that FastROM is mostly a waste, as it's ony something like 20% faster at best, only speeding up some cycles of an instruction by a little bit.
User avatar
MottZilla
Posts: 2837
Joined: Wed Dec 06, 2006 8:18 pm

Re: SlowROM vs FastROM

Post by MottZilla »

Isn't speed of a cycle relative to master clocks based on the memory accessed that cycle? Something like 6, 8, and 12? I also thought I read somewhere that internal operation cycles where only memory inside the CPU is changed always run at the 6 cycle timing or fast 3.58mhz frequency. So that would mean that even using "slowrom" the cpu wouldn't always have ever cycle taking 8 or 12 master cycles but often some would take 6 since they were internal operations? I'm not sure, I'm asking if anyone can clarify. It does seem a bit silly. It would have been nice if the SNES could have run at 3.58mhz and had DMA at that frequency too, though I guess the speed of the PPU access would need to account for that.
iNCEPTIONAL

Re: SlowROM vs FastROM

Post by iNCEPTIONAL »

I have no idea what you guys are talking about on a technical level, but I do know this:

https://youtu.be/siwZTorWw2E

https://youtu.be/HBEp5isXIlc

https://youtu.be/_I25jrZe7os

I, as a layman, can clearly see a difference between these games running in SlowROM vs FastROM.

And, as a layman, that's all I care about at the end of the day--it making games run faster and play smoother.

Job is a good 'un.
Post Reply