Do you run Doom under 9x ?

if it freezes in plain dos, try it in 9x and report 😁

Have you run memtest86 ? And also did you try a unmodified bios ?

Replace dos4gw with a different version...

But did Doom run with the vortex 2? It was incompatible with many pci sound cards. Why don't you keep just the soundblaster in?

Quake doesn't use Mode Y. Does Doom run stable with no sound? I don't know any other Mode Y games, but Mode X or Q might be close enough:
- Lost Vikings
- Rolling Ronnie
- Epic Pinball
- Dyna Blaster

You can also try: https://github.com/mills32/Little-Game-Engine-for-VGA

matze79 wrote:

Do you run Doom under 9x ?

As mentioned in the original post, it seems more stable under 9x. But need to do a longer session still since it sometimes likes to troll me.

But I wouldn't be surprised as Windows 98 seems to be able to initialize the chipset in a way that the BIOS fails to do.

derSammler wrote:

Replace dos4gw with a different version...

Worth a try.

Deksor wrote:

Have you run memtest86 ?

Yes. I if I recall correctly it survived a 24 hour run. Probably wouldn't be a bad idea to do a longer run just to be sure though.

However, do note that I tried another, different kind of, RAM module with the exact same results so I would think the odds of the same failure is kind of slim. Even tried the other RAM slot.

Deksor wrote:

And also did you try a unmodified bios ?

Worth considering especially since there exists a newer BIOS than the one that was modified. This is fairly high on the pain scale since I know I wasn't able to go back to the modified BIOS without using the external programmer.

dondiego wrote:

But did Doom run with the vortex 2? It was incompatible with many pci sound cards. Why don't you keep just the soundblaster in?

Guess I should have specified on the list of things I tried that "video+sound" meant "Voodoo+SB32."

As an unrelated aside, I really have not had much of a problem with PCI sound cards personally. Besides the annoyances that come with having to load a TSR anyway. The SB32 is in there for DOS and the Vortex 2 is only active in Windows 98SE (with all SB emulation disabled since the SB32 takes care of that).

Rawit wrote:

Does Doom run stable with no sound?

Will have to double check but I'm pretty sure I tried this to no avail.

Rawit wrote:

I don't know any other Mode Y games, but Mode X or Q might be close enough: - Lost Vikings - Rolling Ronnie - Epic Pinball - Dyn […]
Show full quote

I don't know any other Mode Y games, but Mode X or Q might be close enough:
- Lost Vikings
- Rolling Ronnie
- Epic Pinball
- Dyna Blaster

You can also try: https://github.com/mills32/Little-Game-Engine-for-VGA

Will try those out after my business trip.

24 hour memtest run ? wow ! Well sure it won't hurt running it for longer but I think it's not worth the time, the issue should come up far quicker since you can easily trigger it with doom.

Was able to do a few more runs today, but still need to get to all of the suggestions. No disabling sound does not fix the crash. Running at 95MHz FSB allows me to complete all three episodes of Doom in a single sitting (100MHz freezes on E1M1 most of the time). Running 100MHz under Windows 98SE also allows me to complete the whole game.

Running memtest86+ now. Thinking more about my run I may have ran the DIMM in my Tualatin to test it as I figured it would be able to do more passes in 24 hours than the K6 would be able to do. Cursory testing shows that memtest86+ may also be freezing with the 100MHz FSB, although need to make sure that's consistent. Running 95MHz right now to try to get a baseline.

Experimented with memtest86+ over the weekend and Monday. At 95MHz FSB the whole 256MB range is stable (25 hours 15 passes). At 100MHz memtest is stable from 0-0x1A0000 (2 hours 180 passes) and from 0x1C0000 on up (7.5 hours 5 passes). So it's like something is being memory mapped somewhere between 0x1A0000 and 0x1C0000 which causes the system to go unstable. The reason I say "go unstable" is while memtest consistently freezes in test 4 if left alone, if the lower bound is set somewhere in that range it will often cause errors to occur somewhere in 0x1EXXXX but only after 4 passes of memtest. (And it's pretty consistently the 4th pass.) Similarly when testing the lower range the errors tend to occur somewhere around 0x17E00-0x1A600. Usually below 0x1A0000. If it doesn't outright halt with a stack trace or just halt before anything can be printed to the screen (which is the most common case). But those very same addresses seem to be just fine as long as nothing in that range is touched.

If only there was some way to black hole that memory range (or the entire 2nd megabyte) then the system would be stable from what I can tell. I know Linux and NT can do this, but not aware of any driver for DOS that's capable of marking that range reserved.

Still want to try the other suggestions (especially seeing if the 1122 BIOS changes anything in this regard) but this does seem to have narrowed the problem down to a specific 128KB of memory.

And as stated before this isn't specific to the DIMM, I've tried 3 other DIMMs with one being PC100 instead of 133 and they all fail at the same addresses.

From your text I get that the issue pertains even when you disable L2 cache which may hint at damage to the north bridge given it not only occurs with the K6-III?

Being able to run in Windows but not Dos could hint at the program being loaded into a different region when compared to DOS and thus masking the issue. This is a theory of mine, so no guarantee - I have no idea how windows treats a DOS program using a DosExtender exactly.

The crash in Doom has nothing to do with the screen mode but occurs most likely during texture "lookup"/reading when drawing the "world's" columns. Does the freeze "feature" vertical bars?
The other games you mentioned do use a less sophisticated approach than Doom, so they are not as "fragile" in this regard.

Not sure why I didn't think of it before but tried Doom with EMM386 and the freeze seems to be gone there and different information is given for where Doom is allocating memory at startup.

This weekend also tried Quake in vid_mode 1 (mode X style 320x200 instead of what I assume is 13h with vid_mode 0). Also tried vid_mode 10 because why not and one of the few higher res modes that the CRT I'm using can display. No issues.

Epic Pinball is stable. Need to setup another monitor for the other games mentioned since the CRT I have setup right now is really picky about display modes (old VGA CRT from memorex telex 286).

amadeus777999 wrote:

From your text I get that the issue pertains even when you disable L2 cache which may hint at damage to the north bridge given it not only occurs with the K6-III?

If this freeze is in any way related to the freeze I was getting in Quake before I found out how to get the system into write back mode then I would have strong reason to believe that the issue is exclusive to using the K6-III+ CPUs. I don't really want to swap the CPUs right now since I feel like given how much mounting pressure is on the CPU right now there's a good chance I'd break the socket getting the heat sink off. May test in the future if I can manage to get my hands on another board. (I have another K6-III+ but it seems to be a worse overclocker "only" reaching 550MHz. To be fair though the one I'm using now only reached 570MHz until I replaced the cooler. But also have a K6-2 CXT, K6-III, and K6-2+ from when I was trying to figure out what was up with Quake.)

I would say, however, that actual damage to the north bridge seems rather unlikely unless someone else has an M5ALA and can confirm that with the plus CPUs they have no such issues. I would think a 128KB no touch zone would be an oddly specific failure for hardware. Especially given that it's a 100MHz vs 95MHz FSB issue. Wouldn't you expect a repeating pattern if something was wrong with the chip?

amadeus777999 wrote:

Being able to run in Windows but not Dos could hint at the program being loaded into a different region when compared to DOS and thus masking the issue. This is a theory of mine, so no guarantee - I have no idea how windows treats a DOS program using a DosExtender exactly.

Seems that way.

amadeus777999 wrote:

The crash in Doom has nothing to do with the screen mode but occurs most likely during texture "lookup"/reading when drawing the "world's" columns. Does the freeze "feature" vertical bars?

The crash either looks like this or is a pure freeze with no visual errors.

It's impossible to state a definite reason given all these factors. Nonetheless interesting but kinda sucks that it's not stable.
The picture you posted is typical for mem/cache issues. All 486s I tested which had a "lazy" sram showed it.

Digging through some documentation it looks like a legacy feature of HIMEM may be able to save the day. Apparently HIMEM has an /INT15 switch which takes an amount of memory to reserve for a legacy non-XMS way of allocating memory. I've set this to 1024 (thus 1 megabyte) and cursory test seems to indicate that Doom is stable, but need to actually do a full test pass on it when I have time. If my understanding of everything is correct setting this to about 768 should be enough to cover the memory hole.

Another possible way to keep programs from accessing that memory may be to create a small ram disk.