I assume all the Intel DX4 Overdrive CPUs at 5V were using voltage regulating interposers.
I also wasn't able to test any of those AMD DX2s or DX4s in the Acorp board as its socket seems to have gotten a bit flakier. Either the ZIF locking mechanism was already slightly damaged before I got it and causing mis-allignment with the underlying contacts or the contacts have gotten bent since then and are making poorer contact.
It may be related to using CPUs with formerly bent pins that are still slightly off, but at some point the socket also started bending CPU pins at odd angles where they were straight beforehand. I may have to try to disassemble the socket at some point and adjust/repair the contacts. I'd like to avoid trying to desolder replace the socket if possible.
Or it's both issues combined: mis-alligned socker cover plate causing the internal contacts to be partially exposed when inserting and thus causing things to get bent. There's more friction than there should be while inserting CPUs, so that may be it. That or there's just a variety of crappier or poorly designed ZIF sockets from the mid 1990s that don't behave like typical Socket 5 or 7 ones.
The Soyo SiS 471 board has a finicky socket, too, and like the Acorp one also has cylindrical recesses in all the holes, so it's easy to mis-allign them and end up bending the pins slightly. Better sockets have conical recesses that help guide the pins in. (the turned brass style non-ZIF sockets also tend to have tapered, conical recesses around the pin holes that help guide them in)
Those blue Intel Overdrive style sockets seem to be like that and some white/beige colored Socket 3 ZIF ones that behave pretty much the same as typical Socket 7 fare. (that other SiS 496 board does have such a socket and I'm more confident in it)
I may have also been correct about the QFP mounted Cx5x86 having larger/thicker pins than the others and may have contributed to making other CPUs harder to make contact in the Acorp board. (and the stiffer pins are less prone to get bent by the socket's weirdness)
After frustrating fiddling with several AMD DX2-80s, DX4s, DX5s and several of the Cyrix DX2s and DX4s I'd been using before not POSTing and ending up with pins bent on removal, I went back to the Cyrix 5x86 and it's working fine as before, both at 120 MHz and 3.46V and at 133 MHz and 5V, but I haven't put much more time on it in the latter configuration.
The trouble really seems completely mechanical in nature with the socket and not any electrical stability issue or damage. Though it's possible the higher ambient temps caused the socket to expand/warp slightly and behave worse than it did in my night-time and early morning testing. (the problems arose in the afternoon after I'd been successfully playing with the ST DX4 at 2x66 and 5V for a while and had Jazz Jackrabbit's attract mode idling in the background ... and I'm still much more confortable running that chip at 5V than the 5x86 and certainly the AMD .35 micron parts)
I also managed to partially corrupt my DOS 5 install when doing some of my benchmarking at more experimental settings, but didn't seem to loose any data (but some files in the DOS folder got corrupted, some commands and the DOS shell stopped working). Then during a separate batch of tests in the Symphony board again, I managed to corrupt/delete my Topbench results by attempting to save and exit and having the system crash/freeze and when reverting to a known-stable configuration, TOPBENCH showed a totally empty results archive. (and I stupidly haven't been backing them up regularly, though I had a backup from about a month ago I just used to repair DOS as well as replace the empty topbench archive)
On the plus side, I have screenshot photos of most of the interesting stuff, but the archive compilation itself was nice.
It also turns out that crash was caused by cache instability ... I'd been trying the 43.75 MHz FSB configuration again, this time without cache wait states on and didn't provide extra cooling to the cache. Trying that again later, after backing up the repaired DOS install was actually successful, but still not a stable configuration for running most programs. Also it's not objectively impressive, but for a 1991, ISA only board it's quite good. OTOH with cache wait states enabled at 131 MHz the ST486DX-4 is about the same (or slower for some things) than at 4x40 MHz, and the board as a whole is more stable there. There's also no way I can see to add write cycle wait states, so DRAM stability at higher bus speeds is also difficult, and it seems to be more finicky with 4MB SIMMs than 1MB, but I've only got one or maybe 2 1MB 60 ns simms but more than a dozen 4MB ones, and sorting through the fastest 70 ns modules I had still didn't quite get there. (I'm not sure how I could get it to actually do 50 MHz FSB as it's marked for)
And while the Cyrix based DX2 and DX4s (and shot period testing of the 5x86) all seemed pretty solid performers in the Symphony board and the actual 5V rated AMD and Intel DX2s and Intel DXs all seem to go OK, it doesn't overclock the AMD and Intel CPUs as well as the Opti or SiS based boards (the AMD DX2 66s tend to run fine at 80 MHz in the other boards and Intel DX2-50 does fine at 80 MHz as well) they do run fine at stock settings or sometimes at smaller overclocks (the DX2-50 is fine at 66 MHz). However, the .5 micron AMD CPUs seem to have weird issues that may be related to running at 5V or may be BIOS or chipset related, plus the 2 DX2-80s are stuck in 3x multiplier mode which would be fine if they overclocked even a little or even went OK at 27x3, but in all cases they threw errors when loading Quake, though most other things worked OK.
OTOH that other SiS 496 based board handled the .5 micron AMD chips fine and overclocked the DX2-80s to 3x40 MHz at 3.98V and would POST at 150 MHz for the AMD DX4-100 but wouldn't boot anything. If I could find the 2x multiplier jumper I suspect it would do 2x66 MHz, though, and as it was seemed to be happy at up to 120 MHz at lower voltages, possibly down to 3.3V if kept really cool, but I did most of the testing at the 5.51 or 3.68V settings.
I also confirmed that it is indeed something related to the vintage of board/BIOS (1994) that makes it behave badly with 3x multiplier Cyrix CPUs and is presumably attempting to set-up certain things at non-default settings given those same CPUs work better in even older boards with no support for Cyrix 486DX2 let alone DX4 CPUs. All the Cyrix/IBM/ST 486 DX2 models I tried in that board worked properly, albeit limited to running at 3.98V max, which undervolted several of them. (interestingly, the 5V ST DX2-80 which will not even POST at 100 MHz, seemed to be fine with 3.98V at 80 MHz, though I've seen one or two other CPUs that are a bit like that: tolerant of under-voltage but poor overclockers)
So at least without a BIOS update, that board is better for the AMD x5 CPUs since they at least get detected as Enhanced AMD 486 DX4s and seem to work properly, though are set to write-through mode for some reason. (I don't know why since Enhanced AM486s had WB cache and should either have that enabled or have a selection option in the BIOS ... since the BIOS does properly identify that feature at POST)
I suppose it could also be something weird related to the GUI BIOS of that board, that and the very similar one of the Soyo board which won't POST any DX4 CPUs at all.
I think I also forgot to mention that the Acorp board does have an L1 cache policy select option in the BIOS, but it only appears when Cyrix CPUs are installed and disappears for others. The GUI BIOS of the Soyo SiS 471 and other 496 board have those options grayed out and unselectable with non-Cyrix CPUs but still visible. (though, again, they don't seem to work properly with Cyrix DX4 or 5x86 CPUs while DX2s are fine and I don't have any working DX or SX 1x multiplier models to test)
My take-away so far for Cyrix/IBM/ST 486s is that they at least seem to be more compatible and reliable with older boards. On top of that, they had some of the fastest, formally 5V rated/tolerant CPU models available. On top of that, they have faster external memory performance than AMD and Intel 486s (at identical settings) and seem to tolerate tighter cache and DRAM timings than AMD or Intel parts, further widening that gap.
The external I/O bandwidth seems to push the Cyrix 486s ahead in Speedsys scores and some other benchmarks (probably most productivity related ones, but also some graphics/games ones like PC Player: the 640x480 VESA mode PC Player benchmark seems to really like fast memory performance)
Ignoring the overvolted ST DX4 CPUs, the Cyrix/ST 5V 486DX2-80 should have been a really appealing upgrade option for Socket 1 boards capable of being configured at 40 MHz. That and the 5V 66 MHz rated DX2s seem to overclock fairly well along with the 3.x V ones (and I'm still not sure which the IBM BL DX2 is). Plus you still get another big speed boost if you upgraded the board later on and re-used the old CPU in a 1996 vintage PCI or VLB board.
Plus, if you had decently fast RAM there was still the SIMM extender/expander/saver style adapter route. That's what my Dad used in a couple of our 486 or Socket 5/7 era builds: actually most of those modules are in storage, still populated, I think with 70 ns FPM DRAM. (not sure what we used for video cards: as of 12 years ago, we had no VLB cards in storage, a single ATi Graphics Ultra ISA card, and the oldest PCI video card was a Diamond Stealth 2000 S3 ViRGE 325 with 1996 dated BIOS V1.01)
That Virge also does fine at 40 MHz but will not do 50 or higher without issues, mostly with VGA palette corruption, possibly specifically limited to the RAMDAC's palette RAM. 256 color VESA/SVGA modes seem to avoid this entirely ... so Tomb Raider at 640x480 works fine, as does PC Player, and same for Terminal Velocity, but anything using mode 13h or unchained VGA mode X/Y end up with corrupt colors but not framebuffer RAM errors. Presumably 320x240 using VESA graphics modes and not VGA-compatible modes would also avoid the palette errors and also use the same linear framebuffer organization as 320x200 VGA 13h and 640x480 VESA.
I'm not sure what's going on with Quake as it's missing the VESA resolution options in DOS but has most or all of them in my Windows 98 build ... that or all those are just really high-res unchained VGA framebuffer modes. (does Quake insist on having enough video RAM for 4x pages/framebuffers like Doom uses? ... in that case the limited resolution options with 512k 1MB or 2MB video cards would make more sense, but still not explain all the restrictions I see ... or maybe an issue with me running the cards driverless in DOS)
I'll have to try S3D accelerated games at 50-66 MHz PCI at some point or DirectX.
I assume as sluggish as it can be, the S3D version of Tomb Raider is faster than software rendering at 640x480 on a 486 in the 80-120 MHz range, especially if there were actual detail setting options or command line tweaks. (Tomb Raider tends to look a bit weird with texture filtering anyway ... even Tomb Raider 2 does, but perspective correction and highcolor rendering is nice ... or well, I'd probably prefer nicer shading and lighting with 320x240 24-bit truecolor mode on the ViRGE ... I do in Tomb Raider 2 except it's got those weird rendering errors around the HUD and health bar in Direct X)