I don't think the Proserva has anything beyond the stock 430HX. It's definitely like mpe has written, EDO timings should be a notch better than FPM.

Can you check, whether the system is actually running at the parameters you have specified in SETUP?

mpe wrote on 2020-03-22, 14:17:

The buffering doesn't have to be on module. It can also happen on the motherboard - look for 74FCT3245A devices or similar close […]
Show full quote

The buffering doesn't have to be on module. It can also happen on the motherboard - look for 74FCT3245A devices or similar close to SIMMs slots.

How many memory slots that can take double density modules are on your board? If more than 4 then there must be some buffering involved.

The 430HX chipset has actually a duplicate copy of MA signals which optionally allows for direct connection to SIMMs (without buffer) and maintain x-222 EDO burst performance on 6-8 SIMM socket motheboards when less than 4 SIMMs are used. However, not every motherboard used this. My GA-586HX does. The HX chipset was a weirdo and often deployed in servers where having more RAM was more important than performance.

AFAIK there are also HX boards with DIMM slots (EDO only) and they are always buffered resulting in x-333 fastest timing.

A photo of the board is provided below.

There are 8 SIMM slots and 7 buffer IC's between the SIMMs and chipset of part number AA244A. The IC's to the left of the SIMM slots are of various 7400 series types. The board works with up to 64 MB double-sided SIMMs. But for the EDO-FPM comparison, I've used singled sided SIMMs for both.

GL1zdA wrote on 2020-03-22, 14:23:

I don't think the Proserva has anything beyond the stock 430HX. It's definitely like mpe has written, EDO timings should be a notch better than FPM.
hx-timings.png
Can you check, whether the system is actually running at the parameters you have specified in SETUP?

How is this done? TweakBIOS shows the setting as x222/x333. With a P54-200 installed, cachechk shows memory read speed as 79.2 MB/s for EDO and 82.2 MB/s for FPM, while memory write speeds are 92.7 MB/s for both.
Why is FPM faster than EDO on this motherboard and can this be circumvented, perhaps with one of those other TweakBIOS settings?

I think you can take it as granted that this board with 8 SIMM slots must use buffered RAM signals to stay within specs. The string of small chips just under SIMM slots is #1 candidate for me (can't read markings). Whether this board also supports buffer bypass ( to enable x222 EDO timing for 2 or 4 row config) is something I don't know.

Not that familiar with TweakBIOS, but I understand this is a generic tool that is unlike BIOS not designed specifically for this board. So even if it offers some settings, are you sure it actually works? If you reduce the EDO setting to x333 do you see any drop in read performance (cachchk)?

TweakBIOS, like CTCHIP34, is not system-specific, but has independent configuration files for numerous chipsets. In this case, I would run tweaks.exe hx.dat. Using the current settings shown in TweakBIOS, I am able to view and adjust what memory read burst timings are being used when different RAM is installed.

In the case of FPM being installed, the memory read burst timings are shown as x222 / x333 in TweakBIOS.

When EDO memory is installed, the memory read burst timings are shown as x333 / x444 in TweakBIOS.

So it looks as if the BIOS is reducing the read burst timings when EDO memory is installed, but why? I can force the timing to x222 / x333 instead of x333 / x444 using TweakBIOS. In doing so, I see the Cachechk memory read speed increase from 96.0 MB/s to 116.3 MB/s. In my previous posts, the cachechk results were with a P54-200 but now I'm using a P55-233. For comparison, the FPM read speed is at 100.0 MB/s with x222 / x333. This begs the question - why is the BIOS reducing memory read bust timings when EDO is installed? Stability issues? Or perhaps parity EDO was never much of a consideration at the time of production and the speed was limited for safe measure.

I have run Quake and DOOM with the EDO x222 setting. The Quake results at 320x200 have increased from 50.46 fps (FPM) to 51.2 fps (EDO x222). DOOM increased from 99.45 fps (FPM) to 99.72 fps (EDO), or about 1.5% and 0.3%, respectively. Not the 5% I was hoping for.

Thinking that the BIOS may be limiting the EDO speed because of instability problems, I booted Win98SE and ran GLQuake and it seemed to do fine with x222 EDO.

Unfortunately, programs like CTCHIP34 and TwkBIOS work in DOS, so they are not solutions for NT4 and W2K, but perhaps WPCREDIT will work with this board (doubtful)? Is anybody here willing to hack the BIOS to set x222 when EDO RAM is used?

mpe wrote on 2020-03-22, 22:10:

I think you can take it as granted that this board with 8 SIMM slots must use buffered RAM signals to stay within specs. The string of small chips just under SIMM slots is #1 candidate for me (can't read markings).

In my previous post, I mentioned the markings on these chips were AA244A. Is there more information that you'd need? The complete markings are AA244A <carriage return> Ti logo 73K <carriage return> A9K2. The last line varies by chip.

feipoa wrote on 2020-03-23, 07:26:

In the case of FPM being installed, the memory read burst timings are shown as x222 / x333 in TweakBIOS.

When EDO memory is installed, the memory read burst timings are shown as x333 / x444 in TweakBIOS.

This might be an explanation:

feipoa wrote on 2020-03-23, 07:26:

Unfortunately, programs like CTCHIP34 and TwkBIOS work in DOS, so they are not solutions for NT4 and W2K, but perhaps WPCREDIT will work with this board (doubtful)? Is anybody here willing to hack the BIOS to set x222 when EDO RAM is used?

Try this:

1PCR(PCI Configration Registers) Editor / WPCREDIT for WIN32
2Copyright (c) 1998  H.Oda!
3
4[COMMENT]=Just changing EDO timings
5[MODEL]=430HX PCIset
6[VID]=8086:Intel
7[DID]=1250:Host to PCI Bridge
8
9[58:5..6]=DRAM ReadBurstTiming     10=x222 01=x333 00=x444
10[58:3..4]=DRAM WriteBurstTiming    10=x222 01=x333 00=x444

I don't think you even need a config file, just set the relevant bits (3, 4 for write, 5,6 for read) at 0x58 to the desired values. The 430FX uses the same registers for this, so you can try the 430FX pcr.

Yes 244 series is a 8 channel buffer.

It has propagation delay between 2.5 - 7 ns and output enable time between 2 - 8 ns which increase effective RAM access time.

I think the chipset could be trying to compensate for these delays by increasing the cycle time.

These delays should apply to FPM too. However, perhaps the FPM with less aggressive timing still manages to stay within specs somehow? Not sure.

Thank you. What's the procedure for using WPCREDIT? I saved your text as a *.pcr file, then I opened the file from within WPCREDIT. WPCREDIT says that the "Vendir ID / Device ID differs !! Does it continue ?" I click YES. I assume I'm not finished yet because I benched memory before and after doing this and the results are the same. So after opening the pcr file, I assume that I should click "save register file", which saves it as 80861250.rg. Then I click on "open register file" and point to 80861250.rg. WPCREDIT says, "Do you rewrite current registar?" I click YES. The result is a BSOD saying *** Hardware Malfunction. Call your hardware ventor for support. NMI: Parity Check / Memory Parity Error. *** The system has halted *** Perhaps I've done something wrong? I'm using NT4 by the way.

Based on the 3.2.16 snipet you posted, my guess is that the manufacturer of the system was able to determine that x222 was stable when using FPM but not EDO. Even with 8 sticks of FPM installed, the system still sets x222 read timings. For write timings, it is set to x222, irregardless of whether EDO or FPM is installed.

I've been testing the system with 8x16 MB FPM single-sided sticks (128 MB total) and 2x64 single-sided EDO sticks (128 MB total). I can limit the system to 4 sticks if that matters, though perhaps not as the the stick limit seems to be related to whether memory access buffers are needed or not. As the buffers are already present, 4 sticks probably offers no stability improvement over 8. Perhaps there is a preference for single-sided sticks though. Further testing is needed for that.

I don't have a 430HX at hand, so I'm just doing it in PCem emulating 430FX, but the "experience" should be similar.
1) Load the *.PRC file.
2) Go to 0x58 (white box with 0x51 in the screenshot). On the right you should see what the bits mean (the PRC is just the description).

3) Click edit. Change bits 6, 5, 4 and 3. WPCREDIT will highlight the description what you are changing. I assume for your case you will change x0101xxx (x are the irrelevant for this case, leave them as they are) to x1010xxx.
4) Now Set and confirm with Yes.
I don't have a physical machine to test it, but the chipset might as well totally ignore it, when the PC is running in protected mode (and that's the case with Windows).

GL1zdA> Thank you for the additional instructions. I had never used WPCREDIT before, or at least I have no memory of it.

Looks like the BIOS address 0x58, bits 6 and 5 are for memory read burst timings, while 4 and 3 are for memory write burst timings. 4 and 3 were already at 1 and 0, so I just needed to set 6 and 5 to 1 and 0.

The system did not hang when saving this register and I was able to benchmark the difference. I am using Sandra99's memory benchmark, which showed 84 / 111 MB/s for CPU/FPU before the change and 92 / 127 MB/s after the change.

I also tested this in W2K and it jumped from 81 / 107 MB/s to 88 / 122 MB/s for CPU/FPU. CPUmark99 jumped from a score of 12.7 to 12.9.

Manually modifying this register boot isn't ideal. Do you know if there is a way to automate this process? I noticed there is an option in wpcredit to "save environment", which saves something to a wpcredit.reg file, the contents of which are here:

1REGEDIT4
2
3[HKEY_LOCAL_MACHINE\Software\NrkLv]
4
5[HKEY_LOCAL_MACHINE\Software\NrkLv\WPCREDIT]
6"FontCol"=dword:00FFFFFF
7"BackCol"=dword:00000000
8"Tit1Col"=dword:0000FF00
9"Tit2Col"=dword:0000FFFF
10"Bit1Col"=dword:00FF8800
11"Bit2Col"=dword:000044FF
12"MarkCol"=dword:0000FFFF
13"Font"=hex:F3,FF,FF,FF,00,00,00,00,00,00,00,00,00,00,00,00,90,01,00,00,00,00,00,00,01,02,01,01,43,6F,75,72,69,65,72,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

Perhaps I add a shortcut to this file in the Windows NT4 and W2K Startup folders? Is the content of this file just the change I made, or is it attempting to re-write all the registers?

feipoa wrote on 2020-03-24, 03:22:

Manually modifying this register boot isn't ideal. Do you know if there is a way to automate this process? I noticed there is an option in wpcredit to "save environment", which saves something to a wpcredit.reg file,

You can manually have it add in the registry under the "run once" in the registry. Something like "REGEDIT.EXE [ /S ] FIXRAM.REG"
You would enter it under: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce]
Under NT4 think you use REG.EXE. added: It's been a while since doing old reg work so am probably a bit off :p

Unfortunately, it doesn't look like that .reg file from WPCREDIT sets the chipset registers, as saving it into the registry has no effect. It is probably related to the layout of WPCREDIT, like colours, fonts and the like.

GL1zdA> Do you know if there is any means of automating on OS startup the setting of the desired chipset register?

There is companion tool WPCRSET to apply settings at system startup.
Some instructions are here: link

feipoa wrote on 2020-03-24, 08:29:

Unfortunately, it doesn't look like that .reg file from WPCREDIT sets the chipset registers, as saving it into the registry has no effect. It is probably related to the layout of WPCREDIT, like colours, fonts and the like.

GL1zdA> Do you know if there is any means of automating on OS startup the setting of the desired chipset register?

You should use WPCRSET instead to automatically apply settings at startup. AFAIK earlier versions of WPCREDIT contained also WPCRSET but later versions not. Anyway since it's not easy to find WPCRSET anymore I have attached my WPCRSET+ WPCREDIT combo that I found.

Unfortunately no. I would look at the setpci port for Windows https://eternallybored.org/misc/pciutils/ , but I don't know whether it works on old version of Windows.

EDIT: I have forgotten about WPCRSET. This should work best.

Being in self-isolation I had some time for experiments. I've re-done EDO vs FPM benchmark on my 430HX board.

The actual improvement of EDO is a little bit less than I remember it. More like +3% in Quake framerate. The +5% was in cache-less system where the difference in RAM latency is magnified. And +16% in raw read transfer speed in Speedsys/Cachechk.

Interesting fact is that when compared at the same timing x-3-3-3 or x-4-4-4 the FPM appears to be indeed consistently a hair faster than EDO. No idea why.

Obviously the EDO, unlike FPM, can do x-2-2-2 bursts and win everything back, but still interesting.

Thanks for the information. I will look into WPCRSET shortly. Is there a program which does the same but in DOS? Seems that Tweak BIOS needs the registered version to automate its task. I've heard that PCISET can do the same for DOS. Anyone have experience with this program? located here, https://www.uwe-sieber.de/util_e.html

EDIT: I'll also test the EDO x222 benefits in Quake to see if it is in line with your 3% gain.

I was able to load WPCRSET as a device and it appears to work properly to set the EDO read timings to x222 in NT4 and W2K.

I was also able to use PCISET to set x222 in DOS via the autoexec.bat file. The command I used was: PCISET 1250 8086 58 01100000 01000000

8086 is the Vendor ID and 1250 is the Device ID for the i430HX DRAM/cache controller chipset. 58 is the register address in HEX. 01100000 is the mask, whereby the 1's say which bits you want to alter (bits 5 & 6 only), while 01000000 is the value you want them set bits 5 & 6 to, the rest of the bits here are ignored.

So far all 3 OSes have been able to run GLQuake, which is all I have tested so far.

I compared Quake shareware v1.06 in DOS as well. Over an average of 3 tests each, with x333 EDO I get 50.067 fps, and with x222 EDO I get 51.23 fps. This yields a 2.3% boost in performance which is inline with your results. Thanks to everyone for their help here!