I'd suggest you run MemTest86+ on your computer and see if it finds memory errors.

80 ns seems really slow memory for a 486 and is more common on 286 or 386.
I remember 70 ns FPM and 60 ns EDO memory from the 486er days.

Viper VLB is a nice card, the Weitek GPU is really uncommon, but I doubt ist has anything to do with your problem.

Why do you suspect issues with the video card if problems started when you added extra memory?

I agree with eisapc, I suspect your 80ns memory is too slow, at least for the current settings.

Getting a bit rusty, but if I recall correctly, with a 25MHz bus, memory cycles were 80ns, with 40ns extra per wait state. You're running at 33MHz bus so 80ns RAM would be run out of spec unless you add an extra wait state. It that's correct, your issues would go away if you lower the system clock from 33MHz to 25MHz (running your CPU as a 486DX2-50) and/or add a memory wait state in BIOS.

Of course both of those are bad for performance, but if they solve the issue you know the slow SIMMs are the cause and getting faster ones would be a good idea.

Thanks everyone - much appreciated.

Because the machine works flawlessly in DOS (I have left it to run all day, and it never freezes under DOS), and passes all the POST memory tests, I tend to believe that the RAM is OK, and the 486DX2/66 is accessing it just fine. It is only in the Windows environment that there is an issue, and only after 15 - 20 of running. Until then, even Windows operation is flawless.

Upon further reflection, this SUGGESTS to me a software error in the Viper Win 3.1 driver - running out of some form of resources after a particular amount of run time at a fixed consumption rate (of whatever the resource in question is).

Perhaps???? .... those drivers were installed when the machine had 8 MB of RAM. That was changed under its feet to 16 MB of RAM. Is it possible that some of the Viper's RAM is being mapped into a space that collides with Windows' newfound use of the address space above 8 MB and after some time of being up, the two run into each other?

@douglar, thanks, I will hunt down and run MemTest86+ just to be sure. I am hoping that Norton Diags should do an equally effective job, but one never knows!

@dionb, thanks as well - I will add one wait state to RAM read and write cycles via the BIOS (presently set to zero wait states) and see if that helps at all.

Next steps:
1/ Add a wait state to RAM accesses
2/ Extensive RAM testing to be sure that the RAM itself and the CPU-RAM bus interface is working without error
3/ Downgrade the Viper Windows 3.x driver from its current 2.10i status, which was billed as "experimental" and back to 2.04, which I believe was the last stable version released. If a bug in the 2.10i driver is behind the weirdness I am seeing, this should resolve it, or at least change its behaviour. I have also found a 2.0705 version, which I may try as well.

Thanks again everyone and I will keep this thread updated with results as they come in.

mac57mac57 wrote on 2025-01-17, 15:00:

Thanks everyone - much appreciated.

Because the machine works flawlessly in DOS (I have left it to run all day, and it never freezes under DOS), and passes all the POST memory tests, I tend to believe that the RAM is OK, and the 486DX2/66 is accessing it just fine. It is only in the Windows environment that there is an issue, and only after 15 - 20 of running. Until then, even Windows operation is flawless.

Still sounds like memory issues - in DOS you almost certainly never use more than 2MB or so, so any problems with the second 8MB you've installed won't trigger anything. On Windows, extra RAM is used for things like disk caching and fills up, triggering any problems with RAM.

mac57mac57 wrote on 2025-01-17, 15:00:

@douglar, thanks, I will hunt down and run MemTest86+ just to be sure. I am hoping that Norton Diags should do an equally effective job, but one never knows!

Try Memtest86+ v2.11 from here: https://www.memtest.org/archives
Let it run for a while. Like 24 hours, if that's an option.

I agree with Dionb. DOS only uses a limited portion of the memory space with any sort of intensity. I bet the VLB card driver is using a bank of EMS very intensively that DOS doesn't really pound on very hard.

Sounds like a memory issue to me too. Swap the simms around so that the slow one is first to see if dos hangs.

Thanks all, and the mystery has been solved. The new RAM passed every memory test I could throw at it, and I have a dozen or so of them that I could hit it with. When the RAM came back "clean", I started guessing that it was some form of wait state issue between the GPU and that RAM, since the new RAM is a bit slower than the old RAM it replaced. I consulted the manual for the Diamond Viper VLB video card that is in the system and found a jumper for (a) "Zero Wait States" and (b) "Normal". It was set for zero wait states, and so I set it for "Normal" even though what "normal" was wasn't defined by the manual. However, this change too made no difference.

At this point, my gut told me that this had to be a software issue, and most likely one of those where the Viper's driver was slowly consuming some form of Windows resource , and when that resource was exhausted, the machine would freeze. I tried monitoring free RAM and Windows System Resources, but neither of these showed any downward trend. Still, this just felt like a software issue to me, and so I decided to execute a strategy that has worked for me in the past. When all debugging efforts seem to lead nowhere, stimulate the test system with seemingly unrelated inputs and observe what the output is. This will often change the behavior of the system enough that you glean some additional information that points in the direction of the actual problem/solution. In this manner, I decided to do three things: (1) do a "clean" boot of DOS (no config. sys or autoexec.bat, except for loading HIMEM and EMM386, which Windows needs) and then go into Windows and observe if the freezing behavior changed in any way, (b) disable Windows 32-bit disk access and again observe the outcome and finally (3) unplug the network cable and again observe.

I didn't get past (1). That solved it! After a "clean" boot into DOS followed by starting Windows, Windows remained stable and ran for over an hour before I stopped the test. This confirmed that it WAS a software issue. I guessed some form of conflict between what was being loaded in config.sys/autoexec.bat and Windows itself. I could have exhaustively added things back to the "clean " boot versions of config.sys and autoexec.bat and watched each time to see what happened, until I found the culprit, but at this point I let inspiration take over. A little voice in the back of my head told me that the EXPLOSIV.COM DOS screen saver was the most likely source of the problem, and so I restored config.sys and autoexec.bat back to their full and original state and simply commented out the load of EXPLOSIV (which goes in as a TSR) in autoexec.bat. That was it - that did it! With EXPLOSIV not loaded, Windows again ran for over an hour before I terminated the test.

So, I can only conclude that EXPLOSIV, which is set to run after 15 minutes of inactivity, was starting up even when Windows was running, and in the process, was conflicting with Windows in a sufficiently destructive way as to freeze the machine. So, a poorly behaved DOS screen saver was "taking out" Windows after 15 minutes of run time, every time.

This is the "fun" of DOS and Windows - when things go wrong, they often don't provide meaningful error messages or worse, they provide misleading error messages, or even worse, something apparently unrelated goes wrong, pointing the debugging effort into totally the wrong direction. The "fun"? You have to apply a LOT of creative and critical thinking to the issue and try to suss out the root cause. This is rarely easy and often takes quite a long time.

In this case, everything pointed to an incompatibility with the new RAM, and yet the incompatibility was with an old screen saver. That incompatibility had been there since I installed the screen saver a year ago or so. It is just that until recently, I had not run Windows long enough since the DOS screen saver was installed to encounter the problem. This only happened when I was running what I thought were stability tests for the new RAM. Sheesh!

Anyway, thank you ALL for your thoughtful comments and suggestions! MUCH appreciated!

Interesting twist - nicely found 😀

For what it's worth:

I consulted the manual for the Diamond Viper VLB video card that is in the system and found a jumper for (a) "Zero Wait States" and (b) "Normal". It was set for zero wait states, and so I set it for "Normal" even though what "normal" was wasn't defined by the manual. However, this change too made no difference.

It wouldn't have, even if the RAM had been the problem. This sets the VLB wait states for the Viper card, not for the system RAM. Those need setting (if possible) in system BIOS.

Thanks, @dionb. It certainly was not clear what those Viper wait states were for - I was hoping it was for the GPU's accesses to main RAM. It could also however, as you so correctly point out, be related to the accesses from the GPU to the onboard RAM on the card... Either way, it would not have impacted the issue or the solution, given the nature of that solution.

mac57mac57 wrote on 2025-01-21, 05:16:

Thanks, @dionb. It certainly was not clear what those Viper wait states were for - I was hoping it was for the GPU's accesses to main RAM. It could also however, as you so correctly point out, be related to the accesses from the GPU to the onboard RAM on the card... Either way, it would not have impacted the issue or the solution, given the nature of that solution.

It's neither, it's about the communication on the VLB bus between CPU and the Viper card. VLB communication usually works without wait states up to 33MHz, beyond that (40MHz, 50MHz) a wait state is commonly required. This is partly dependent on the capabilities of the chip on the card, but also on the physical implementation on the motherboard and on how many VLB cards you have (1 tends to be rock solid, 2 can get wobbly at speed, 3 is asking for problems).