red-ray wrote:

Thank you for running the tests and generating the files. These confirm that the issue is the PCI Command register being 0x0002 rather than 0x0003 is the root cause of the issue. Is there any reason for having the Rage as the primary VGA device?

If I set the Voodoo as primary, I can't enable dual-head mode & span the desktop, because I get an error that the frame buffer address space conflicts between the two cards & can't be remapped. With the Rage as primary it works fine. Someone mentioned in my other thread that some Rage cards have a jumper that allow them to be used as a secondary card, but this one doesn't. Anyway that's the only reason I'm using the Rage as primary in this system; it was really just an experiment to see if it would work.

red-ray wrote:

I could get SIV to enable I/O Access, but feel I should have a think about this before making any changes, epically so as I plan to release SIV 5.42 tomorrow. I suspect it would be wise to wait 'till you have figured out why your get the 125 MHz rather than a 143 MHz clock first, what do you think?

BTW for the 3dfx the RAMDAC Clock is the current clock so if you change the display resolution this should change.

red-ray wrote:

Why is the speed 166 MHz rather then 143 MHz, is this 3000 vs. 2000 please?

AFAIK it's supposed to be: Voodoo3 1000 (just a few OEM versions) = 125MHz, V3 2000 = 143MHz, 3000 = 166MHz, and 3500 = 183MHz, but obviously I've found a mutant card that identifies itself as a 2000 but still runs at 125MHz. The clock speed is the only major difference between the cards from the 2000 and up. (Some '1000' implimentations only had 8MB RAM and one TMU disabled.)

I'm pretty sure my card really is running at 125MHz, because that would bear out some benchmark results I got where it's slower than the K6-2 system despite the P3 itself being a significantly faster CPU.

red-ray wrote:

This comes down to what AMD did, the PCI Device ID is made up of a Vendor ID + Device ID, ATI was vendor 1002 and AMD is vendor […]
Show full quote

xjas wrote:

(One thing that's bugging me a little is the reporting of ATI cards as AMD cards

This comes down to what AMD did, the PCI Device ID is made up of a Vendor ID + Device ID, ATI was vendor 1002 and AMD is vendor 1022, but AMD now use 1002 for such as my AMD Radeon RX 5700 which has an ID of 1002-731F. Clearly it should be reported as AMD so to do what you would like I would need to know which Vendor 1002 Device IDs were ATI. This would be possible, but I feel the effort needed would be excessive just to say ATI rather than AMD. Looking on my Matisse system the Device IDs for RX 5700 are not even adjacent.

Copy code to clipboard

1[ 10 - 00 - 0 ]  4    1002-1478-00000000-C4   PCI Bridge (10-11:12) x8@4 (x16@4)  AMD Radeon Navi PCIe Switch Upstream Port
2[ 11 - 00 - 0 ]  4    1002-1479-00000000-00   PCI Bridge (11-12) x16@4 (x16@4)    AMD Radeon Navi PCIe Switch Downstream Port
3[ 12 - 00 - 0 ]       1002-731F-0B361002-C4   VGA Controller x16@4 (x16@4)        AMD Radeon RX 5700 [GPU-1]
4[ 12 - 00 - 1 ]  51   1002-AB38-AB381002-00   High Def Audio x16@4 (x16@4)        AMD Radeon Navi 10 HDMI Audio

I was afraid that was the case... If it leads to some horrible GPU-by-GPU checks and spaghetti code, it's not worth doing, IMHO. Maybe others feel more strongly about it than I do. I just like seeing ATI's good old red logo where it's appropriate. 😉

xjas wrote:

If I set the Voodoo as primary, I can't enable dual-head mode & span the desktop, because I get an error that the frame buffer address space conflicts between the two cards & can't be remapped. With the Rage as primary it works fine.

Thank you for all the information and sorry for my delay in replying as I have been busy with the SIV 5.42 release today.

I half suspected the Rage needed to be the primary for it to work. I have pondered the I/O Access and adjusted SIV, please will you try the attached SIV32L 5.43 Rage-00 with the Rage as the primary and see what get's reported as the Voodoo 3 clocks.

Just drop the new files over the previous ones as the kit only includes the changed files.

After mentioning the I/O Access effect to Martin I suspect HWiNFO may also fail to report the Voodoo 3 clocks when the Rage in primary, does it? If so I suspect it will if you first run SIV and SIV enables I/O Access as it should.

Edit: I checked on my Windows 2003 R2 system with a Voodoo 3, my suspicions about HWiNFO were correct and it reported 7.1 MHz clocks 'till I ran SIV which enabled I/O Access.

For ATI then yes, it would spaghetti code, but I guess I could cleanly use the ATI Rage logo for Rage GPUs as AFAIK there are no AMD Rage GPUs, do you know of any?

Edit: If you use the SIV-5.43-Savege-00.zip I just posted you should get ATI logos for Rage GPUs.

Okay so I installed Win2k on the Omnibook, thankfully I've somehow found the drivers for it, right now it's still installing the drivers as I'm posting this message.

Vynix wrote:

right now it's still installing the drivers as I'm posting this message.

Great and I hope they all go in OK. With W2K SIV should get the multiplier correct as it changes, report the disk SMART data, the DIMM SPD information and in general do rather better.

I have made a number of improvements for S3 GPUs and the attached SIV 5.43 Savage-00 should do rather better. I tested the S3 Trio64V2 improvements on my card and it's also got S3 Savage 4 support, but this is as yet untested.

It's going fine so far (I had to wipe the hard drive, split it in two ~10GB partitions, reinstall W98 and finally install Win2k).

Right now it's still busy installing the drivers, it has rebooted as I'm writing this.

Looks like it's hanging on section 221 (CPU TIMER) 😐

Edit: yup even with CPU-TIMER unticked SIV froze entirely then the whole system hardlocked, so I had to unplug the laptop to turn it off

Vynix wrote:

Looks like it's hanging on section 221 (CPU TIMER) 😐

Oops, sorry about this and I hope the system came back OK. I am trying to think what could have caused this as I don't recall this ever happening before with [cpu-timer]. My best guess if that there is something strange about the HPET, but to tell more I would need the save files. The one from 98 does not contain the information I need to check.

Is there a BIOS option to disable the HPET? What does Menu->Hardware->BIOS Tables->BIOS Tables report?

I guess SIV started OK, if you do Menu->File->Save Selected and uncheck [cpu-timer] before pressing [Start] does that complete OK? Please will you post both the .DMI + .TXT so I can see how far SIV got.

Hrm well after the hardlock Win2k wouldn't boot afterwards (it would freeze at the login prompt) thankfully I could still access Win98...

So yeah I would up reinstalling Win2k (turned out that my previous install was bad...), that's the first time that this happened.

Before the full hardlock I had tried to untick CPU-timer but this is where things went downhill.

As for the HPET thing, I have no idea what this thing is, and there isn't any option related to HPET in the BIOS as far as I know.

Aye, looks like it worked this time, I have no idea why. Maybe it has to do that I didn't had any update installed with the first Win2k install (the one that hardlocked to death 😵), while this second one has all the patches that I could find installed.

Vynix wrote:

Hrm well after the hardlock Win2k wouldn't boot afterwards (it would freeze at the login prompt) thankfully I could still access Win98...

As for the HPET thing, I have no idea what this thing is, and there isn't any option related to HPET in the BIOS as far as I know.

If it's freezing at the login prompt maybe the installation had issues caused by one of the drivers you installed.

Thinking about the HPET I don't think your system will have it as I just checked a Pentium 4 and it does not.

If you do reinstall I would be inclined to make the W2K partition FAT32 rather than NTFS to that the W98 system can access it. Also make sure it's in the extended partition rather than a second primary partition I have seen issues caused by W98 getting confused when there are multiple primary partitions on a drive.

Vynix wrote:

Aye, looks like it worked this time, I have no idea why. Maybe it has to do that I didn't had any update installed with the first Win2k install (the one that hardlocked to death 😵), while this second one has all the patches that I could find installed.

Good and I suspect we may never know! I will have a look at the save and see if I can spot anything.

Please will you post D:\Documents and Settings\Administrateur\Bureau\SIV-5[1].43-Savege-00\SIV_OMNIBOOK-2000.dmi? This is the raw data that SIV displays on the [Machine] panel and it runs better in test mode when I have it.

Looking at the SIV screen shot the system is almost 100% busy with most of the time being in Kernel mode. This is good and I would use Windows Task Manager to try and find out the cause of this. With just SIV running on your system I would expect a load of 2 or 3% at most.

Here goes:

Sorry it took me this long! Seems to run fine... in that it doesn't crash, at least. The info all seems to check out the more I look at it, maybe if I had done this earlier I'd have actually been able to help with something. Banshee clocks are reported fine.

This is the .DMI file it made. Not sure how much use this is to you.

Ah the CPU at 100%? That's just the touchpad driver hogging the CPU at the absolute maximum, without it running (if I kill the SynTPEnh process) CPU usage hovers at 5-10% usually... I have no idea why the driver does this (if I don't install it then my touchpad doesn't work, so I'm a bit in a catch-22 situation)

EDIT: Never mind, it seems to go away if I log out and log back in... I've never seen that before, Computers sure have their own mysteries that noone can explain. As for the cause of this, I found that it isn't the Synaptics driver that caused this, but rather, it seems that initially the "System Inactive Process"'s CPU usage will shoot up to 90% and keep rising before dropping down. Weird.

Sedrosken wrote:

This is the .DMI file it made. Not sure how much use this is to you.

Thank you for checking out SIV and posting the save files, it's good to get a post when there were no strange effects 😀 I prefer to have the .DMI as SIV runs better in test mode when it's there, but these days I can manage better than I used to be able to without it as I added code to read the [machine] section from the save file and internally re-create the data it contains that SIV needs to run well in test mode.

I was pleased to see SIV report the 3dfx Voodoo Banshee as this is the first time I have seen it do this. Looking at Menu->Machine->GPU Info there is 16MB which is what Windows reports as memory size as and 8MB which is what SIV read from the card. Clearly they both can't be correct and I suspect the GPU really has 16MB, does it? Have you tried HWiNFO on the system, if so what does it report as the GPU memory size and are the clocks the same?

Edit: I just spotted such as Menu->Help->SIV Lookup did not report the image type and versions. This is down to DBGHELP.dll not being there and if you put the attached into C:\WINNT\system32 then SIV should do better. I suspect you must have put PSAPI.dll V5.00.2134.1 there, did you?

Vynix wrote:

Computers sure have their own mysteries that no one can explain.

Yes, they sure do! I noticed when first installed Windows 2003 x32 Enterprise Terminal Server R2 on my Dual AMD Athlon MP 1900+ (Palomino) TYAN S2466 system I got a similar effect. In the end I tracked this down to Windows Update checking if updates were needed. Once it had installed all the available updates I disabled Windows Update and now, touch wood, the system load at most one or two % almost all of the time.

It does have 16MB. HWiNFO used to work but now seems to crash. Hmm. I'll have to troubleshoot that.

Sedrosken wrote:

It does have 16MB. HWiNFO used to work but now seems to crash. Hmm. I'll have to troubleshoot that.

There is a HWiNFO thread and I suspect if you post the HWiNFO32.dbg file to it Martin will look into what is happening.

Did you spot I edited my earlier post?

Thank you for confirming 16MB, I will now have a look at the Banshee datasheet

red-ray wrote:

Thank you for all the information and sorry for my delay in replying as I have been busy with the SIV 5.42 release today. […]
Show full quote

xjas wrote:

If I set the Voodoo as primary, I can't enable dual-head mode & span the desktop, because I get an error that the frame buffer address space conflicts between the two cards & can't be remapped. With the Rage as primary it works fine.

Thank you for all the information and sorry for my delay in replying as I have been busy with the SIV 5.42 release today.

I half suspected the Rage needed to be the primary for it to work. I have pondered the I/O Access and adjusted SIV, please will you try the attached SIV32L 5.43 Rage-00 with the Rage as the primary and see what get's reported as the Voodoo 3 clocks.

Just drop the new files over the previous ones as the kit only includes the changed files.

After mentioning the I/O Access effect to Martin I suspect HWiNFO may also fail to report the Voodoo 3 clocks when the Rage in primary, does it? If so I suspect it will if you first run SIV and SIV enables I/O Access as it should.

Edit: I checked on my Windows 2003 R2 system with a Voodoo 3, my suspicions about HWiNFO were correct and it reported 7.1 MHz clocks 'till I ran SIV which enabled I/O Access.

Sorry, it took a little longer to get back to this due to some driver issues on the machine (& me not having time to fix them - long story.) Voodoo clocks are being reported correctly in all three configurations of primary/secondary. 😀 Please see attached. (Also I bumped up the resolution to 1152x864 and the RAMDAC speed changed on the Voodoo card, as it should.)

It's still showing "0MB 64-bit SDRAM" for the Rage, but looking pretty good otherwise.

red-ray wrote:

For ATI then yes, it would spaghetti code, but I guess I could cleanly use the ATI Rage logo for Rage GPUs as AFAIK there are no AMD Rage GPUs, do you know of any?

Edit: If you use the SIV-5.43-Savege-00.zip I just posted you should get ATI logos for Rage GPUs.

Nice! Yeah, it's safe to say all Rage-series GPUs are ATI products. Even the relatively recent ES1000 server chip (which is some descendant of the Rage line) is still branded ATI.

Thank you for your excellent testing, I expected it to work as I tested it on my Voodoo 3 2000, but what I could not check is that things would be OK when the VBIOS had not set I/O Enabled in the first place as I can't get my system to post with a PCI primary GPU.

I just need to fix the Voodoo Banshee memory size reading from the chip and then plan to release 5.43 Beta-00 which will include this I/O Access fix. I was expecting I would need to release Beta-00 to support the next Windows 10 20H1 insider build but M$ seem to be running late.

xjas wrote:

It's still showing "0MB 64-bit SDRAM" for the Rage, but looking pretty good otherwise.

The 0MB is down to SIV not having a VXD for Windows 9x and on Windows NT/2K/XP it should get the size correct.

Good luck with sorting out the driver issues.