AlexZ wrote on 2022-08-21, 19:30:

he old BIOS has to be configuring something differently

Unless there is a hidden CMOS setup value only accessible with third party utilities or BIOS rom mod which I find unlikely because the beta BIOS probably has everything exposed.
I did a CMOS jumper reset prior to flashing the beta so probably there shouldn't be any unwanted settings otherwise the CMOS checksum warning would be persistent.

Bruno128 wrote on 2022-08-21, 18:49:

I am using a modest FX5200 AGP in that motherboard with 3.19a BIOS and am also experiencing this issue. While one way to look at it is there is hardly any game explicitly requiring Win98 to run and pushing the AGP card to the max and one could just boot to XP for more demanding stuff... Though the persistence of the issue and the evident benchmark results demonstrate there is without a doubt a significant AGP performance drop irregardless with either FX5200 or FX5900 Ultra.
While I know that sounds weird but has anyone managed to narrow the issue to the newer BIOS specifically? Are we looking in the right place? Or is that a coincidence and is somehow related to RAM amount / Core2Duo cpu used in beta BIOS systems? (the main reason to go beta I presume)

If Joseph_Joestar wants to test every BIOS to find the one that introduces the bug we could. Asus's patch notes are a little spartan though. ASRock's are better, but I have a Wolfdale CPU and can't downgrade past 2.10. If I had a the first revision of the motherboard and an older CPU I could test every BIOS release to see what the offending patch was. I suspect it's the CPU microcode update though.

I've tried looking for other connections to see if there could be any other hardware or software configuration that's causing this. But regardless of the amount of RAM or VRAM, single or multicore, AMD or Intel processor, ATI or NVidia GPU, or motherboard manufacture, anyone that reports the issue has this in common: a K8M800 or PT880 chipset and any version of Windows below XP (NT 5.1). I've searched the internet far and wide for this specific issue and that's the only thing they all have in common.

AlexZ wrote on 2022-08-21, 19:30:

That microcode suggestion is just a speculation, like other possible causes. I suspect changed chipset settings that confuse VIA AGP driver and cause it to work in a crippled mode.

It would be great if you or someone else who can reproduce the issue provided a dump of wpcredit chipset settings when BIOS configuration is exactly the same (e.g after loading optimal settings) - for both cases. The old BIOS has to be configuring something differently. Another option would be debugging the VIA AGP driver, however that's a lot more challenging.

I've compared Joseph_Joestar's working example registry dumps with mine and they are being configured correctly. I went over every register and compared it with Intel's AGP 3.0 documentation, and VIA's chipset documentation, and everything on my chipset is being configured correctly by the AGP driver. VIA's 98/ME AGP driver, VIAGART.sys, I've confirmed has debugging symbols. I have a USB-DB9 cable and I plan to try and run a kernal debugger to see what's going on under 98's hood. Lately, I haven't had the free time to do this though.

Spoiler

Joseph_Joestar wrote on 2022-08-21, 19:47:

I also briefly used an ATi Radeon 9550 with Catalyst 6.2 and it exhibited the same performance issues.

Thank you, that striking out NV forceware as a possibility.
I'm looking at K8V-X AMIBIOS version history and it covers a time period lasting from May 2004 t/m October 2005. Something makes me speculate it has to do with UAGP v.3.5. standard introducing a number of GART-related registers.

Bruno128 wrote on 2022-08-21, 19:56:

Thank you, that striking out NV forceware as a possibility.
I'm looking at K8V-X AMIBIOS version history and it covers a time period lasting from May 2004 t/m October 2005. Something makes me speculate it has to do with UAGP v.3.5. standard introducing a number of GART-related registers.

I've tried vanilla 2001 XP, released before UAGP 3.5 was implemented, and the bug is not present.

VDNKh wrote on 2022-08-21, 19:51:

I suspect it's the CPU microcode update though.

An interesting thought and could be potentially tested by creating a monstrosity of a beta BIOS fork mod with the backported microcode part in AMI MMTool from the original BIOS rom while keeping the rest of the blocks. Alas,.. it wouldn't explain the same issue occurring on an entirely different AMD architecture...

VDNKh wrote on 2022-08-21, 19:51:

If Joseph_Joestar wants to test every BIOS to find the one that introduces the bug we could.

Nah, I'm good.

Best I can do is give you guys screenshots of my BIOS settings so you can compare, if you think that would help.

VDNKh wrote on 2022-08-21, 20:02:

I've tried vanilla 2001 XP, released before UAGP 3.5 was implemented, and the bug is not present.

While a reasonable thing to test, I'd say that still doesn't entirely strike out the possibility though. It's still WinNT 5.x being a world away from 9x.
Everyone experiencing the issue is likely using a v.5.24A or similar Hyperion Pro driver package released well into the 00's and possibly implementing some of the newer unwanted stuff?
May we be looking at the combination of UAGP v.3.5. BIOS implementation plus new VIA AGP driver in 9x environment?
Have you ever tried beta BIOS in conjunction with older viaaagp versions in w98?

VDNKh wrote on 2022-08-21, 19:51:

I've compared Joseph_Joestar's working example registry dumps with mine and they are being configured correctly. I went over every register and compared it with Intel's AGP 3.0 documentation, and VIA's chipset documentation, and everything on my chipset is being configured correctly by the AGP driver. VIA's 98/ME AGP driver, VIAGART.sys, I've confirmed has debugging symbols. I have a USB-DB9 cable and I plan to try and run a kernal debugger to see what's going on under 98's hood. Lately, I haven't had the free time to do this though.

Spoiler

gartmap.PNG

That looks very good. I would basically set a debug point in every function and see what gets called when 3D Mark 2001 tries to detect AGP memory size. That 0 has to come from somewhere. It would be hopeless without debugging symbols. Fixing this problem will very likely require a driver patch, even if it means a hack. It could be something as trivial as that AGPEnable function simply failing and cascading to all issues we experience.

As far as CPU compatibility is concerned, I would get a Sempron, every BIOS should be compatible with that. It would be worth checking if you get AGP driver to work correctly using the oldest BIOS. Downgrading BIOS to 7032v11 had no effect on my MSI K8T Neo V (pity as that board seems to be common and can be found often in good state). I bought a few spare socket 754 boards they came with Semprons. Being able to compare execution paths would significantly improve the chance of finding a fix for this.

I don't have my build by me atm to try it but I am including an older VXD AGP driver picked from HyperionPro v.4.56 for those who can do some win98 testing on a downgraded version while running newer BIOS.

Joseph_Joestar wrote on 2022-08-21, 20:12:

Nah, I'm good.

Best I can do is give you guys screenshots of my BIOS settings so you can compare, if you think that would help.

Understandable. Myself and others on Vogons have tried every BIOS setting available, the issue is outside of BIOS settings as far as I'm concerned.

Bruno128 wrote on 2022-08-21, 20:12:

While a reasonable thing to test, I'd say that still doesn't entirely strike out the possibility though. It's still WinNT 5.x be […]
Show full quote

While a reasonable thing to test, I'd say that still doesn't entirely strike out the possibility though. It's still WinNT 5.x being a world away from 9x.
Everyone experiencing the issue is likely using a v.5.24A or similar Hyperion Pro driver package released well into the 00's and possibly implementing some of the newer unwanted stuff?
May we be looking at the combination of UAGP v.3.5. BIOS implementation plus new VIA AGP driver in 9x environment?
Have you ever tried beta BIOS in conjunction with older viaaagp versions in w98?

Bruno128 wrote on 2022-08-21, 20:27:

I don't have my build by me atm to try it but I am including an older VXD AGP driver picked from HyperionPro v.4.56 for those who can do some win98 testing on a downgraded version while running newer BIOS.

The issue even exists in Windows 2000 (NT 5.0). Considering that this AGP implementation does work on old BIOSs, I don't think UAGP 3.5 is the issue, at least not directly.

Others here on Vogons have also tested multiple versions of the chipset driver. I've tried several different ones myself, including the Windows 95 VxD version of the AGP driver. All experience the same issue.

AlexZ wrote on 2022-08-21, 20:16:

That looks very good. I would basically set a debug point in every function and see what gets called when 3D Mark 2001 tries to detect AGP memory size. That 0 has to come from somewhere. It would be hopeless without debugging symbols. Fixing this problem will very likely require a driver patch, even if it means a hack. It could be something as trivial as that AGPEnable function simply failing and cascading to all issues we experience.

As far as CPU compatibility is concerned, I would get a Sempron, every BIOS should be compatible with that. It would be worth checking if you get AGP driver to work correctly using the oldest BIOS. Downgrading BIOS to 7032v11 had no effect on my MSI K8T Neo V (pity as that board seems to be common and can be found often in good state). I bought a few spare socket 754 boards they came with Semprons. Being able to compare execution paths would significantly improve the chance of finding a fix for this.

I actually have a Kentsfield Q6600 that works on all BIOS versions. If it comes to it I will install and test it. I have the R2.0 version of the 4CoreDual-SATA2 board though so I can't safely flash my BIOS back to the earliest version. I can flash it back before the microcode update though.

I've thoroughly investigated this problem in the past and I can say at least two things with a fair degree of certainty:
- the issue is without a doubt related to the BIOS, but it's NOT related to normal BIOS settings that one can find in the CMOS setup (whatever it is, it's something more low level). It might be related to other hidden chipset registers, but I have my doubts - it seems to go deeper than that.
- the problem was introduced sometime in early to mid 2005 (I have yet to see a motherboard with a BIOS from 2004 that has this problem), and it's not specific to only one vendor, so I suspect that it's a code block that originates from VIA itself)

Unfortunately, some newer motherboards (such as the Asus K8V-X SE) exhibit this problem with all official BIOS versions (since even the earliest BIOS revision is from mid 2005).
My "solution" in this case was to simply try BIOS versions from earlier (similar) motherboards that do have 2004 BIOS revisions (the Asus K8V-X, in this case) and this actually worked surprisingly well.

Now, here comes the kicker: I have (what appeared to be) two identical K8V-X SE motherboards - same revision and all. However, only one of them worked with the old K8V-X BIOS versions, the other failed to POST after the BIOS update (froze at a memory related post code). So I took off the north bridge heatsinks, and lo and behold, even though both motherboards look identical, their north bridges certainly are not (the North bridge with the round, grey metalic area appears to be a newer revision).

Funnily enough, the one that failed to work with the vanilla K8V-X BIOS, did work just fine with the... (drum roll)... Asus A8V BIOS (which is actually a very different socket 939 motherboard that has the VIA K8T800 PRO chipset). The only issues I could see was a warning message during POST that the "BIOS is not valid for this motherboard", and incorrect/broken readings from the temperature/voltage sensors in the BIOS itself (in Windows they are read correctly by software such as AIDA64). Other than that, the board worked perfectly during many days of testing (and, of course, the Win98 performance issues were gone).

WARNING: don't try this at home, unless you understand the risks (including the fact that you will most likely need an external BIOS flasher, since things will certainly go wrong during the trial and error phase).

My MSI K8T-Neo V has yet another revision:

K8T800
0534CD
2GB1014731

AlexZ wrote on 2022-08-22, 16:45:

0534CD

I think this is probably the date code. Meaning, year 2005 week 34. No idea what the CD is though. Maybe the name of the factory?

On the other hand, the chip with the silver circle that @bloodem posted has a date code of 0453 meaning year 2004 week 53. This seems to fit as 2004 was one of those less common years which actually have 53 weeks, instead of the usual 52.

Joseph_Joestar wrote on 2022-08-22, 17:10:

I think this is probably the date code. Meaning, year 2005 week 34. No idea what the CD is though. Maybe the name of the factory?

On the other hand, the chip with the silver circle that @bloodem posted has a date code of 0453 meaning year 2004 week 53. This seems to fit as 2004 was one of those less common years which actually have 53 weeks, instead of the usual 52.

Now that you mention it, it does make sense. This means that the north bridge with the round/grey metallic area is actually manufactured earlier (and this is probably the reason why it does work with the BIOS from the older K8V-X motherboard).

Another thing that I found interesting: even though I've flashed the "Asus K8V-X version 1006 BIOS" (from December 22nd, 2004) on this K8V-X SE motherboard (the one with the 0453 date code on the north bridge), Athlon 64 "Venice" CPUs do work perfectly fine - although Asus mentions that they should only be supported by the latest ver 1012 BIOS (obviously, since Venice CPUs were not yet available in late 2004).
And this is great, since I do prefer to use Venice CPUs (unless going for a very period correct build), because these run much cooler than the earlier 130 nm models (ClawHammer/Newcastle).

Just a hint ... Venices (and s754 in general) work great with modern AMD Wraith coolers. AM3+ version with no bling in pics.

stef80 wrote on 2022-08-23, 06:55:

Just a hint ... Venices (and s754 in general) work great with modern AMD Wraith coolers. AM3+ version with no bling in pics.

I think all modern AM4 (AM5) coolers work fine for socket 754/939.
My personal favorite are the Deepcool GAMMAXX 300 and its little brother: Deepcool Iceedge Mini FS v2.0 (pictured below).
These are cheap, dead silent and keep the CPU nice and cool, even when overclocking.

VDNKh wrote on 2022-08-21, 20:40:

Others here on Vogons have also tested multiple versions of the chipset driver. I've tried several different ones myself, including the Windows 95 VxD version of the AGP driver. All experience the same issue.

All those versions are broken as VIA probably never discovered the issue. But since AGP works normally in Windows XP we can be sure that it is fully functional, including AGP memory. It just needs to be initialized properly. I believe comparing VIA AGP driver behavior between BIOSes to be absolutely essential to find out what call behaves abnormally. It could well be happening during Windows boot. Perhaps AGP initialization fails that early. It may also be necessary to compare how Windows XP AGP driver does it.

AlexZ wrote on 2022-08-23, 15:48:

VDNKh wrote on 2022-08-21, 20:40:

Others here on Vogons have also tested multiple versions of the chipset driver. I've tried several different ones myself, including the Windows 95 VxD version of the AGP driver. All experience the same issue.

All those versions are broken as VIA probably never discovered the issue. But since AGP works normally in Windows XP we can be sure that it is fully functional, including AGP memory. It just needs to be initialized properly. I believe comparing VIA AGP driver behavior between BIOSes to be absolutely essential to find out what call behaves abnormally. It could well be happening during Windows boot. Perhaps AGP initialization fails that early. It may also be necessary to compare how Windows XP AGP driver does it.

Agreed, also need someone to inspect and compare the 98 and XP drivers. Ditto to firmware that made this working using different firmware, extract that details and fix the correct firmware?

But what about other motherboards that also use K8T800 has the issue too or not? My intended use for K8T800 motherboard (this is Fujitsu Siemens FSC D1607-A11 motherboard) is for windows 98SE. Metal top northbridge.

Cheers,

AlexZ wrote on 2022-08-23, 15:48:

VDNKh wrote on 2022-08-21, 20:40:

Others here on Vogons have also tested multiple versions of the chipset driver. I've tried several different ones myself, including the Windows 95 VxD version of the AGP driver. All experience the same issue.

All those versions are broken as VIA probably never discovered the issue. But since AGP works normally in Windows XP we can be sure that it is fully functional, including AGP memory. It just needs to be initialized properly. I believe comparing VIA AGP driver behavior between BIOSes to be absolutely essential to find out what call behaves abnormally. It could well be happening during Windows boot. Perhaps AGP initialization fails that early. It may also be necessary to compare how Windows XP AGP driver does it.

It depends. When I was experimenting with editing the AGP Target registers, sometimes changing a value would cause 98 to not boot. Other times it would only hang when trying to poll the graphics driver for information, such as opening the Nvidia control panel or opening 3DMark.

My guess is the GART issue is at boot since the GARTLO register is programmed then, Windows allocates virtual memory to it then too. 98 also throws a resource conflict on a fresh install on the AGP Target device. It's easily correctable by manually changing it, but 98's memory manger might be part of the issue.

Maybe Joseph_Joestar can load a clean install of 98 on his working system and see if it's still creating a conflict?

VDNKh wrote on 2022-08-24, 01:10:

My guess is the GART issue is at boot since the GARTLO register is programmed then, Windows allocates virtual
memory to it then too. 98 also throws a resource conflict on a fresh install on the AGP Target device. It's easily correctable by manually changing it, but 98's memory manger might be part of the issue.

Maybe Joseph_Joestar can load a clean install of 98 on his working system and see if it's still creating a conflict?

I'm not sure I follow.

If I was to do a clean install of Win98SE (with no chipset or GPU drivers) I would see a resource conflict in Device Manager? On which device specifically?