Writeup: AOpen i945GMm-HL shenanigans
AOpen i945GMm-HL - The Retro Web
Welp. This board is weirder than I ever thought it'd be. Not the board in general, but the specific one I bought.
To begin, it turns out that my particular board, and likely many others of the same model, are OEM-customized boards that AOpen provided to a little company called RM Education. They make all-in-one PCs for the UK market.
...And they are using evaluation BIOSes (in other words, BIOS software that's normally only meant for prototyping and... well, evaluation) in their retail boards.
My specific board contains BIOS version R1.08, which is actually R1.02 apparently. There is evidence of an R1.07 existing as well from a reddit thread on the r/buildapc subreddit, but I doubt that it's been dumped anywhere.
Moving on to the original point of this writeup, I got this board because I wanted to build a system that pushed the 32-bit Core Duo T2700 as far as possible, meaning I needed a mobile-on-desktop board. AOpen built a reputation for doing this sorta stuff in the 2000s, so I went ahead and picked one of their boards for use (although I would've much preferred using the top of the line AOpen i975Xa-YDG instead if it were being sold anywhere. That's a VERY tasty looking board with its full size DIMM slots and SLI-compatible dual PCIe x16 slots and ability to crank the FSB all the way to 305MHz).
Slightly surprisingly, the Core Duo T2700 is quite the overclocker! It's able to push from 2.3GHz all the way up to 2.7GHz with some FSB overclocking using the SetFSB tool. It's multiplier-locked to a range from 6.0 to 14.0, so I can only push it through this means.
The board I'm using, the AOpen i945GMm-HL, supports running the FSB up to 195MHz. It's okay-ish in terms of stability, but crashes when running Aida64 benchmarks unless I loosen the memory timings from the 5-5-5-15 settings that it uses at 333MHz to 5-6-6-18, which is just the tiniest bit faster than its stock settings for 400MHz operation by SPD. With these settings, it's much more stable and is able to run the benchmarks, though unless I lower the FSB from 195MHz to 190, it will consistently crash Chrome when trying to play Youtube videos on integrated graphics. I'll likely experiment some to see if adding a card capable of handling the video playback in hardware helps.
For now, this is all for this blog post. I'll follow-up with more details as they come in reblogs. As follows are the specs of the system:
AOpen i945GMm-HL (OC'ed from 166MHz FSB to 195MHz, 190MHz for more stability)
Intel Core Duo T2700 @ 2.7GHz (OC'ed from 2.3GHz)
2x 2GB Crucial DDR2 SO-DIMMs @ 5-6-6-18 timings
Some random 40GB Hitachi hdd lol
Windows XP Pro SP3, fully updated via LegacyUpdate
Supermium Browser (fork of Google Chrome and the reason why I was able to test Youtube playback in the first place)
Coming up: Installing One-Core-API and Java 21 to play Minecraft 1.21 on a 32-bit system out of spite for Microsoft "dropping support" for 32-bit CPUs.
2 notes
·
View notes
Writeup: Forcing Minecraft to play on a Trident Blade 3D.
The first official companion writeup to a video I've put out!
So. Uh, yeah. Trident Blade 3D. If you've seen the video already, it's... not good. Especially in OpenGL.
Let's kick things off with a quick rundown of the specs of the card, according to AIDA64:
Trident Blade 3D - specs
Year released: 1999
Core: 3Dimage 9880, 0.25um (250nm) manufacturing node, 110MHz
Driver version: 4.12.01.2229
Interface: AGP 2x @ 1x speed (wouldn't go above 1x despite driver and BIOS support)
PCI device ID: 1023-9880 / 1023-9880 (Rev 3A)
Mem clock: 110MHz real/effective
Mem bus/type: 8MB 64-bit SDRAM, 880MB/s bandwidth
ROPs/TMUs/Vertex Shaders/Pixel Shaders/T&L hardware:
1/1/0/0/No
DirectX support: DirectX 6
OpenGL support:
- 100% (native) OpenGL 1.1 compliant
- 25% (native) OpenGL 1.2 compliant
- 0% compliant beyond OpenGL 1.2
- Vendor string:
Vendor : Trident
Renderer : Blade 3D
Version : 1.1.0
And as for the rest of the system:
Windows 98 SE w/KernelEX 2019 updates installed
ECS K7VTA3 3.x
AMD Athlon XP 1900+ @ 1466MHz
512MB DDR PC3200 (single stick of OCZ OCZ400512P3)
3.0-4-4-8 (CL-RCD-RP-RAS)
Hitachi Travelstar DK23AA-51 4200RPM 5GB HDD
IDK what that CPU cooler is but it does the job pretty well
And now, with specs done and out of the way, my notes!
As mentioned earlier, the Trident Blade 3D is mind-numbingly slow when it comes to OpenGL. As in, to the point where at least natively during actual gameplay (Minecraft, because I can), it is absolutely beaten to a pulp using AltOGL, an OpenGL-to-Direct3D6 "wrapper" that translates OpenGL API calls to DirectX ones.
Normally, it can be expected that performance using the wrapper is about equal to native OpenGL, give or take some fps depending on driver optimization, but this card?
The Blade 3D may as well be better off like the S3 ViRGE by having no OpenGL ICD shipped in any driver release, period.
For the purposes of this writeup, I will stick to a very specific version of Minecraft: in-20091223-1459, the very first version of what would soon become Minecraft's "Indev" phase, though this version notably lacks any survival features and aside from the MD3 models present, is indistinguishable from previous versions of Classic. All settings are at their absolute minimum, and the window size is left at default, with a desktop resolution of 1024x768 and 16-bit color depth.
(Also the 1.5-era launcher I use is incapable of launching anything older than this version anyway)
Though known to be unstable (as seen in the full video), gameplay in Minecraft Classic using AltOGL reaches a steady 15 fps, nearly triple that of the native OpenGL ICD that ships with Trident's drivers the card. AltOGL also is known to often have issues with fog rendering on older cards, and the Blade 3D is no exception... though, I believe it may be far more preferable to have no working fog than... well, whatever the heck the Blade 3D is trying to do with its native ICD.
See for yourself: (don't mind the weirdness at the very beginning. OBS had a couple of hiccups)
Later versions of Minecraft were also tested, where I found that the Trident Blade 3D follows the same, as I call them, "version boundaries" as the SiS 315(E) and the ATi Rage 128, both of which being cards that easily run circles around the Blade 3D.
Version ranges mentioned are inclusive of their endpoints.
Infdev 1.136 (inf-20100627) through Beta b1.5_01 exhibit world-load crashes on both the SiS 315(E) and Trident Blade 3D.
Alpha a1.0.4 through Beta b1.3_01/PC-Gamer demo crash on the title screen due to the animated "falling blocks"-style Minecraft logo on both the ATi Rage 128 and Trident Blade 3D.
All the bugginess of two much better cards, and none of the performance that came with those bugs.
Interestingly, versions even up to and including Minecraft release 1.5.2 are able to launch to the main menu, though by then the already-terrible lag present in all prior versions of the game when run on the Blade 3D make it practically impossible to even press the necessary buttons to load into a world in the first place. Though this card is running in AGP 1x mode, I sincerely doubt that running it at its supposedly-supported 2x mode would bring much if any meaningful performance increase.
Lastly, ClassiCube. ClassiCube is a completely open-source reimplementation of Minecraft Classic in C, which allows it to bypass the overhead normally associated with Java's VM platform. However, this does not grant it any escape from the black hole of performance that is the Trident Blade 3D's OpenGL ICD. Not only this, but oddly, the red and blue color channels appear to be switched by the Blade 3D, resulting in a very strange looking game that chugs along at single-digits. As for the game's DirectX-compatible version, the requirement of DirectX 9 support locks out any chance for the Blade 3D to run ClassiCube with any semblance of performance. Also AltOGL is known to crash ClassiCube so hard that a power cycle is required.
Interestingly, a solid half of the accelerated pixel formats supported by the Blade 3D, according to the utility GLInfo, are "render to bitmap" modes, which I'm told is a "render to texture" feature that normally isn't seen on cards as old as the Blade 3D. Or in fact, at least in my experience, any cards outside of the Blade 3D. I've searched through my saved GLInfo reports across many different cards, only to find each one supporting the usual "render to window" pixel format.
And with that, for now, this is the end of the very first post-video writeup on this blog. Thank you for reading if you've made it this far.
I leave you with this delightfully-crunchy clip of the card's native OpenGL ICD running in 256-color mode, which fixes the rendering problems but... uh, yeah. It's a supported accelerated pixel format, but "accelerated" is a stretch like none other. 32-bit color is supported as well, but it performs about identically to the 8-bit color mode--that is, even worse than 16-bit color performs.
At least it fixes the rendering issues I guess.
2 notes
·
View notes