kixs wrote:

2) The benchmark results are not reflecting reality, though. I distinctly remember playing two video games back in ~1994 on my 386SX40: One Must Fall 2097, and Warcraft I. Both games ran very well, even with sound. Neither game runs anywhere close to acceptably on this Am386DX-40, even with sound disabled.

Taking this into consideration... the problem is your VGA card. If you have any other (even Trident 8900D/CL will be better) test it.

Download Phil's DOS benchmark suit and run 3DBENCH, PCPBENCH, DOOM and post results.

I'll do as you suggest, but it doesn't seem like any of those tests are "clean" enough to demonstrate that it's the video card's fault. Seems like a better idea would be to whip up a program in ASM that would just blit very simple patterns to the framebuffer in a loop and time how long it takes to do so, so that cache/RAM problems could be eliminated. I could even unroll the loops into straight op codes so that nothing but the CPU registers would be involved.

Doom, especially, is going to involve all kinds of other aspects of the system in its performance.

All that being said, I'll do as you suggest. I've been using Phil's DOS benchmark suite for months and I do pay attention to the results of the included programs, but they can be hard to interpret in cases like this.

Also, I have a Tseng Labs ET4000AX in transit to my house, but it won't be here until tomorrow or Friday. Until then, the only alternative video cards that would work in this 386 system are a VLB Mach32 card(which is currently installed my 486 system), and a VLB Trident card which is sitting on my work table. I don't think I have any plain ISA video cards lying around, but I'll check when I get home.

Other than raw performance of the VGA card itself, can you think of any reasons why it could be the source of the problem?

It's simple. Some cards are slower some are faster. OTI are usually pretty slow. Even slower then Trident. Tseng should be the fastest among these. 3Dbench will show you the difference in FPS. Between slow and fast there could be 5-6FPS difference or ~30% if you like it better. And this is very noticeable in games.

I know this first hand when in 1992(or 93) I replaced only the motherboard. Going from 286-16 to 486slc-33 and in games - especially F1GP that has cpu usage indicator. There wasn't much improvement. I was very disappointed. By pure coincidence a few weeks of the purchase I tested Trident 8900D in my system. I couldn't believe the difference. It was huge! Like it was supposed to be in the first place. But VGA card slowed it down. My card was 16-bit Chip&Tech... probably even slower OTI. Imagine if I had tested it with a Tseng 🤣 I might even do the comparison one day as I have all the necessary parts 😉

As already said... it would be useful if you post the BIOS settings and get that lost 10-15% of cpu power back 😀

kixs wrote:

It's simple. Some cards are slower some are faster. OTI are usually pretty slow. Even slower then Trident. Tseng should be the fastest among these. 3Dbench will show you the difference in FPS. Between slow and fast there could be 5-6FPS difference or ~30% if you like it better. And this is very noticeable in games.

I know this first hand when in 1992(or 93) I replaced only the motherboard. Going from 286-16 to 486slc-33 and in games - especially F1GP that has cpu usage indicator. There wasn't much improvement. I was very disappointed. By pure coincidence a few weeks of the purchase I tested Trident 8900D in my system. I couldn't believe the difference. It was huge! Like it was supposed to be in the first place. But VGA card slowed it down. My card was 16-bit Chip&Tech... probably even slower OTI. Imagine if I had tested it with a Tseng 🤣 I might even do the comparison one day as I have all the necessary parts 😉

As already said... it would be useful if you post the BIOS settings and get that lost 10-15% of cpu power back 😀

Note how I said "Other than raw performance of the VGA card itself...", but ok.

I knew that Oak Technologies cards weren't fantastic, but I didn't think a VGA card from them would make THIS much of a difference. Until I show you guys a video of what I'm talking about, you won't understand. When I run Warcraft I on the fastest speed setting on this Am386DX-40, it performs like it's on the slowest speed setting on a 486DX2-66. It's unplayable. To put it in concrete FPS terms, it would be like getting 4FPS instead of 60FPS at 320x200x8bit. That difference does not seem like it can be chalked up to a video card's performance, but I admit I could be wrong. I'll certainly know soon enough; this is a matter of empirical evidence. 😉

Re: BIOS settings and getting 10-15% performance increase...no. I didn't bother to post the settings I tried last night, but I did get it to be stable with 0WS write and 0WS read, with 3-2-2-2 timing. The benchmark came in at ~31.5 instead of ~30.0, which is only a 5% increase. Games still ran like complete shite, of course. There aren't any other relevant BIOS settings to play with, so it's got to be something at the hardware level.

aquishix wrote:

Re: BIOS settings and getting 10-15% performance increase...no. I didn't bother to post the settings I tried last night, but I did get it to be stable with 0WS write and 0WS read, with 3-2-2-2 timing. The benchmark came in at ~31.5 instead of ~30.0, which is only a 5% increase. Games still ran like complete shite, of course. There aren't any other relevant BIOS settings to play with, so it's got to be something at the hardware level.

Oh. Good luck then.

konc wrote:

aquishix wrote:

Re: BIOS settings and getting 10-15% performance increase...no. I didn't bother to post the settings I tried last night, but I did get it to be stable with 0WS write and 0WS read, with 3-2-2-2 timing. The benchmark came in at ~31.5 instead of ~30.0, which is only a 5% increase. Games still ran like complete shite, of course. There aren't any other relevant BIOS settings to play with, so it's got to be something at the hardware level.

Oh. Good luck then.

If you really want me to post screenshots, I can post them. There are something like 64-128 combinations of these timing settings that I could try, so I'm assuming you don't want to see all those results. What do you want to see, exactly? Default, and best achieved? I just spelled out what best achieved was in text form, and everyone knew what the defaults were causing...so I didn't see the point in posting the screenshots. I'm not being purposefully obstinate.

There are many combinations but only some are relevant. Also decrease the timings for cache to less then 3-2-2-2 which is the slowest possible. 2-1-1-1 is fastest.

kixs wrote:

There are many combinations but only some are relevant. Also decrease the timings for cache to less then 3-2-2-2 which is the slowest possible. 2-1-1-1 is fastest.

Clearly.

And 2-1-1-1 crashed the machine upon boot. I think 3-1-1-1 crashed as well in a different way, and 2-2-2-2 worked but had no noticeable impact on performance. Only setting the wait states to 0 for read and write improved performance, and then only by 5% in a synthetic benchmark; no noticeable improvement in any game.

I really am wondering at this point if this is a RAM incompatibility problem.

Most BIOS's have different options. What I'd like to see is what options are there. Therefore pics are good 😉

kixs wrote:

Most BIOS's have different options. What I'd like to see is what options are there. Therefore pics are good 😉

I've attached 5 images. The first two show the two relevant BIOS screens with BIOS defaults. The third is an image of the Symantec system benchmark resulting from those settings. The 4th and 5th images show the best BIOS settings I could come up with, and the resulting benchmark results.

NB: I know I should've changed that 64MB cacheable RAM amount to 4MB because the system currently has 4MB in it; I did that after I took these pictures and it made no difference in performance or anything else.

Couple of other things to note:

1) I received that ET4000 card today, ahead of schedule. I installed it and it definitely improved the video performance, but it didn't have any(at least not much) visible impact on the speed of Warcraft I. It just seems to speed up text being displayed to the screen while in 80x25 text mode in DOS, the BIOS menus, and the POST screen.

2) I took out 4MiB of RAM from the previous 8MiB total, ran the benchmarks (and played Warcraft I) and saw no change. I swapped in the 4MiB I had removed instead, with similar non-results. So the RAM doesn't appear to be a problem.

😢

It's dead simple: Unless you change your "Cache Read Wait State" to something that doesn't start with 3-x-x-x, you're stuck with low 30s in sysinfo.
Yes, I'm 100% certain about this, just this setting and nothing else. And no, I don't believe that you tried 2-2-2-2 "but had no noticeable impact on performance". Try it again please.

(Apparently your cache can't cope up with 2-1-1-1, your RAM can with 0 WS)

These are pretty basic advanced BIOS settings. You can set AT BUS clock to something faster. Go by steps but it should work CLK/3 or CLK/2 too (if you have them of course). This will improve video performance.

Perhaps you already know this, but these systems are pretty 'dumb', so just changing memory or cache chips does not affect performance by itself, since the chips do not carry any kind of configuration info, and the system cannot configure itself.
You need to manually optimize the settings for the memory/cache that is installed. So if you swap it out, you need to re-test all settings to find the optimum.

If you have an ISA multi-IO card around, I would suggest testing the system with that card installed (so no VLB cards). It could be that the VLB implementation is bugged, and is dragging down performance.
A friend of mine had a 486 with ISA, VLB and PCI. We found that when a VLB card was inserted, that all ISA slots were also running at very high speed. Effectively this meant that sound cards didn't work properly. The sound was garbled, or games even got corrupted/crashed altogether. So the VLB bus on that system was unusable.

konc wrote:

It's dead simple: Unless you change your "Cache Read Wait State" to something that doesn't start with 3-x-x-x, you're stuck with low 30s in sysinfo.
Yes, I'm 100% certain about this, just this setting and nothing else. And no, I don't believe that you tried 2-2-2-2 "but had no noticeable impact on performance". Try it again please.

(Apparently your cache can't cope up with 2-1-1-1, your RAM can with 0 WS)

Will do.

I think that last night, I tried 2-2-2-2 and it got past the POST screen, past the boot loader, and then crashed when DOS tried to process CONFIG.SYS. A bunch of ASCII garbage flew across the screen for a second or two and then it locked up. I'll verify this when I get home this afternoon, but I'm pretty sure that's what happened. What is definitely the case is that every choice of cache read wait state resulted EITHER in a system crash at some point in the boot-up process, or marginal/insignificant impact on performance. (I.e., nothing in these BIOS changes has really helped.)

I'm not questioning your experience or analysis; I'm merely stating what I have observed on my own system.

Another thing that I'm thinking of trying is putting my spare 486DX2-66 CPU into the empty socket on the motherboard this afternoon, and changing the jumper settings appropriately. That will tell me if it's the CPU or something related to the CPU. At that point, it would seem to be narrowed down to either the VLB problem that Scali is suggesting, or some kind of resource conflict between the installed cards.

kixs wrote:

These are pretty basic advanced BIOS settings. You can set AT BUS clock to something faster. Go by steps but it should work CLK/3 or CLK/2 too (if you have them of course). This will improve video performance.

Well, I'm basing my reasoning on the "AT BUS Clock" section of this document: http://margo.student.utwente.nl/el/pc/bios/ami31.htm

Since my CPU is clocked at 40MHz, setting it to CLK/5 is the correct choice. Anything higher than that would be sketchy unless I knew for a fact that all 6 of my installed expansion cards can operate at a higher bus clock...wouldn't you agree?

At any rate, this doesn't *seem* to bear on the problem, because the CPU benchmark shouldn't be affected by the bus clock on the motherboard. This is one of those things that I'm sure Scali could weigh in on; I don't know enough about AT architecture to have a strong opinion. I'm sure it also depends on the exact technique(s) being used in the CPU benchmark. Again, I'm tempted to write my own.

Even after I replace this troublesome motherboard with a different one, I'll be tempted to figure out the root cause of all this simply so I can acquire some (useful?) technical knowledge.

Scali wrote:

Perhaps you already know this, but these systems are pretty 'dumb', so just changing memory or cache chips does not affect perfo […]
Show full quote

Perhaps you already know this, but these systems are pretty 'dumb', so just changing memory or cache chips does not affect performance by itself, since the chips do not carry any kind of configuration info, and the system cannot configure itself.
You need to manually optimize the settings for the memory/cache that is installed. So if you swap it out, you need to re-test all settings to find the optimum.

If you have an ISA multi-IO card around, I would suggest testing the system with that card installed (so no VLB cards). It could be that the VLB implementation is bugged, and is dragging down performance.
A friend of mine had a 486 with ISA, VLB and PCI. We found that when a VLB card was inserted, that all ISA slots were also running at very high speed. Effectively this meant that sound cards didn't work properly. The sound was garbled, or games even got corrupted/crashed altogether. So the VLB bus on that system was unusable.

Thanks for jumping in, Scali!

I did know that, and I've made a good faith effort to test (what seem like) the relevant BIOS settings upon any change in hardware on this system. As I've pointed out on this thread, nothing seems to help to any substantial degree. I'm really suspecting it's a VLB problem, but I don't know enough about how buses work to understand WHY that could be a problem. It's hard for me to see why a synthetic CPU benchmark would be impacted by what's going on between or on any of the installed expansion cards. I would think that a CPU benchmark would do little more than execute some basic arithmetic op codes with minimal data being loaded in, which would probably be in cache RAM anyway. Could it be something like an expansion card lighting up an interrupt request far too frequently, thereby preventing the CPU from performing the instructions at full speed on average?

I do have an ISA multi I/O card, but I can't remember if it works correctly or not. I'll try it out this afternoon.

Interesting anecdote about your friend's 486. Could that help explain why I can't get Star Control ][ to sound good with GUS? All three of my systems with GUS cards make it crackle, pop, skip, and generally sound like garbage. One is this troublesome 386 with a GUS Classic(and a VLB multi I/O card installed), one is a 486 with a GUS classic(and a VLB multi I/O card installed), and one is a Pentium-II with integrated I/O, with PCI slots. That Pentium-II system would seem to contradict that explanation, since it has PCI and ISA, but no VLB. It's just hard for me to believe that Fred Ford and Paul Reiche III would've screwed up something so basic as GUS compatibility, since they went out of their way to implement it in the first place in ~1993.

aquishix wrote:

Will do. […]
Show full quote

Will do.

I think that last night, I tried 2-2-2-2 and it got past the POST screen, past the boot loader, and then crashed when DOS tried to process CONFIG.SYS. A bunch of ASCII garbage flew across the screen for a second or two and then it locked up. I'll verify this when I get home this afternoon, but I'm pretty sure that's what happened. What is definitely the case is that every choice of cache read wait state resulted EITHER in a system crash at some point in the boot-up process, or marginal/insignificant impact on performance. (I.e., nothing in these BIOS changes has really helped.)

I'm not questioning your experience or analysis; I'm merely stating what I have observed on my own system.

Another thing that I'm thinking of trying is putting my spare 486DX2-66 CPU into the empty socket on the motherboard this afternoon, and changing the jumper settings appropriately. That will tell me if it's the CPU or something related to the CPU. At that point, it would seem to be narrowed down to either the VLB problem that Scali is suggesting, or some kind of resource conflict between the installed cards.

I think I already wrote what the problem with this system is, you need to change this particular setting and nothing else.
Earlier on you wrote "2-2-2-2 worked but had no noticeable impact on performance", which I openly doubted. In this post you wrote that it didn't work at all.
There is no other way to see a proper sysinfo result in the range of ~40. If it really doesn't work with 2-2-2-2, then you need to change your cache chips as well. Note that I'm talking particularly for the DX/40 processor, not a 2x33. You can theorize all you want about CPU or VLB problems, but that's not the case for your sysinfo result, I don't know any other way to say this more clear.

VGA performance is another thing of course, but how can you judge without bringing the CPU to normal numbers first?

If you still don't believe this I can post BIOS settings+sysinfo screenshots with only this option changed.

konc wrote:

I think I already wrote what the problem with this system is, you need to change this particular setting and nothing else.

You have made your position abundantly clear. I believe that you have good reasons for your position. But I do think you're ignoring some relevant facts. Go back and take a look at that FPU benchmark I posted. That is *severely* off from what it should be -- which is clear from the fact that the Am386DX-40 is explicitly listed as one of the reference benchmarks, and that's the CPU I have in this system! That suggests to me there's something screwy going on. Furthermore, the fact that Warcraft I runs like absolute crap even when the CPU benchmark is coming in at the performance level just above an Intel 386DX-25 supports that line of thinking. Go take a look at Blizzard's stated system requirements for Warcraft I:

Operating System: MS-DOS 5.0
Processor: Intel 386DX 20 MHz
Memory: 4MB RAM
Graphics Card: VGA graphics, 256-colors capable, 320 x 240 resolution
DirectX:
Sound Card: Sound Blaster compatible sound card
Hard Drive Space:
Drives: 3.5" Disk Drive or 2X CD-ROM Drive
Controls: Keyboard & Mouse
Multiplayer: 14.4 Kbps modem or IPX network card

So, if the CPU is benchmarking at something like a 386 @ 27MHz, and the system requirement is only a 386 @ 20MHz, AND the game is unplayably, unbearably slow, it tells me that taking this approach is misguided.

konc wrote:

Earlier on you wrote "2-2-2-2 worked but had no noticeable impact on performance", which I openly doubted. In this post you wrote that it didn't work at all.

I should've been more careful to record the results from every single change in settings. You're expressing some frustration at me for not doing so, and that's fair enough. But you can't conclude from my failure to do so that you've figured out the root cause of this system performance problem.

konc wrote:

There is no other way to see a proper sysinfo result in the range of ~40.

I will tentatively believe you about this particular claim. Again, even if you're factually correct, I don't think it's the most relevant fact.

konc wrote:

If it really doesn't work with 2-2-2-2, then you need to change your cache chips as well.

...or perhaps get a different motherboard/chipset. I've already tried 3 different sets of cache RAM: a 128KiB 20ns kit, a (different) 256KiB 20ns kit, and a 256KiB 15ns kit. Absolutely no difference in performance whatsoever, either in Warcraft I or in the cache benchmarking tool included in Phil's DOS benchmark suite.

konc wrote:

Note that I'm talking particularly for the DX/40 processor, not a 2x33.

Noted. =)

konc wrote:

You can theorize all you want about CPU or VLB problems, but that's not the case for your sysinfo result, I don't know any other way to say this more clear.

You're coming in loud and clear.

konc wrote:

VGA performance is another thing of course, but how can you judge without bringing the CPU to normal numbers first?

Because I've been using computers since I was 5 years old(I'm currently 37 years old), and I'm extremely familiar with and sensitive to different aspects of system performance at an experiential level. I can tell when the CPU is fast, the video card is slow, vise-versa, etc. Putting in that ET4000 card *definitely* improved video performance, but it didn't make Warcraft I play significantly faster. Warcraft I is bottlenecked on something other than video I/O or sound I/O. Could be cache problems -- yes. Could be FPU problems. Could be a weird resource conflict.

konc wrote:

If you still don't believe this I can post BIOS settings+sysinfo screenshots with only this option changed.

What I would be more interested in is seeing a video of you playing Warcraft I on the fastest speed setting before and after that change in BIOS setting.

Would you be willing to do that for me? I'd bet money that you will not see a significant difference in performance -- or at least, with the slower BIOS setting you will NOT see anything nearly as bad as what I'm seeing.

If I turn out to be wrong, I'll be completely shocked, and I will have learned something. I'll also eat crow in front of you. 😉

Okay, it may be hardware problems... I would suggest removing the FPU altogether (only a handful of games actually use it anyway, and DOOM certainly isn't among them). It could also be in the chipset/motherboard itself, so you may not be able to fix it, and it may just be a 'dud'.
But let's not overlook the software here.
Are you running a regular MS-DOS? (No FreeDOS, DR-DOS or other alternatives, to rule out any quirks).
And have you tried booting it 'bare'? No config.sys, no autoexec.bat.
To rule out any drivers/TSRs/etc that might affect performance (EMM386 is a culprit for example).

Scali wrote:

Okay, it may be hardware problems... I would suggest removing the FPU altogether.

I would if I could, but I don't have a separate FPU installed(yet -- I've ordered a Cyrix fastmath one, but it hasn't arrived). This is just the integrated FPU circuitry of the Am386DX-40.

Scali wrote:

It could also be in the chipset/motherboard itself, so you may not be able to fix it, and it may just be a 'dud'.

I suspect this is the case, but I can't conclude this until I remove the VLB and every other card except for the ISA multi I/O card and the VGA card.

Scali wrote:

But let's not overlook the software here.
Are you running a regular MS-DOS? (No FreeDOS, DR-DOS or other alternatives, to rule out any quirks).

Stock MS-DOS 6.22, installed from floppies.

Scali wrote:

And have you tried booting it 'bare'? No config.sys, no autoexec.bat.

Of course. 😉

(Many, many times. Seems to make no difference.)

Scali wrote:

To rule out any drivers/TSRs/etc that might affect performance (EMM386 is a culprit for example).

I never load EMM386.EXE except in certain boot menus that I construct, for certain games.

It's not loaded in this case.

Whenever I let CONFIG.SYS and AUTOEXEC.BAT get processed, the mouse driver is not run automatically. I've tried running Warcraft I with and without it loaded; it makes no difference.

aquishix wrote:

I would if I could, but I don't have a separate FPU installed(yet -- I've ordered a Cyrix fastmath one, but it hasn't arrived). This is just the integrated FPU circuitry of the Am386DX-40.

The Am386DX-40 doesn't have a built-in FPU.
The Am386DX is basically just a 'carbon copy' of the Intel 386DX, and the 40 MHz version is just a 33 MHz one with slightly more modern manufacturing, which allows the higher clockspeed (some late Intel 33 MHz ones could also run at 40 MHz, if you cherry-pick them).
As such, there is no internal FPU.

So if your machine insists that it has an FPU, that is strange... And if performance is very low, chances are it is not a physical CPU, but some software emulation?