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.
Now this is something you don't really come across every day. A complete in box 3Dfx Voodoo Rush, complete with all accessories. Driver CD? Check. Pack-in games? Check. All the manuals and pamphlets you can imagine for something like this? For sure.
And of course, let's not forget about the card itself.
The Voodoo Rush is a pretty unique card compared to most other graphics cards even from the era. Unlike the Voodoo 1 and Voodoo 2, it's not a purely 3D card incapable of rendering 2D graphics. At the same time, it's also not one of the increasingly-common all-in-one cards capable of both 2D and 3D in a single chip. It'd take the Voodoo Rush's successor, the Voodoo Banshee, for 3Dfx to accomplish that themselves.
Instead, the Voodoo Rush chipset (and I really do mean chipset) is produced by 3Dfx in partnership with Alliance Semiconductor and Macronix, although cards featuring a chip from the former are far more common than the latter. Both Alliance and Macronix's chips feature a special dedicated bus that allows them to sacrifice a chunk of what would otherwise be their memory buses to connect to video memory to communicate with the pair of 3Dfx chips to the right of the card. These two chips together handle the framebuffer and texture mapping, and were essentially a cut-down Voodoo 1 in terms of performance.
The Alliance Semiconductor chip is also a curiosity in itself, and although officially, the Alliance AT25 is distinct from the AT3D, it is believed that the AT25 is in fact just a rebranded AT3D with the 3D features disabled at the driver level. I have yet to test this myself however, but a writeup on the AT3D can be found here.
As far as the pack-in games go, this particular boxed set includes Pandemonium, Formula 1 Racing, and Star Wars Shadow of the Empire: Battle of Hoth. I found the latter two games very fun to play, especially for pack-in games included with what was meant to be a budget graphics card. Pandemonium was a neat 3D side-scrolling platformer, but I didn't feel that it was nearly as enjoyable in comparison. Further thoughts on the pack-in games are included in the linked Youtube video I made alongside this post:
All in all though, for a budget graphics card originally released in 1997 put into a scenario where it's now paired with roughly 1999-ish hardware, the Voodoo Rush turned out to be a far better experience than I'd expected. At least, when only considering the pack-in games. Partly for length reasons, I opted not to try any other games on the Rush besides the three pack-in games, but I do plan on doing a follow-up video covering additional titles.
High-resolution scans of the box and all of its contents alongside disk images of all four CDs are uploaded to Archive.org and TheRetroWeb.
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.
Somehow, I always find myself gravitating back to the S3 ViRGE/DX.
This time around, rather than placing total focus on the ViRGE itself, we'll be taking a look at some OpenGL wrappers!
This writeup will be updated along the way as more videos release.
The setup is as follows:
Matsonic MS7102C
Windows 98SE RTM with the following patches/update: KernelEX 4.5.2, NUSB v3.3e, Windows Installer 2.0, DirectX 9.0c
Intel Pentium III (Coppermine) @ 750MHz
S3 ViRGE/DX @50MHz w/4MB EDO DRAM (using the S3 Virge "SuperUni" drivers)
256MB PC-133 SDRAM (Kingston KVR133X64C3/512) (System can only handle 256MB per DIMM)
Sound Blaster AWE32 CT2760
Some random 5GB Hitachi 2.5" HDD that I "borrowed" from a very dead laptop
Java 6 (1.6.0) build 105/Java 6u0
Wrappers to be tested:
S3Mesa - a wrapper based on the Mesa project. It's a full OpenGL implementation sitting on top of S3D and Direct3D, but from the available source code appears to be missing some functionality and is quite unstable.
AltOGL - also a wrapper based on the Mesa project, but relies solely on Direct3D. It is similarly missing some functionality, but is much more widely compatible with cards beyond the Virge thanks to its lack of reliance on S3's proprietary API.
Techland S3D - one of the many wrappers made by Techland for their Quake II engine-based "Crime Cities" game. Although it like S3's own GLQuake wrappers only implements as much of the API as is needed by the engine, it still implements far more features than S3's DX5 and DX6-based wrappers, of which are not tested in this wrapper race.
Techland D3D - like AltOGL, Techland's D3D counterpart to their S3D wrapper implements a subset of the OpenGL spec, but still enough to be compatible with a number of titles beyond Quake II engine games.
GLDirect 1.x - A very early version of GLDirect. There exists a license code for this version floating around on the internet that appears to have been used for internal testing by Shuttle, a PC manufacturer that's largely fallen out of relevance and mainly does industrial PCs nowadays.
GLDirect 3.0.0 - One of the last versions of GLDirect to support hardware acceleration on DX6-class graphics cards.
Things tested
WGLGears
ClassiCube 1.3.5 and 1.3.6
Minecraft: Indev in-20091223-1459, Alpha 1.0.4, Beta 1.7.3 (with and without Optifine), Release 1.5.2
Tux Racer
GL Excess benchmark
Half Life 1 v1.1.1.1 KingSoft NoSteam edition
Findings
GLDirect 1.01
#OpenGL #GLDirectThird recording's the charm, I guess.A big thank you to my patrons: Opium4TmassS, Bicyclette, Piper, and TheToad. (I'll rem
OpenGL Version String
Vendor: SciTech Software, Inc.
Renderer: GLDirect S3 Inc. ViRGE/DX/GX
Version: 1.2 Mesa 3.1
Textures do not work at all in every test case besides Half Life.
ClassiCube 1.3.5 and 1.3.6 both fail to render any terrain beyond a greyish horizon and the outlines of blocks. All blocks, items, and text that are able to be rendered are pure white in color and have no textures applied.
Minecraft Indev in-20091223-1459 and Beta 1.7.3 with Optifine crash upon world-load
Minecraft Alpha 1.0.4, Beta 1.7.3, and Release 1.5.2 all crash upon launch.
Tux Racer is able to render 2D textures such as text and graphics, but flickers INTENSELY and is a seizure risk. Beyond this, however, the game will only render a solid white screen.
Half Life launches and runs, but at a terrible 4 FPS. The game lags hard enough that the tram in the opening area of the game is frozen where it is, preventing the player from accessing anything beyond the intro cutscene.
GL Excess crashes instantly.
Performance
GLGears: ~76 FPS
ClassiCube 1.3.5/1.3.6: Unknown; game fails to render
Minecraft in-20091223-1459: Unknown; world crash
Minecraft Alpha 1.0.4: Unknown; crash on game launch
Minecraft Beta 1.7.3: Unknown; crash on game launch
Minecraft Beta 1.7.3 w/Optifine: Unknown; world crash
Minecraft Release 1.5.2: Unknown; crash on game launch
Tux Racer: Unknown; game fails to render in a VERY seizure-inducing way
Half Life: ~4 FPS; gameplay outside of training room is broken
GL Excess: Unknown; instant crash
GLDirect 2.00
From here on, GLDirect is split between "Game" and "CAD" wrappers, denoted by either a "G" or a "C" after the version number where written in this writeup.
OpenGL Version String (2.00C)
Vendor: SciTech Software, Inc.
Renderer: GLDirect S3 Inc. ViRGE/DX/GX
Version: 1.2 Mesa 3.1
OpenGL Version String (2.00G)
Vendor: SciTech Software, Inc.
Renderer: GLDirect
Version: 1.1
GLDirect 2.00C likes to complain about insufficient color precision.
Changing the color precision from 24-bit up to the maximum 32-bit color does absolutely nothing.
The CAD wrapper very clearly is intended for non-gaming workloads given how easily it crashes things. However, it is strange that it is labeled as a "maximum compatibility" wrapper/driver.
I am not using the SciTech GLDirect 3.0 driver beta seen in the video because it requires a card capable of higher DirectX versions than 6, which is what the S3 ViRGE supports. I may revisit this video idea with a later graphics card in a future video for more thorough testing.
Using the 2.00G wrapper, Minecraft Alpha and Beta have many visual bugs. Text is not rendered at all, for example, and the world selection screen is eerily dim compared to what it should be. Beta in particular extends this darkness to the title screen as well.
Under 2.00G, Minecraft Beta 1.7.3 with Optifine no longer has this darkness.
Under 2.00G, Minecraft Release 1.5.2... inverts the colors of the Mojang logo?
Did you know that if you fall out of the Half Life intro tram in just the right place, you get to see the multiverse?
The framerate starts to rise when this happens, as it appears that the tram after becoming unstuck will trigger the next loading screen. Unfortunately, this loading screen appears to be what seals your fate. Once the tram stops though you at least get to meet biblically-accurate Half Life rendering in a smooth double-digit framerate!
Performance (2.00C)
GLGears: 63 FPS
ClassiCube 1.3.5/1.3.6: Unknown; game fails to render
Minecraft in-20091223-1459: Unknown; crash on game launch
Minecraft Alpha 1.0.4: Unknown; crash on game launch
Minecraft Beta 1.7.3: Unknown; crash on game launch
Minecraft Beta 1.7.3 w/Optifine: Unknown; crash on game launch
Minecraft Release 1.5.2: Unknown; assumed crash on game launch based on previous versions' behavior
Tux Racer: Unknown; game fails to render (no longer seizure inducing at least)
Half Life: Unknown; crash on game launch
GL Excess: Unknown; instant crash
Performance (2.00G)
GLGears: 390 FPS; only a black screen was rendered.
ClassiCube 1.3.5/1.3.6: 10-30 FPS range, ~12-15 FPS on average; most of the game still does not render, but text, the hotbar, hand items, and very occasional flickers of geometry do render. Seizure warning.
Minecraft in-20091223-1459: Unknown; crash on world load
Minecraft Alpha 1.0.4: Unknown; crash on world load
Minecraft Beta 1.7.3: Unknown; crash on world load
Minecraft Beta 1.7.3 w/Optifine: Unknown; crash on world load
Minecraft Release 1.5.2: Unknown; crash on game launch
Tux Racer: Unknown; crash on game launch
Half Life: 4-5 FPS; game physics are almost entirely broken down and I'm pretty sure you end up phasing into a higher plane of existence along the way. Trying to enter the training room crashed the entire PC afterwards.
GL Excess: Unknown; instant crash
GLDirect 3.00
OpenGL Version String (3.00G)
Vendor: SciTech Software, Inc.
Renderer: GLDirect
Version: 1.1
OpenGL Version String (3.00C)
Vendor: SciTech Software, Inc.
Renderer: GLDirect S3 Inc. ViRGE/DX/GX
Version: 1.2 Mesa 3.1
GLDirect 3.00, both the CAD and Game versions, appears to behave identically to GLDirect 2.00 in almost all cases unless stated otherwise.
Performance (3.00G)
GLGears: 249 FPS; gears are rendered completely incorrectly
ClassiCube 1.3.5: 15-20 FPS on average; most of the game fails to render and the system hard-crashes after a few seconds.
ClassiCube 1.3.6: Insta-crash.
Minecraft: Crash on world load across all versions. Didn't bother testing Release 1.5.2.
Tux Racer: Unknown; crash on game launch
Half Life: ~4 FPS; extremely choppy audio in tutorial level.
GL Excess: Unknown; instant crash
Performance (3.00C)
GLGears: 80 FPS; Perfectly rendered
ClassiCube 1.3.5/1.3.6: Unknown; renders a white screen
Minecraft: Crashes on game launch. The game may also complain about color depth here.
Tux Racer: Unknown; renders a white screen
Half Life: Unknown; renders a white screen and then crashes on game launch
GL Excess: Unknown; instant crash
Techland S3D
#OpenGL #Techland #TechlandS3D #S3GraphicsThis video survived a blackout and a partially-fried capture card! (I should really look into repl
We've now moved on from GLDirect! From here on out, each wrapper is instead a discrete opengl32.dll file that must be dropped into the folder of whatever program you'd like to run it with.
Right off the bat, things appear to be taking a turn for the interesting as GLGears fails to render anything.
Performance
GLGears: 60 FPS, but only because a black screen is rendered.
ClassiCube 1.3.5/1.3.6: Crashes on game launch but renders a solid blue screen.
Minecraft in-20091223-1459: We load into a world! Have fun trying to play it though. Rendering is very flickery and broken. It may be possible that there's an issue of some kind with z-buffering. 12-15 fps if that matters at all in this case.
Minecraft Alpha 1.0.4: Crashes on game launch.
Minecraft Beta 1.7.3: Renders an inverted vignette that slowly grows darker.
Minecraft Beta 1.7.3 w/Optifine: Crashes on world load.
Minecraft Release 1.5.2: Rendered the title screen with many errors for a brief moment before turning to a black screen and crashing.
Tux Racer: Unknown; renders mostly a white screen. The game does respond to user inputs, and the rendered scene changes based on those inputs, but no textures or complex objects are ever rendered. Instead, you only get the white "floor" plane, a solid blue skybox, and translucent boxes where text, objects, and particles should've been.
Half Life: Crash on game launch; absolutely RAVAGES the title screen in ways I thought only the Alliance AT3D could.
GL Excess: Actually loads! But renders only solid black or white screens after the initial loading screen.
Techland D3D
Two more wrappers left after this one! This wrapper and the Techland S3D wrapper that came before it were both created by Techland originally for their "Crime Cities" game, which, being an OpenGL title during an era where support was spotty at best across the dozens of vendors that existed at the time, necessitated the creation of a set of OpenGL wrappers that could translate calls to other APIs.
Anyway, I originally thought that there wasn't going to be much that'd be interesting about this wrapper based on how Minecraft (didn't) work, but I was quickly proven wrong in the things I tested afterwards!
GLGears: ~290 FPS, but only because a black screen is rendered.
ClassiCube 1.3.5/1.3.6: 2-5 FPS. Runs with z-buffering issues. Faster than software rendering, but not by much (SW rendering was roughly 1-3 FPS)
Minecraft: Renders only a black screen and (usually) crashes.
Tux Racer: Unknown; renders a mostly-white screen. However, shading works well enough that you can just barely distinguish what is what.
Half Life: Crash on game loading after the title screen; absolutely RAVAGES the title screen in ways I thought only the Alliance AT3D could.
GL Excess: Actually runs! Performance is alright in some parts but generally remains low. Also, it erroneously uses the exact same texture for every single rendered object.
S3Mesa/AltOGL
So, it turns out that there may or may not be some level of bugginess involved with S3Mesa and AltOGL on my current testing setup. Whereas both wrappers were (somewhat) stable and able to load into both Minecraft and Half Life with relatively little trouble in previous experiments with AltOGL/S3Mesa and the Virge, this time around it doesn't appear to be working as expected. There may be something that got screwed up thanks to having installed and used multiple different versions of GLDirect prior to using S3Mesa and AltOGL.
The best-case scenario would have been to start off with a fresh install of Windows 98 with every test run with a different wrapper, but in this case I didn't do that. As a result, the findings for S3Mesa and AltOGL here should be considered with a grain of salt.
Vendor: Brian Paul
Renderer: Mesa S3GL V0.1
Version: 1.1 Mesa 2.6
Vendor: Brian Paul
Renderer: altD3D
Version: 1.2 Mesa 3.0
Performance - AltOGL
GLGears: 125 fps
ClassiCube 1.3.5/1.3.6: crash + system lockup
Minecraft in-20091223-1459: crashes on world load (normally it's much more stable according to previous videos. See here for reference: Indev on S3 ViRGE using AltOGL
Minecraft: Aside from Beta 1.7.3 with Optifine which crashes on world load, all versions of the game crash instantly.
Tux Racer: Freezes on main menu
Half Life: Instacrash
GL Excess: Instacrash
Performance - S3Mesa
GLGears: i forgor to run it 💀
ClassiCube 1.3.5/1.3.6: no crash but everything is rendered in solid white rather than with textures. performance is likely in the single digits.
Minecraft in-20091223-1459: crashes on world load (normally it's much more stable according to previous videos. See here for reference: Indev on S3 ViRGE using S3Mesa
Minecraft: Aside from Beta 1.7.3 with Optifine which crashes on world load, all versions of the game crash instantly.
Tux Racer: Renders just about everything except for the game terrain and player character. Performance seems to just barely reach double-digits.
Half Life: Instacrash; textures missing on main menu (similarly to Minecraft indev, this is an unexpected result as the game normally is able to play.)
GL Excess: Instacrash
Misc Notes
Running HWinfo32 crashes the system regardless of if KernelEX is enabled or not.
GLDirect 5 refuses to do anything other than software rendering due to the lack of higher DirectX support by the Virge.
GLDirect 3 can "run", but crashes the entire system after a few seconds in Classicube using the "game" wrapper.
GLDirect 3, unlike 5, has no license code available for free use.
I didn't have the opportunity to record during the time GLDirect 3's trial was active, and it expired already so to avoid having to reinstall everything to get a new trial (I've already tried to roll back the system calendar), I will instead be using GLDirect 2, which I have in fact found a license code for.
GLDirect 2 has a fourth option for OpenGL acceleration beyond the CAD/Game DirectX hardware acceleration and the CPU software acceleration, which is a DX8-based wrapper that appears to have later debuted fully in GLDirect 3.x and up. I think it's safe to assume that the CAD/Game DX6-based wrappers were then deprecated and received no further development after GLDirect 2.x given the pivot to a newer DirectX API.
There are a number of other wrappers available for the S3 ViRGE, and even an OpenGL MCD for Windows 2000. However, I'm sticking with the five that were listed here as they implement enough of the OpenGL spec to be (more) widely compatible with a number of games. The S3Quake wrapper, for example, implements only enough of the spec to run GLQuake, and I have never gotten it to even launch any other titles.
I really, sincerely didn't expect MC Beta 1.7.3 to launch at all even with Optifine, given how from prior testing I found that the game would instantly crash on anything higher than Classi--nevermind, it just crashed on world-load. (S3Mesa, AltOGL, TechlandD3D, TechlandS3D, GLDirect 1.x)
Non-Optifine Beta 1.7.3 crashes before even hitting the Mojang splash screen. (S3Mesa, AltOGL, TechlandD3D, GLDirect 1.x)
Non-Optifine Beta 1.7.3 gets into a world! All text is missing though as are the blocks. Performance is expectedly horrendous. (TechlandS3D)
Making batch files to handle version-switching instead of doing it by hand is nice.
Alongside the system setup for testing apparently no longer being ideal for using S3Mesa and AltOGL, comparison against some test runs done on an Athlon XP 1.1GHz system also reveal that the Virge performs far better with a faster CPU like the aforementioned Athlon XP than the 750MHz Pentium that this series of experiments is built upon. This experiment as a result may be eventually redone in the future using that faster CPU.
Writeup: To boldly stumble… pushing the Alliance AT3D to its limits
Yeah. We're venturing into levels of absolute jank that none have ever gone before.
This writeup is also available on The Retro Web!
#AllianceAT3D #terriblegraphicsGaming? Oh, I thought you meant suffering.Writeup + bonus content: https://www.tumblr.com/not-radioshack/7306
Fun fact, this card singlehandedly killed Alliance Semiconductor's graphics division! All three successor cards that were planned for release after the AT3D were promptly scrapped and never heard of again. Alliance themselves would crumble not long after, and at present is a shell of its former self that manufactures only memory chips as opposed to… well, mainly memory chips and a few other things on the side.
Aaaaaaanyhow, let's get on with this with a quick spec-dump.
OpenGL support (continued)
- AltOGL OGL to D3D:
--100% OpenGL 1.1 compliant
--100% OpenGL 1.2 compliant (but I highly doubt it)
--Vendor string:
Vendor: Brian Paul
Renderer: altD3D
Version: 1.2 Mesa 3.0
As for the rest of the system...
Windows 98 SE w/KernelEX (no updates)
Matsonic MS7102C
Intel Pentium III (Coppermine) @ 750 MHz
256MB PC-133 SDRAM (single stick of Kingston KVR133X64C3/512, can't extract SPD data bc system crashes)
Hitachi 4GB Microdrive
Some random Slot 1 Cooler Master CPU cooler
And with that out of the way, onto the notes!
So. Uh, yeah. The Alliance AT3D, and more specifically this AT3D, is a very... VERY strange card. Despite releasing rather late for a 3D-capable graphics chip in comparison to the competition, the AT3D is very clearly half-baked at best, and a flaming dumpsterfire at worst. I'm not sure if it's the hardware itself or drivers written by the world's worst driver dev team to have ever existed, but there is something very, very wrong with the 3D rendering capabilities that this card has.
As implied by the specs of the card from up above, the AT3D has no native OpenGL support. Or native DirectX 6, for that matter. Windows 98 just happens to like to stamp DX6 support onto cards that don't support anything higher. This card was released targeting Windows 95, and drivers for Windows 98 and up were never made available. Luckily, with how similar the two OSes are at the kernel level, the Win95 drivers are fully-compatible with '98. Yes, that is in spite of the atrocious 3D rendering.
So, anyway. OpenGL. That was what this video was intended to focus on, but between me catching Covid back in August and only finally recovering enough to begin recovering by late September, the video ultimately ended up as this congealed pile of rambling and chaos, with plenty of Windows 98 crashes sprinkled in for flavor.
ClassiCube runs... okay, I guess, if you're willing to look past the amazing rendering quality. AltOGL crashes ClassiCube 1.3.5, and though I've been told that 1.3.6 works with AltOGL, with the AT3D at least it still crashes.
So, instead of AltOGL, I am using Techland's OpenGL to Direct3D wrapper. Though intended to be a "mini-GL" for their Crime Cities game, Techland's wrappers have a decent reputation for speed and compatibility among low-end cards. Though, the AT3D is clearly an outlier on both fronts.
Minecraft itself is unable to launch with either wrapper. With the Techland wrapper, the game complains about not being able to create an OpenGL context, which isn't too surprising given how the Techland wrapper implements only a subset of the OpenGL spec. Slightly more surprising, however, is the fact that AltOGL also fails to allow the game to launch, instead resulting in an instant crash back to desktop. So, while Minecraft proper isn't able to run on the AT3D, I still would say that you could pull off some block game shenanigans with this thing if you're willing to suffer the pain of its rendering hardware screaming in agony.
Other games aside from Minecraft and ClassiCube were tested as well, or at least attempted to be tested, but much like Minecraft itself, they crashed in varying levels of severity with both wrappers. Aside from ClassiCube, the only thing I was successful in running were the 3DMark99 and 2000 benchmarks and demos.
But, this is not where this writeup ends. Oh, no. There's still a completely fresh, unopened can of worms sitting right here on the table for all of us to enjoy.
That can of worms? The card itself and its BIOS.
If you take a look at VGA Legacy MKIII's entry on the Alliance AT3D, you'll find that all of the cards shown on the website are made by a company called "Super Grace". All of them are identical.
My card, however, has a little extra something: a populated 10-pin header.
I'm not 100% sure about what its function is, but just from eyeballing where the traces lead to from the pin header suggests that this may be a header for some kind of optional TV-out add-on board. Perhaps one that outputs composite and/or s-video. It certainly fits in line with the strange video BIOS (vBIOS) that this card comes with. (Also, wow! Matching graphics core, PCB, and memory chip branding! And look at that neato peacock logo from an unknown company!)
So then. The BIOS. This card's BIOS is version 4.30.00 Build 29, whereas the version of BIOS on the Super Grace cards is 2.30.00 Build 29. The differences go beyond just a bump from a 2 to a 4, too; the "version 4" BIOS has a neat animated Alliance Semiconductor logo and banner that slides in from the right, whereas the "version 2" BIOS is a static text box with no logo or anything. However, the lack of animation does also allow the system to complete the bootup process much faster.
Below are a pair of videos demonstrating the difference:
Beyond the visual differences, the primary functional difference between the v2 and v4 BIOSes is that the v2 BIOS seems to be completely unaware of the card's seeming TV-out capability. The v4 BIOS, however, is practically hypersensitive to it.
What? TWO videos on the Alliance AT3D? You're spoiling me.Writeup + bonus content: https://www.tumblr.com/not-radioshack/730644935032930304/
I'll give you a rundown of what happened.
I often use a program called "VCS" to let my Datapath VisionRGB capture card pass video through and act more or less like a regular monitor. The problem, however, is that apparently, when the capture card is hooked up to the AT3D, this causes the EDID (Extended Display Identification Data) that the capture card sends to the AT3D to seemingly identify itself (to the AT3D, at least) as... a TV.
Now, normally this shouldn't be much if any issue. Graphics cards after all are meant to be able to handle this sort of connection. Heck, before the capture card, I was using an actual TV as the monitor for my testbench.
But because weird hardware seems to gravitate towards me, this was not the case for the AT3D. Whatever EDID info the capture card seems to send to the AT3D when VCS is used causes the card to trigger its "TV mode", which enables a TV features tab in the card's graphics settings and disables almost all of the regular settings for refresh rate and screen positioning available in the regular settings tab. Attempting to disable the TV features tab results in a system crash.
The solution to this? Going into the VisionRGB configuration, manually wiping the EDID information, and using OBS as a video-out from the capture card instead after rebooting both the capture system and the testbench. This finally gets the AT3D to recognize the capture card as a regular monitor rather than a TV, and makes the TV features tab go away and unlocks the regular monitor settings.
The v2 BIOS does not do any of this.
I really don't have anything else to say about this card. The AT3D alone is already known for being one of if not THE worst graphics card to ever exist, and the extra sprinkle of weird behavior that my specific card shows is more or less just icing on the terribleness cake. The lack of the ability to really do anything aside from purely-2D tasks makes it hard to have much that can be done with the card in the first place. Though, I guess Baldur's Gate 1 works pretty well since it's a sprite-based isometric 3D game that only uses 2D rendering techniques.
Anyway yeah this card is peak jank lol. Have my card's weird BIOS that doesn't exist anywhere else on the internet. The v2 BIOS is available from VGA Legacy MKIII.
A much later version 4.30.00 Build 29 vBIOS for the Alliance AT3D. This vBIOS includes an animated boot splash with a sliding Alliance Semic
Also the AT3D can run Tux Racer if you slap AltOGL on it. It crashes the whole system if you try and use the Techland wrapper, so the behavior is the polar opposite of ClassiCube 1.3.5.
Every time I close my eyes I see it... the broken rendering, the screams... they haunt me.Writeup + bonus content (even though this itself i
Update: It appears that the Youtube RetroTechBytes also has a nearly-identical AT3D, peacock logo and all:
Please signal boost: One-of-a-kind Broken Prototype S3 Chrome 460 Mega-infopost
(Yes, I know that is a very word salad-y post title.)
This is the S3 Chrome 460. It is currently nonworking. Nobody knows anything about it, and I’m trying to get in contact with any former S3 Graphics engineers that may be able to help.
What is known:
All “@” handles are in reference to users on Twitter.
As a whole, the Chrome 400 series utilized the Destination architecture, which was S3’s very first unified shader architecture capable of GPGPU tasks, much like Nvidia’s CUDA.
The Chrome 450/460 series utilized the mid-range “Destination 2” (D2) architecture, as opposed to “Destination 3” used by the low-end 430/440. As said by Loeschzwerg, there were no known high-end “Destination 1” architecture chip taped out. (https://twitter.com/Loeschzwerg_3DC/status/1683162950951903235)
The Chrome 450/460 was a 13x13mm (169mm2) die produced on the 90nm node by Fujitsu, and later TSMC. Strangely, the 430/440 series was produced on the much smaller 65nm node.
The Chrome 450/460 supported DX10, whereas the 430/440 supported DX10.1
The PCI device IDs for the Chrome 450/460 series are as follows:
o 9020, 9022, 9023, 9024, 9025 (http://listing.driveragent.com/c/pci/5333)
o The vendor ID for all chips is 5333 (S3 Graphics)
o There is one known beta driver that supports these device IDs (https://www.touslesdrivers.com/index.php?v_page=23&v_code=21175)
These PCI IDs appear to correspond to different die revisions
o Known existing die revisions present in collection: 86C920-921 (ID 9020), 86C922 (ID 9022 based on the cards owned by @Loeschzwerg_3DC), and 86C924 (can be assumed to be device ID 9024)
There are two “major” die revisions that exist.
o Revision 86C920-921 (I will refer to this as the “’920” revision) is most certainly the earliest revision, being physically larger in package size than all other revisions.
It also has a different pinout, and is produced by Fujitsu rather than TSMC, resulting in a greyish tint on the die rather than the blue tint of later revision chips.
The date code on all 86C920 chips (in my collection) reads “0727”, which implies that every ‘920 chip in existence was produced in a single batch on the 27th week of 2007, but cannot concretely prove so.
o Revision 86C922 (‘922) changes fabs from Fujitsu to TSMC, leaving the dies with a blueish tint and changing the pinout. This revision serves as the basis for all following revisions known to exist.
The date code on all 86C922 chips across my collection and Loeschzwerg’s appears to be 0738, implying that this revision was also produced in a single run much like its predecessor. (https://twitter.com/Loeschzwerg_3DC/status/1616750453500547072)
The 86C924 (‘924) revision is minor in comparison to the jump from ‘920 to ‘922, but interestingly the two in my collection have mismatching date codes—0728 and 0734. Unless I am reading the date codes wrong, this means that the ‘924 revision was produced either in two separate batches before the ‘922 run was done, or that perhaps it was continuously produced between the ‘920 and ‘922 revisions. I do not know what changes were made between ‘922 and ‘924.
o Almost all dies have a number and a letter, a word, or both written on them in permanent marker, likely for IDing which ones were being tested for what. The two words that appear the most often are “mem” (by far the most common) and “shift”. The letter “p” (pass?) also regularly appears.
There are three known Chrome 460 ES cards that exist: my broken early-revision ‘920 card, and Loeschzwerg’s two later-revision cards, one of which appears to be a 460 binned down to a 450.
There were rumors that the reason why the card was scrapped seemingly just before release was because its die became too expensive to produce (https://forum.beyond3d.com/threads/s3-excalibur-with-128-bit-mc-taped-out.42965/). There is zero confirmation or denial of this, and this rumor was said in passing on a thread discussing the follow-up Chrome 500 series (Excalibur architecture, which was later revealed to be a mildly tweaked at best Destination architecture).
The Chrome 460 (or at least, its ‘920 revision) gets hot very quickly, and may have been the reason for the switch to TSMC’s fabs.
o I believe that my card, despite having a heatsink and a fan blowing directly at it, likely died from overheating in the few minutes that it was running while I was collecting information and attempting to install an INF-modded 430/440 driver. It worked again after replacing the popped MOSFET and putting on the proper stock heatsink that it would’ve had mounted, but quickly died to a short a second time even with the new cooler. I still feel bad about this.
Most if not all Chrome 460 chips were acquired either directly through the S3/VIA/Centaur lab auction or through someone who attended the auction. The chips and card I own came from John at CPUShack, for example, and a number of others purchased miscellaneous 460s for their private collections from him.
o Loeschzwerg got his cards from a reseller who attended the 2021 Centaur auction just like I had.
And now, returning to my own broken card, to reiterate:
The card died to a short, and triggers the power supply’s OCP mode when the chip is installed on the board according to @dosdude1 . This does not happen when the chip is removed.
VCORE and GND were found by dosdude1 on the card’s footprint of the Chrome 460, and using that knowledge, the resistance from VCORE to GND on the chip itself was found:
o The original chip that was soldered to the card itself measured 1.5 ohms from VCORE to GND
o All other ‘920 chips between the ones in my collection and sent to dosdude1 as candidates for chip-swapping measure between 0.5 and 0.9 ohms, which I was told should be normal for graphics chips, but according to dosdude1 is still plenty low enough to trip the PSU’s OCP mode when installed.
Timeline
I originally purchased the card, alongside two “spare” ‘920 chips, two ‘922 chips, and two ‘924 chips, from CPUShack. The card had no heatsink included, so I had to make do with a chipset cooler (that honestly might have actually been better at cooling than the stock cooler) and a case fan.
o A few weeks after the purchase and arrival of the card, which by then had blown out its MOSFET and died short, I was able to buy a couple S3 Chrome 400-series coolers from CPUShack after he found them. Installing the cooler and replacing the MOSFET with an identical one salvaged off a Chrome 430 managed to get the card to work again for about half a minute from what I remember. However, I will also mention that the salvaged MOSFET came off a Chrome 430 that also died short. The MOSFET itself was undamaged, but the die itself appeared to be busted. I guess it was just an S3 thing during this generation.
o From what I remember, I filled out repair forms for both Louis Rossman and NorthRidgeFix, in hopes that a chip swap with one of the extra ‘920 dies I’d acquired at the time could bring the card back to life. In both cases I was turned down, though this was to be expected since there is zero documentation available for either the card or the chip itself.
o I was then able to get in contact with dosdude1, asking the same thing—just a chip swap was what I was hoping needed to be done. After some back and forth, I sent off the card, both of the extra ‘920 chips I had at the time, and some additional VRM MOSFETs that I’d bought after I’d run out of salvage chips.
o Shortly after the card and chips were mailed out, I came back to CPUShack asking if he had anymore Chrome 460 dies in stock. I proceeded to purchase all remaining chips he could find, which consisted of 10 ‘920 and 10 ‘922 revision dies.
o The chip swap would be completed with minimal issue, but the card unfortunately remained dead. It’s at this point where dosdude1 decided to probe for VCORE and GND, and in turn I measured out the resistance between the two on all ten of the ‘920 chips that had arrived by then, finding that they all read between 0.5 and 0.9 ohms. I do not know what the resistance from VCORE to GND is on the later die revisions, as the pinout was changed.
o Currently, dosdude1 is waiting for a buck regulator replacement to arrive after replacing the MOSFETs themselves yet again, finding in the process that the replacement MOSFETs I sent were faulty and… sending 12 volts straight into VCORE. That’s on me for buying them off Ebay. I did not know where else to look.
o Despite this, even after the faulty MOSFETs were replaced with tested working ones, the card continued to pull far too much current.
o Finally, as of now, he is still waiting for the buck regulator to arrive. There is no evidence that it is faulty as opposed to the MOSFETs, but neither of us have any clue what could be wrong anymore at this point aside from the dies themselves. It’s very much possible that one of the three dies in his possession have been fried to a crisp by that momentary 12v to VCORE in the split second before OCP kicked in, but even then after a non-faulty replacement was installed alongside a spare die it continues to trip the power supply’s OCP.
o I own 27 Chrome 460 dies across three revisions, 13 of which, counting the two sent to dosdude1 and the one installed on the card itself, are of the ‘920 revision that’s been causing myself and dosdude1 headaches for the better part of a year. Neither of us know what is wrong with the card, and outside of the discovery of the faulty “new” MOSFETs I’d sent, the only thing that appears to still be the issue are the dies themselves. They can’t all be bad, right?
Misc. info
My only lead on anyone that may be familiar with the S3 Chrome 460 is Bruce Chang of VIA Technologies. However, his email appears to only accept messages from others in the company.
