TASOS

Sorry for messing the thread ... Anyone ever had a FIC AU31-L (mATX , nforce2) ? I recently got one , that has a 400FSB sticker on it , a rev A4 chipset and MCP-T south and had an XP3200+ on it

Very very good result !! That 760G chipset , really makes things easier. I see you don't fear the condensation

Motivated by an other recent post in our forum , i decided to make this "re-post" of an older wordpress blog , about running older 3D Benchmarks with current pc systems that use modern hardware and OS. All credit goes to the author of this blog , (aka scali) https://scalibq.wordpress.com/2020/12/25/running-anything-remedy-futuremark-madonion-ul-in-2020/ Also copy-pasting his post (i hope he doesn't have a problem with this) just in case something gets lost in the future. People with more knowledge , please feel free to contribute in this thread. // Running anything Remedy/Futuremark/MadOnion/UL in 2020 Posted on December 25, 2020 by Scali There has always been a tie between Futuremark and the demoscene. It all started with the benchmark Final Reality, released by Remedy Entertainment in 1997. Remedy Entertainment was a gaming company, founded by demosceners from the legendary Future Crew and other demo groups. Remedy developed an early 3D acceleration benchmark tool for VNU European Labs, known as Final Reality, which showed obvious links to the demoscene, both because of the demo-like design of its parts, the name “Final Reality” being a reference to the Future Crew demo Second Reality, and the fact that a variation of Second Reality’s classic city scene was included in Final Reality. After this first benchmark, a separate company focused on benchmarking was founded, which was to become Futuremark. After releasing 3DMark99, they changed their name to MadOnion.com. Then after releasing 3DMark2001, they changed back to Futuremark Corporation. Eventually, after being acquired in 2018 by UL, they changed the name to UL Benchmarks. With every major milestone of PC hardware and software, generally more or less coinciding with new versions of the DirectX API and/or new generations of hardware, they released a new benchmark to take advantage of the new features, and push it to the extremes. Traditionally, each benchmark also included a demo mode, which added a soundtrack, and generally had extended versions of the test scenes, and a more demo-like storytelling/pacing/syncing to music. As a demoscener, I always loved these demos. They often had beautiful graphics and effects, and great music to boot. But, can you still run them? UL Benchmarks was nice enough to offer all the legacy benchmarks on their website, complete with registration keys: Futuremark Legacy Benchmarks – UL Benchmarks Or well, they put all of them up there, except for Final Reality (perhaps because it was released by Remedy, not by Futuremark/MadOnion). But I already linked that one above. I got all of them to run on my modern system with Windows 10 Pro x64 on it. I’ll give a quick rundown of how I got them running, starting from the newest. 3DMark11, 3DMark Vantage, 3DMark06, 3DMark05 and 3DMark03 all installed and ran out-of-the-box. 3DMark2001SE installed correctly, but the demo would not play. Looking at the error log revealed that it had problems playing back sound (which explains why regular tests would work, they have no sound). But when you select the Compatibility mode for Windows 8, that fixes the sound, and the whole demo runs fine. 3DMark2000 was a bit more difficult. On my laptop it installed correctly, but on my desktop, the installer hung after unpacking. The trick is to go to Task Manager, find the setup.exe process in the Details tab, right-click it and select “Analyze wait chain”. It will tell you what the process is waiting for. In my case it was “nvcontainer.exe”. So I killed all processes by that name, and the setup continued automatically. Now 3DMark2000 was installed properly, but it still did not work correctly. There is a check in there, to see if you have at least 4MB video memory. Apparently on a modern video card with multiple GBs of memory, the check overflows, and thinks you have less than 4MB. It then shows a popup, and immediately closes after you click on it. So I disassembled the code, found the check, and simply patched it out. Now it works fine. If you want to patch it yourself, use a hex editor and change the following bytes in 3DMark2000.exe: Offset 69962h: patch 7Dh to EBh Offset 69979h: patch 7Dh to EBh XL-R8R dates from the same era as 3DMark2000, and I ran into the same issue of setup.exe getting stuck, and having to analyze the wait chain to make it continue. It did not appear to have a check for video memory, so it ran fine after installation. 3DMark99Max was more difficult still. The installer is packaged with a 16-bit version of a WinZip self-extractor. You cannot run 16-bit Windows programs on a 64-bit version of Windows. Luckily you can just extract the files with a program like 7-Zip or WinRar, by just right-clicking on 3DMark99Max.exe and selecting the option to extract it to a folder. From there, you can just run setup.exe, and it should install properly. Like 3DMark2000, there’s also a check in 3DMark99Max that prevents it from running on a modern system. In this case, it tries to check for DirectX 6.1 or higher, and the check somehow mistakenly thinks that the DirectX version is too low on a modern system. Again, a simple case of disassembling, finding the check, and patching it out. If you want to patch it yourself, use a hex editor and change the following byte in 3dmark.exe: Offset 562CCh: patch 75h to EBh Final Reality then, the last one. Like 3DMark99Max, it has a 16-bit installer. However, in this case the trick of extracting it does not help us. You can extract the setup files, but in this case the setup.exe is still 16-bit, so it still cannot run. But not to worry, there are ways around that. Initially I just copied the files from an older installation under a 32-bit Windows XP. But an even better solution is otvdm/winevdm. In short, x86 CPUs can generally only switch between two modes on-the-fly under Windows. So a 32-bit version of Windows can switch between 32-bit and 16-bit environments, which allows a 32-bit version of Windows to run a 16-bit “NTVDM” (NT Virtual DOS Machine) environment, in which it runs DOS and 16-bit Windows programs. For 64-bit versions of Windows, there’s a similar concept, known as Windows-on-Windows (WOW64). This allows you to run 32-bit Windows programs. The original NTVDM for DOS and Win16 programs is no longer available. Otvdm works around this by using software emulation for a 16-bit x86 CPU, and then uses part of the Wine codebase to translate the calls from 16-bit to 32-bit. This gives you very similar functionality to the real NTVDM environment on a 32-bit system, and allows you to run DOS and Win16 applications on your 64-bit Windows system, albeit with limited performance, since the CPU emulation is not very fast. Because it’s not a sandbox environment like most emulators, but it actually integrates with the host OS via 32-bit calls. In our case, we can simply run the Final Reality installer via otvdm. Just download the latest stable release from the otvdm Github page, and extract it to a local folder. Then start odvdmw.exe, and browse to your fr101.exe installer file. It will then install correctly, directly onto the host system. There appear to be no compatibility problems with this oldest benchmark of them all, funny enough, so that rounds it all up. Here is a video showing all the 3DMark demos: And here is the XL-R8R demo: And finally the Final Reality demo:

I wonder if it is possible to create a poll between old members , about renaming this forum section ?

You did well. Systems of that era were scoring 2 to 5 Reality Marks. Write how you managed to run it with modern OS and hardware.

People that are still benching 754-939 with xtreme cooling should have a clue (i guess) It wasn't such a big list anyway. I can't find my notes at the moment (must be stashed away in some board box with other stuff ... probably) and as always , i will find it when i wont be looking for it.

I asked about die temps , because you know how weird these E5 and E6 cores react with negative temps. No software monitoring. Many years back , when i was using extreme cooling , i remember i had to actively monitor realtime the die temp with an extra temp probe on the Fluke. We had temp probes with very thin wires , that you could navigate through the cpu pins. At the edge of stability , even a 2C temp difference had an impact on benchmarks. For example , at -8C die temp you could finish the run , while at -10C you were blue screening (temp related) cold bug. When using an SS it's very hard to hold the temps you need. I was never lucky enough to have a 754 or 939 cpu without a cold bug (and we didnt have a list of cpu steppings to have ... back then). What do you mean ? Evap temp will always be higher (colder) than die temp

-30C die temp or evaporator temp ?

What can i say. After so many years (in this hobby) , i thought i've seen it all. But ... i was wrong. Congrats for this awesome combo (board and cpu) and score !! Die temp ?

It would be very interesting to see something different this time (i mean other than the usual Athlon and Turion Mobile cores).

Top result !!

Sorry for the late reply , but i was away. I wanted to know how were they named , to look for them in my files.

Scotty How was it called ?

Scotty They should have the exact same memory support. https://www.x86-guide.net/en/cpu/AMD-Athlon-1640B-cpu-no2967.html https://www.x86-guide.net/en/cpu/AMD-Athlon-64-LE-1640-(Lima-512K)-cpu-no8087.html

I cant spot any difference between the Athlon 64 1640B and the Athlon 64 LE-1640 (the 512kb L2 version) https://www.cpu-world.com/Compare/575/AMD_Athlon_64_1640B_vs_AMD_Athlon_64_LE-1640_(L2_512KB).html