VOGONS


First post, by auron

User metadata
Rank Oldbie
Rank
Oldbie

i used to have some luck obtaining SDRAM timings, which may have actually been from a DIMM specsheet instead of an IC one, but right now i have some nanya 32 meg SIMMs with NT511740C5J-60 ICs - datasheet for these chips is available, but absolutely nothing in there is immediately readable as a value that can be set in BIOS. is there a method to convert some of those values into BIOS setting values? failing that, what is the considered the ideal way to test memory stability on that era of hardware?
candidates:

- memtest86, which could work but from what i have read is geared more towards recognizing hardware faults rather than instability. will test the entire memory range but needs a floppy connected;
- quake timedemo, which should exercise RAM pretty well, but i don't know to what extent unstable memory would necessarily make it crash;
- prime95, of which old versions from ~2000 can be obtained from archive.org, but runs of this seem to take an eternity on pentiums, and it also needs some tweaking to prevent page file spillover.

the simple 60/70ns approach that i have seen in some intel OEM BIOSes was maybe not that bad - you leave some potential performance on the table compared to more detailed settings, but anyone could look at their memory and check for 60 or 70 at the end, so it's a rather safe setting.

Reply 1 of 7, by mkarcher

User metadata
Rank l33t
Rank
l33t

The settings in the BIOS are how the BIOS is going to program the chipset. If you set some timing to "1 WS", it will very likely be one FSB clock period longer than when you set it to "0 WS". You don't know what "0 WS" means until you have a detailed chipset datasheet, though. The BIOS settings don't tell you enough to compare to the memory chip (or memory module) datasheet.

In my experience, quake timedemo is a very effective test to find whether you running memory at a too high access speed. Crashes are quite common if timings are too aggressive. memtest86 indeed aims more to tests that exercise the memory cells, but especially the block move test is also quite effective at finding stability issues, at least for SDRAM systems. My suggestion from personal experience: Try quake first, because it oftentimes crashes within the first timedemo run, which is way quicker than a single memtest86 pass. If quake passes, you can also try booting Windows 2000 (another good stability test). Be aware that booting a complex operating system that includes a couple of disk writes during boot (updating timestamps, writing event logs, ...) has the potential effect of corrupting the installation. If you use the "does Windows 2000 boot" (you might use NT4 as well, if 2000 requires too much RAM), I recommend backing up the installation partition, and restoring to that backup if you got system crashes.

Reply 2 of 7, by auron

User metadata
Rank Oldbie
Rank
Oldbie

well, datasheets for any 430 or 440 series chipset are readily available, of course. does this mean that even when one has datasheets for both the chipset and RAM ICs, and knows what to look for, it is still not possible to determine ideal timings? or is an even more detailed datasheet than the available ones required?

i have a 430FX board that sets a x2222 read burst timing by default - seems to me this could be troublesome with 70ns memory.

Reply 3 of 7, by mkarcher

User metadata
Rank l33t
Rank
l33t
auron wrote on 2024-06-21, 18:09:

well, datasheets for any 430 or 440 series chipset are readily available, of course. does this mean that even when one has datasheets for both the chipset and RAM ICs, and knows what to look for, it is still not possible to determine ideal timings? or is an even more detailed datasheet than the available ones required?

i have a 430FX board that sets a x2222 read burst timing by default - seems to me this could be troublesome with 70ns memory.

When sufficiently decent chipset datasheets are available, you should be able to determin the fastest timing setting that is guaranteed to work. Likely slightly faster settings will work as well, especially if the chips are not too warm. The interesting parameter for x222 read bursts is the page mode CAS cycle time. At FSB66, a single clock is 15ns, so 2 clocks per "word" requires the RAM to support a CAS cycle time of 30ns. EDO tends to support faster page mode cycle times than FPM (that's the whole point of EDO!), I expect nearly all 70ns EDO chips to support a x222 burst. I randomly checked three 70ns EDO data sheets:

  • Siemens HYB5117805BSJ-70: EDO cycle time is 30ns. Just fast enough.
  • Hyundai HY5117404AJ-70: EDO cycle time (called HPC = "hyper page mode cycle time") is 30ns again.
  • Hynix GM71C16403CJ-7: EDO cycle time 30ns again.

So it seems that a x222 burst is OK at FSB66 for EDO memory. I don't expect that to work for 70ns FPM, though. As long as we are just checking the cycle time, propagation delay is not an issue, because the delay does not affect the cycle time. Delays do affect setup and hold times, though. The interesting parameter in that case is the CAS access time. I still have the Hynix data sheet opened, and it specifies a CAS access time of 18ns. You need to compare that time to the required CAS access time by the 430FX. The datasheet I can find for the 82437FX controller does not include any timing details, but it does include the claim that the chipset supports x222 bursts on EDO RAM.

This also shows why you need EDO to get the CAS cycle time of 30ns. These RAMs require around the same time /CAS active (aka low) and /CAS inactive (aka high or precharged). The Hynix datasheet specifies 13ns min each. With FPM RAM, the data goes away "really soon" after /CAS goes high. If the data is available 18ns after /CAS is pulled low, but /CAS is only low for around 15ns, at the time the data is stable, FPM RAM will no longer drive it to the bus. On the other hand, EDO will continue driving the bus when /CAS goes inactive, so the data can be read by the chipset while the RAM chip already prepares to accept the next address.

Reply 4 of 7, by auron

User metadata
Rank Oldbie
Rank
Oldbie
mkarcher wrote on 2024-06-22, 20:30:

So it seems that a x222 burst is OK at FSB66 for EDO memory. I don't expect that to work for 70ns FPM, though.

actually it looks like it's fine because x222 with FPM detected is not a valid setting and becomes x333 instead - at least, that's how i'm reading the datasheet. x333 would be treated as x444, then. it looks like this:

The attachment fpmedo.png is no longer available

i did quickly test this with some 70ns FPM (only 16 meg sticks, though), and as expected, despite same settings the 60ns EDO is a hair faster in pcpbench - 17.8 vs. 17.6 (640x400) and 38 vs. 37.5 (320x200), pentium 133. the BIOS doesn't expose any changes with the FPM installed, still presenting "read burst timing x2222" by default, but this suggests it's actually using the slower timing with FPM, unless EDO features also used transparently in some other way.

Reply 5 of 7, by mkarcher

User metadata
Rank l33t
Rank
l33t
auron wrote on 2024-06-23, 09:23:
mkarcher wrote on 2024-06-22, 20:30:

So it seems that a x222 burst is OK at FSB66 for EDO memory. I don't expect that to work for 70ns FPM, though.

actually it looks like it's fine because x222 with FPM detected is not a valid setting and becomes x333 instead - at least, that's how i'm reading the datasheet. x333 would be treated as x444

That's also how I understand the datasheet, and I am confident we are understanding the data sheet correctly. It would be interesting to know how long /CAS is low and how lang /CAS is high in FPM x333 mode (i.e. register setting "10"), looking at the Samsung KM416C1000B-7 datasheet (again a random 70ns found using Google), I find a page mode cycle time of 45ns, which again perfectly matches the period of 3 FSB clocks, I find a /CAS pulse width of 20ns minimum, but as the access time from /CAS is 20ns as well, if you actually want to read something, you need extra /CAS active time. The /CAS precharge time is just 10ns, so the most convenient timing for reading that chip is to have /CAS low for 2 FSB clocks (30ns), with data being available after 20ns, and /CAS high for 1 FSB clock. Using 1.5 FSB clocks for /CAS low and /CAS high would also just work, but the data valid window would be unconviniently narrow.

auron wrote on 2024-06-23, 09:23:

i did quickly test this with some 70ns FPM (only 16 meg sticks, though), and as expected, despite same settings the 60ns EDO is a hair faster in pcpbench - 17.8 vs. 17.6 (640x400) and 38 vs. 37.5 (320x200), pentium 133. the BIOS doesn't expose any changes with the FPM installed, still presenting "read burst timing x2222" by default, but this suggests it's actually using the slower timing with FPM, unless EDO features also used transparently in some other way.

That interpretation is likely correct, as the only advantage of FPM compared to EDO is the faster possible read burst. You can't know what the BIOS does without reverse engineering it (either by disassembling relevant parts, but much easier by looking at chipset configuration register values when booted). The BIOS core as shipped by the BIOS manufacturers (like AMI, Award or Phoenix) supports a fixed mapping from setup display texts to register values without any code, just by an entry in a setup option table (and that's what you can modify using MODBIN), but the BIOS supports options that are interpreted using code as well. As the 430FX uses the same timing code on every bank, and IIRC the 430FX supports mixed FPM/EDO configurations, I don't think it would make sense to remap x222/x333 to different interpretations depending on the kind of installed RAM. On the other hand, it would make sense to call the option "DRAM burst (EDO/FPM)" and call that setting "x222/x333".

I already have seen BIOS code that dynamically patches the setup table in the BIOS shadow copy depending on run-time detected circumstances (like the type of super I/O chip or the revision of the chipset), but as explained, this approach wouldn't make much sense for the 430FX burst speed, just as setting the burst speed programmatically different depending on installed RAM type doesn't make much sense.

Reply 6 of 7, by auron

User metadata
Rank Oldbie
Rank
Oldbie

i went back and tested the three read burst settings on both sets of memory - there are three different benchmark results for the EDO but only two for the FPM, so it's as expected. the only thing that's a little curious is that x4444 actually comes out a tiny bit faster on FPM than EDO for some reason, 17.3fps/36.7fps vs. 17.2/36.5 fps. i also remembered that some later boards actually do use "x222/x333" to describe the values for that setting, i think the gigabyte ga-586tx3 is an example of that.

Reply 7 of 7, by mkarcher

User metadata
Rank l33t
Rank
l33t
auron wrote on 2024-06-24, 17:03:

the only thing that's a little curious is that x4444 actually comes out a tiny bit faster on FPM than EDO for some reason, 17.3fps/36.7fps vs. 17.2/36.5 fps.

Remember that the key point of EDO is that you can run a faster burst, because it does not stop driving the data lines during the burst as soon as you deassert /CAS. But EDO RAM can not count. It's not like SDRAM with a configuratble burst length, so EDO RAM will not just stop driving the data lines at the end of the burst. You have to take active action to make the EDO RAM stop driving when you are done with the burst. This active action could be deasserting /RAS, but this will close the page, and cause a significant delay if the next burst is going to hit the same page. Another way (and probably the most common way) is to pulse the /WE line while /CAS is inactive. This does not perform a write, but as soon as /WE is asserted, EDO RAM will stop driving the bus, independent whether /CAS is active or negated. This is meant to allow some other device to start driving the data to write. It's not unlikely that the /WE pulse adds an FSB clock to the burst duration. You only notice the extra clock required at the end of the burst, if the next memory access is delayed by that pulse. This means the "EDO penalty" gets worse the more occupied the memory bus is. So it makes sense that the EDO penalty is most observable at x444, as this slow burst puts the most pressure on the memory bus at the same required net throughput.

You only win by using EDO instead of FPM if EDO allows faster bursts than FPM does. As we just discussed is this thread, at FSB66, this is indeed the case, as EDO permits an x222 instead of an x333 burst.