It is currently Tue Jan 16, 2018 8:43 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 13 posts ] 
Author Message
 Post subject: SlowROM vs FastROM
PostPosted: Fri Dec 07, 2012 1:31 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1340
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 byuu on Fri Dec 07, 2012 1:57 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: SlowROM vs FastROM
PostPosted: Fri Dec 07, 2012 1:47 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19477
Location: NE Indiana, USA (NTSC)
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 the GBA boots into what is essentially slow ROM mode, but 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.

Quote:
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.


Top
 Profile  
 
 Post subject: Re: SlowROM vs FastROM
PostPosted: Fri Dec 07, 2012 2:01 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1340
> 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.


Top
 Profile  
 
 Post subject: Re: SlowROM vs FastROM
PostPosted: Fri Dec 07, 2012 2:11 pm 
Online
User avatar

Joined: Wed Feb 13, 2008 9:10 am
Posts: 606
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
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.

_________________
http://www.tmeeco.eu


Top
 Profile  
 
 Post subject: Re: SlowROM vs FastROM
PostPosted: Fri Dec 07, 2012 2:17 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1340
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.


Top
 Profile  
 
 Post subject: Re: SlowROM vs FastROM
PostPosted: Fri Dec 07, 2012 5:28 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
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! ;-)


Top
 Profile  
 
 Post subject: Re: SlowROM vs FastROM
PostPosted: Fri Dec 07, 2012 7:39 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1340
> 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 =)


Top
 Profile  
 
 Post subject: Re: SlowROM vs FastROM
PostPosted: Fri Dec 07, 2012 8:35 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1946
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
 Post subject: Re: SlowROM vs FastROM
PostPosted: Sat Dec 08, 2012 12:43 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6633
Location: Seattle
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)


Top
 Profile  
 
 Post subject: Re: SlowROM vs FastROM
PostPosted: Sat Dec 08, 2012 3:59 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7348
Location: Chexbres, VD, Switzerland
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.


Top
 Profile  
 
 Post subject: Re: SlowROM vs FastROM
PostPosted: Tue Dec 11, 2012 6:06 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 540
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 :-)


Top
 Profile  
 
 Post subject: Re: SlowROM vs FastROM
PostPosted: Tue Dec 11, 2012 7:25 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
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.


Top
 Profile  
 
 Post subject: Re: SlowROM vs FastROM
PostPosted: Tue Dec 11, 2012 10:21 pm 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2806
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group