sedrosken
Florida Man
You end up with strange issues with older machines. In another effort to get just a little more performance out of my 486 -- I really, really just wanted to see Diablo play smoothly on it, and seeing 32-channel XM modules play smoothly would be nice as well -- I've managed to source a few PGA168 interposers that offer a way to force a 3/4x multiplier for boards without support for that, and voltage regulation to take the 5v the board provides down to the 3.3v that won't fry newer CPUs. I used the Am5x86 I'd previously used with the M912 board, and thankfully it's not fried -- initially I had the sort of success that I never do, everything just worked. CPU-Z made the thing BSOD, but that was actually down to the VxD it generated to get access to the CPUID I suppose -- deleting the old one and letting it remake it solved it.
No, I dipped back into the case and noticed I had some residue on the AA batteries where I'd superglued the holder to the power supply in lieu of using less-permanent mounting options, as the others I'd tried lost their adhesion after a while. Without thinking I removed the batteries to clean this off, and lost all my CMOS settings. When going through and resetting all those settings, I have a few that actually have a reputation for being unstable on this class of hardware; namely, I have everything (cache, RAM, local bus) set to zero wait-states, and I'm both shadowing and caching an option ROM at address D000-D7FF. You can see why I initially thought one of these other settings must have been causing the problems I'll describe in a moment -- they are known to cause instability on other 486-class machines, and while they worked reliably here before, maybe something changed with the upgrade I did.
When booting, particularly in my normal configuration loading EMM386 and then initializing my sound card at address 220h, interrupt 5, low DMA 1, and high DMA 5, with the MIDI port at 330h, the machine would totally freak out, drop to 40-column text mode, and then display an error message that seemed pretty unsure of itself:
"MEMORY PARITY ERROR ????"
It turns out that I'd inadvertently toggled the Gate A20 Emulation setting from Chipset to Fast. For those unfamiliar, this dictates how expanded memory is accessed, and as most 386+ DOS configs make use of EMM386 to provide expanded memory emulation using extended memory for applications requiring it, it's a surprisingly important setting. On later machines I'm sure this works fine in Fast mode, indeed I remember it causing no issues back when I had the Pentium Pro machine. However I'm guessing that the UM480, being a combination 386/486 chipset made at a time when some people still used genuine expanded memory cards, might just be early enough that it's got some weird bugs with that mode of operation.
One CMOS setting had the 486 out of commission for weeks between me not having time to diagnose further and simply having no idea what could possibly be wrong. Imagine my terror when swapping back to the DX4 OverDrive, a known-good CPU, didn't fix the problem! I reseated and used deoxit on the contacts of all my RAM and every add-in card, several times, swapped hardware around, and only when I decided to try loading the BIOS defaults on a whim did I fix it purely by accident.
Ironically this is still not the final chapter -- I want to find a specific model of AMD DX4 CPU, one rated for 120MHz operation (so I can use the 40MHz crystal and run a 40MHz system bus) but that only has 8K of L1 cache, as I'm almost completely certain that's what's tripping up the chipset as far as enabling L2 cache -- these later chips all have 16K. When I finally find one of this specific model that doesn't come from China, doesn't cost two hundred dollars, or perhaps both, I'll have one last thing to test. Thankfully I do have the 12ns cache chips floating around from my M912 misadventure, so if/when I get that working I'll have faster cache for 0WS operation at 40MHz.
No, I dipped back into the case and noticed I had some residue on the AA batteries where I'd superglued the holder to the power supply in lieu of using less-permanent mounting options, as the others I'd tried lost their adhesion after a while. Without thinking I removed the batteries to clean this off, and lost all my CMOS settings. When going through and resetting all those settings, I have a few that actually have a reputation for being unstable on this class of hardware; namely, I have everything (cache, RAM, local bus) set to zero wait-states, and I'm both shadowing and caching an option ROM at address D000-D7FF. You can see why I initially thought one of these other settings must have been causing the problems I'll describe in a moment -- they are known to cause instability on other 486-class machines, and while they worked reliably here before, maybe something changed with the upgrade I did.
When booting, particularly in my normal configuration loading EMM386 and then initializing my sound card at address 220h, interrupt 5, low DMA 1, and high DMA 5, with the MIDI port at 330h, the machine would totally freak out, drop to 40-column text mode, and then display an error message that seemed pretty unsure of itself:
"MEMORY PARITY ERROR ????"
It turns out that I'd inadvertently toggled the Gate A20 Emulation setting from Chipset to Fast. For those unfamiliar, this dictates how expanded memory is accessed, and as most 386+ DOS configs make use of EMM386 to provide expanded memory emulation using extended memory for applications requiring it, it's a surprisingly important setting. On later machines I'm sure this works fine in Fast mode, indeed I remember it causing no issues back when I had the Pentium Pro machine. However I'm guessing that the UM480, being a combination 386/486 chipset made at a time when some people still used genuine expanded memory cards, might just be early enough that it's got some weird bugs with that mode of operation.
One CMOS setting had the 486 out of commission for weeks between me not having time to diagnose further and simply having no idea what could possibly be wrong. Imagine my terror when swapping back to the DX4 OverDrive, a known-good CPU, didn't fix the problem! I reseated and used deoxit on the contacts of all my RAM and every add-in card, several times, swapped hardware around, and only when I decided to try loading the BIOS defaults on a whim did I fix it purely by accident.
Ironically this is still not the final chapter -- I want to find a specific model of AMD DX4 CPU, one rated for 120MHz operation (so I can use the 40MHz crystal and run a 40MHz system bus) but that only has 8K of L1 cache, as I'm almost completely certain that's what's tripping up the chipset as far as enabling L2 cache -- these later chips all have 16K. When I finally find one of this specific model that doesn't come from China, doesn't cost two hundred dollars, or perhaps both, I'll have one last thing to test. Thankfully I do have the 12ns cache chips floating around from my M912 misadventure, so if/when I get that working I'll have faster cache for 0WS operation at 40MHz.