Joseph_Joestar wrote on 2024-06-27, 11:49:

Right now, I am hearing the card's fan wind up during gameplay, and getting quieter as soon as I quit to the desktop. But I'm guessing that's not what you meant.

If that's the case, then it most likely works properly in WinME (which would be strange, since it's the same driver).

In my case, I have a dual-boot system with Win98/WinXP and in WinXP the behavior is the one that you describe, with the fan getting quiet when being idle, on the desktop (with Catalyst 7.11).
However, in Win98 the fan always runs at close to full speed, and the memory ICs get extremely hot to the touch (50 - 60+ degrees C) even when doing nothing.

bloodem wrote on 2024-06-27, 12:29:

If that's the case, then it most likely works properly in WinME (which would be strange, since it's the same driver).

To be precise, I'm using WinME with this Security Update CD installed, though I doubt that would make much difference.

And yeah, I'm also dual booting with WinXP using Catalyst 7.11, but the behavior of my card is the same on each OS. Possibly a platform specific issue?

Joseph_Joestar wrote on 2024-06-27, 12:40:

Possibly a platform specific issue?

Yes, this is also a possibility. Will need to dig deeper. 😀

I have just installed a Voodoo2 SLI System im my C2D testbed. Seems to work OK.

I just wonder if a GF4 4200ti (in my case) is able to run a glide wrapper instead?
And if so, which is the best wrapper choice today?

ux-3 wrote on 2024-06-29, 06:11:

I have just installed a Voodoo2 SLI System im my C2D testbed. Seems to work OK.

I just wonder if a GF4 4200ti (in my case) is able to run a glide wrapper instead?
And if so, which is the best wrapper choice today?

I don't use Glide wrappers since I have a dedicated Voodoo 3 retro system.

But from what I gather, it's possible to use certain versions of nGlide with retro hardware. I think it may need a DX9 capable GPU for optimal performance though. Someone else will have to fill in the details, as I have no personal experience with this.

Fantastic build! thanks for linking me to this 😁 now to delve into my favourite numbers 😁 haha

ux-3 wrote on 2024-06-29, 06:11:

I have just installed a Voodoo2 SLI System im my C2D testbed. Seems to work OK.

I just wonder if a GF4 4200ti (in my case) is able to run a glide wrapper instead?
And if so, which is the best wrapper choice today?

i though nGlide was software based and not dependant on GPU, just checked and looks like Joestars right you need a GPU that supports Direct X 9, or Vulkan 1.0, i use nGlide on an FX5200 128MB 64bit with a single core 775 CPU, and it works fine, so you dont need a powerful GPU just a DX9 one.

This reminds me of a build I did on my testbench. I used a Xeon quad core socket 771 processor and a PCIe x850 XT PE. I will have to set it up again to compare benchmarks.

Just picked up an AMD R7 250 for 12 EUR from my local classifieds, and I temporarily put it into this system for testing purposes. This is mostly for the sake of curiosity, as I wanted to see how AMD cards compare to their Nvidia counterparts in terms of supported features. This particular card has VGA, DVI-D and HDMI connections. During my tests, I was deliberately using HDMI, but I ran into a few issues with that. At first, the card wouldn't display anything over HDMI, just giving a black screen, while VGA and DVI worked fine. I thought the port might be dead, but nope, turns out I just needed to use an older HDMI 1.4 compliant cable. For some reason, this card doesn't like my newer HDMI 2.0 cable.

For the drivers, I'm using Catalyst 14.4 pack 2 which are still available from AMD's website. This pack seemed to install ok, but the main GPU driver was missing after the installation process was finished. I had to install that manually via Device Manager. Oddly enough, this initially detected the card as an "Radeon HD 8800M Series" but I manually changed that to "R7 200 Series". Not sure if there's any meaningful difference between the two. In any case, here's what GPU-Z says about this card:

Next up, I fired up the driver panel and wanted to check the image scaling options. And just as I had heard, these work correctly on AMD cards under WinXP, even when using a HDMI connection. This is in contrast to Nvidia cards, where this functionality either needs (much) older drivers or a plain DVI to DVI connection.

Then, I checked the black level settings, and was pleased to see that you can select between Full and Limited RGB straight from the driver panel:

This is another thing that Nvidia cards lack under WinXP, and you need to use third-party tools to toggle it. I haven't tested all the other driver options thoroughly at this time, but there's certainly some interesting stuff in there. This is my first AMD card (I have some ATi branded ones) so I wasn't sure what to expect.

P.S.

Table fog works on this card with Catalyst 14.4 drivers. However, due to the lack of 16-bit dithering, it has that ugly color banding in Thief 2, same as Nvidia cards. The difference being, on this card table fog works even under Win7, which isn't the case with my GTX 970 for example. One thing that kinda disappointed me was that Integer Scaling isn't available on the R7 250 under Win7. Apparently, that option needs GCN2 hardware.

I had no issues with hardware id shenanigans on Catalyst 13.x

The Serpent Rider wrote on 2024-10-29, 19:47:

I had no issues with hardware id shenanigans on Catalyst 13.x

I just did a clean install of WinXP with Catalyst 13.12 and got the same result. The card wasn't recognized, but this time, even the Catalyst Control Center didn't install. Fortunately, I was able to install both the driver and the CCC manually and then everything worked fine. Also, the BIOS of this particular card is from 2015, so it's possible that it's using some weird hardware ID that AMD's WinXP drivers can't pick up automatically. I will say, this driver version seems a bit more stable on my system. Previously, I had random crashes in 3DMark 2001 with Catalyst 14.4 but not anymore with 13.12.

On an unrelated note, HDMI audio works fine on this card, no special tweaks or adjustments needed. IIRC, that's another thing that can be flaky on Nvidia cards under WinXP. At least, I was never able to get it working on my GTX 970.

I just finished benchmarking the R7 250 in this system. Here are the results:

For the 3DMark tests, the default benchmarks were used. For the game tests, the following benchmarks were used:

• FarCry v1.4 benchmarked using the "HardwareOC FarCry Benchmark" at the "Ultra Detail" preset
• Doom 3 v1.31 benchmarked at the "Ultra Quality" preset using the built-in "timedemo demo1 usecache" console command
• Splinter Cell: Chaos Theory v1.05 benchmarked using the stock "Timedemo.bat" file. VSync and Anti Aliasing are turned off, all other settings have been fully maxed out
• Crysis (GOG version) benchmarked using the stock "Benchmark_GPU.bat" file at the "High" graphical settings

I think the card is CPU bottlenecked in some of these games, but once you get to the newer titles, performance drops off noticeably at higher resolutions. Still, not a bad showing for such a cheap GPU. As long as you don't go too crazy with AA, it should be fine for a budget WinXP build.

P.S.

I discovered the cause of the crashes in 3DMark. It wasn't (just) the drivers, turns out the card needed a bit more voltage than this particular motherboard could deliver by default. Fortunately, there's a setting in the BIOS which allowed me to increase the voltage of the PCIe slot by a tiny bit, and that did the trick. Also, I took a photo of the GPU die while changing the thermal paste. Here's what it looks like:

While testing the R7 250, I noticed an odd issue with the Audigy 2 ZS. Doom 3 patched to 1.31 wouldn't recognize the sound card, and refused to enable EAX 4.0. I tried updating OpenAL and even installing EAX Unified, but nothing helped.

On a hunch, I removed DanielK's drivers and used the stock WDM drivers from the official Audigy 2 ZS installation CD. With those, EAX 4.0 in Doom 3 worked like a charm. No other changes were made to the system, so I'm guessing there might be some sort of incompatibility between Doom 3 and DanielK's Audigy drivers, at least on this particular platform.

EDIT - found the root cause, see below.

Turns out my mistake was installing the Audigy sound card drivers before the AMD graphics card drivers. Why would that even matter? Well, I'm not really sure, but somehow he HDMI audio of the R7 250 got into a conflict with the Audigy driver, and it prevented EAX from being detected. The solution was only install the Audigy drivers *after* installing the R7 250 drivers. Posting this here in case someone else runs into the same issue.

Joseph_Joestar wrote on 2024-11-02, 09:03:

On a hunch, I removed DanielK's drivers and used the stock WDM drivers from the official Audigy 2 ZS installation CD. With those, EAX 4.0 in Doom 3 worked like a charm. No other changes were made to the system, so I'm guessing there might be some sort of incompatibility between Doom 3 and DanielK's Audigy drivers, at least on this particular platform. Posting this here in case someone else runs into the same issue.

I’m not really a fan of DanielK’s drivers. Every time I install them, no matter what PC, I always get the slow XP shutdown bug. I’ve gone back to just using the standard Creative drivers.

zuldan wrote on 2024-11-02, 11:01:

I’m not really a fan of DanielK’s drivers. Every time I install them, no matter what PC, I always get the slow XP shutdown bug. I’ve gone back to just using the standard Creative drivers.

I've heard of that, but haven't experienced it myself, at least on the systems that I currently use.

Though in this particular case, the true culprit was AMD's HDMI audio driver for the R7 250. I've edited my previous post to reflect this.

Joseph_Joestar wrote on 2024-11-02, 09:03:

Turns out my mistake was installing the Audigy sound card drivers before the AMD graphics card drivers. Why would that even matter? Well, I'm not really sure, but somehow he HDMI audio of the R7 250 got into a conflict with the Audigy driver, and it prevented EAX from being detected. The solution was only install the Audigy drivers *after* installing the R7 250 drivers. Posting this here in case someone else runs into the same issue.

Heh, when I still had Sound Blaster Z it sometimes stopped working while updating NVIDIA HDMI audio drivers, happened enough times I actually started reinstalling Creative drivers every time I updated NVIDIA drivers expecting them to crap out. I wonder what is up with that if there's issues like that with AMD HDMI audio too.

After thoroughly testing the R7 250, I removed it from this build, put it in storage, and reinstalled the X800 GTO. However, the system would now hang at the boot screen while detecting IDE devices. I had used a separate SSD while testing the R7 250 as I didn't want to alter my existing installations of WinME and WinXP. The other drives were unpowered and disconnected during these tests, so there was little to no chance that they went bad.

After *way* too much troubleshooting, I narrowed it down to the SATA cable. Turns out it's one of those that have a metallic latch which (flimsily) locks the cable into place once it's connected. Well, I may have accidentally pulled it out without releasing the latch, and this apparently damaged the cable. Replacing that cable with a new one solved the problem, but it made me think, why build cables with those crappy latches at all? The latch was obviously too weak if I was able to remove the cable without releasing it first, with minimal effort.

Anyhow, this concludes my daily rent about working with retro hardware. I guess the lesson I learned today is that I need a dedicated test system, rather than temporarily using one of my existing builds for testing newly acquired components.

I want to say those sata cables were designed for esata but I'd have to verify.

DosFreak wrote on 2024-11-04, 11:10:

I want to say those sata cables were designed for esata but I'd have to verify.

It's possible. I think it just said "SATA III cable" on the packaging, but who knows.

All I know is that I'm not buying those anymore.

Joseph_Joestar wrote on 2024-11-04, 11:01:

I guess the lesson I learned today is that I need a dedicated test system, rather than temporarily using one of my existing builds for testing newly acquired components.

Part of the problem is that if you are covering a wide period of time then no single system would be a suitable base for experimentation. You'd need several base platforms.

But, yes, I too have learned that swapping parts in your main builds is asking for trouble. In my situation it was rather tempting, as most of mine aren't in PC cases currently. I have 5 open test bench platforms. The urge to swap parts is strong. Haha. Once I have my permanent builds in cases though, I plan to set up these test benches in the same eras as my PCs so I can swap parts in those without affecting the ones I spent ages getting configured how I want.