Remaining at 256k at the moment...

Throwing in an ISA video card and loading the BIOS setup defaults shows the memory holes in CTCM7 (first screenshot in previous post). The +256k is back now that memory remapping is turned back on.

DOOM timedemo does complete successfully - I honestly don't know much about the under-the-hood stuff for the timedemo. I do know it runs pretty slow on this 486SX-33 - but at least it completed. Playing the game seems "normal" to me - albeit with a slower framerate yet decent game speed.

Timed 2134 gametics in 5211 realtics.

cachechk is naturally back to complaining about Megabyte #8 as memory remapping is enabled again.

Regarding the Stealth 24 VLB - There are two jumpers on that card. One is for IRQ2 (and is open). The second looks to (at a glance) ground a pin from the S3 chip, and it is closed. The Jumper is simply labeled JP2 - no description on the card. There is one open, undocumented jumper between a couple of ISA slots. I have not changed it at all, and I have no reason to do so.

This VLB card was the card that ran in the machine with 256k cache many moons ago. So my only explanation is that either A: It is related to the battery corrosion (although I seriously doubt it) or B: Proper memory/cache/Shadow ram configuration that was lost due to the battery. I did change jumpers on this board in 2010 in attempt to run a DX4 Overdrive (it wasn't happening), and they have been restored to the documentation for an SX-33.

So even though programs like cachechk and ctcm7 are reporting oddities, DOOM runs with the ISA VGA card. I honestly think cachechk is incompatible with memory remapping - and this is something that is typically disabled when you are over 8 MB, I think. I would assume most of the guys here that use cachechk are rocking higher RAM than 8 MB.

the issue with having holes in the cacheable range is if you are benchmarking, trying to optimise the system, and the program is running in the hole, your scores could be reduced a lot and, thus, difficult to compare with others. I've seen score reductions at 50% because of this.

Your DOOM score seems about right for an SX33.

So your motherboard doesn't have jumpers for VLB "delay" and "wait state"? Mine does and it is fussy about it when I use a VLB graphics card.

It has been my general experience that when CTCM7 shows all these holes that the system isn't all that stable.

Yes, even in my 386, I use 32 MB. My VLB 486 uses 64 MB.

I don't really have any jumpers related to VLB. I still have my physical manual for it, but the documentation is available online here: http://motherboards.mbarron.net/models/486vlb3/vi11.htm The last pages of the manual show the heart of the BIOS options.

Changing gears a bit, I unplugged the psu, pulled the battery from the header, and cleared the CMOS for a couple of hours. I came back, wired up my test ATX PSU (with AT adapter), plugged the battery back in and loaded defaults. Nothing really changed as far as performance/issues.

I have external cache turned off at the moment. I still have memory holes listed in CTCM7 with the external cache turned off - those holes ("mirrored") are listed as part of the main memory. So the L1 and L2 lists (I assume) are meant to match it. I don't really know how to control the memory holes or why they are there.

I know it is possible that the VLB video card was messing with the timing/wait states a bit and required things to be slowed down. I can't recall if I tried DOOM with slowed DRAM wait states and the VLB card. Honestly if Doom hadn't frozen with the VLB card, I probably would have ignored everything cachechk/ctcm7 was saying and moved along - but I guess it is evidence that there is still a problem.

I dunno. It is weird. It seems like things *should* work but there is an addressing issue of some sort. Memtest86+ is also as happy as can be.

I am a little brain dead with the whole business. I would like to continue fighting this fight rather than give in and take this Soyo SiS board sitting two feet from me and just building a 486 - this UMC board *should* work.

Did it pass himem's memory test as well? Might also try installing Windows 95 just as a stability test of sorts.

It always passes himem's memory whenever himem is involved in a boot.

I put he VLB card back in. Put it in a different slot. Benchmarked with L2 off - Doom completed. Turned L2 back on - crash. It crashes quite quickly with L2 enabled. Changing DRAM wait state didn't seem to make a difference.

Was hoping to lock down DOS prior to loading Windows 95.

But it passes DOOM fine with 128K installed?

Actually (pulled 4 sticks out and reconfigured jumpers after your post)... yes. With VLB card, in fact.

Technically tag is supposed to be 8k for 128k L2, but the jumper settings seem to work for 128k with a 32k tag.

Memory holes still exist and all of that with ctcm. cachechk is happy.

Hmm. I guess I could use Windows 95 for testing, but I was thinking this would probably be a DOS 6.2/Win 3.1 machine, ultimately.

I also have the PROMISE EIDE4030 Plus to throw into the mix. Perhaps do a before and after benchmark - although proceeding with 128kb of cache leaves a bitter taste in my mouth - even if the difference might not be that noticeable.

Sounds like either your cache is bad, your motherboard jumpers are incorrect for 256K, or your motherboard/chipset did not properly implement 256k. Ruling out the former should be pretty straight forward.

For my perverted computer interests, an early 486 or any 386 board must work properly with 256K cache, or I have no interest in it. Not sure how you feel about a 128K limitation.

feipoa wrote:

Sounds like either your cache is bad, your motherboard jumpers are incorrect for 256K, or your motherboard/chipset did not properly implement 256k. Ruling out the former should be pretty straight forward.

For my perverted computer interests, an early 486 or any 386 board must work properly with 256K cache, or I have no interest in it. Not sure how you feel about a 128K limitation.

Looks like I got an edit in on my previous post after you posted this one.

I guess the true head-scratcher is why/how this board operated with a VLB graphics card + 256k of cache and ran DOOM just fine in 1994. The fact that moving to an ISA VGA card seemed to eliminate the DOS4GW crash also has me wondering about RAM/cache/VLB speeds.

So I stand at a crossroad - jumper to 128k and move along with this board - OR - toss all the restoration work I have done on this board and move the cache back to the SiS board and build from there?

I suppose the million dollar question is - How much of a difference does 128k L2 vs 256k L2 truly make? And for a more personal question - what are your reasons for going 256k or bust?

And if I stick to 128k, I am probably going to want to run some stress tests.

Then there is also the question of "what if I did 12ns tag?" or put the 256k of 20ns back in but left a 15ns in the tag socket. No idea if that really will make a difference. There is nothing in the manual (not much of a manual, though) that makes any indication that tag should be faster - unless it is always assumed (and goodness knows the clone market assumed back then). I have seen the guys on here and elsewhere mention the faster tag requirement - but I don't know if that is from manuals/general knowledge/or even chipset specific. (EDIT: Looks like you had the same question years back - L2 cache speed)

256K is a nice common number for cache; I like to max out [double-banked] cache on all motherboards. You need 256K of direct-mapped cache for 32 MB to be cached in write-back mode, or 64 KB to be cached in write-through mode. Although 386 boards only use write-through L2 cache and usually have a limit of 32 MB, my mind defaults back to 256K being minimum. There is also a [relatively small] performance increase from 128K to 256K which I'd like to quantify at some point for various systems.

Not sure how you ran the system in 1994, but memory is unreliable.

15 ns TAG should be fine. I don't know any 486 boards which came with a faster TAG. Some came with 15 ns cache or 20 ns cache. Perhaps play with the CMOS cache timings.

I had been playing with the timing throughout this cache exercise. I don't really have many other options.

I put the old cache back in and had the same problem. I dropped it to 128k with the old cache and had some graphics corruption (but timedemo completed). I may have even had a freeze with 128k during testing, but I ran so many tests...I can't remember. Maybe it did. I have no idea if the larger tag has anything to do with it.

My brain is starting to recall this problem happening 22+ years ago after having the system a couple of years - and it is possible that the solution was to disable the L2 cache when the problem manifested itself and then eventually move to a Pentium in 1996. But who knows - I might be way off. That may have never happened - but disabling L2 would have been a very simple solution to keep a system running until an upgrade, and also an explanation as to why I don't remember it. Seeing as how it is a CMOS option, that setting would have been lost years ago thanks to the corrosion.

So with L2 Disabled - The Doom demo appears to run fine.

Speedsys actually reports faster throughput.

I could go all the way back to 256k with the 20ns (in there now), turn it on, and use the 16 bit ISA exclusively for awhile to see if it sticks, but I am more reluctant to give up VLB than I am to go to no cache.

And just not using any L2 cache might be perfectly fine for this application.

CkRtech wrote:

My brain is starting to recall...

That happens to me sometimes as well. I question if my mind just stuffed the memory in or if it actually happened some decades ago.

I put the cache back in the Soyo along with the VLB video card from my machine, and it can't start MS-DOS with L2 enabled. SOOO...perhaps I have two bad sets of cache 😒

I put the VGA card in - same issue.

Maybe I zapped this set. Either that, or I need to reseat it. Perhaps I will just set everything on fire.

Have you considered buying an SRAM tester? Most units also include a flash programmer. These units are usually around $50-200. There are more expensive units which actually measure the response time from the SRAM, but the prices are ridiculous.

Ahh man. I dunno. I imagine you have to pay a good amount if you want a good one that does reliable testing.

What are the voltages for the static ram you have used, btw? It is something I haven't looked into. Saw a lot on eBay that are 3.3v. The board I have is all 5 - unless there are resistors dropping it down. I suppose I could measure, but the board is out now.

Apparently I am not giving up. feipoa - You have been my wingman through this. I am crossing my fingers that it isn't the cache or the chipset, but here goes -

1: Put the 4 + tag of the original 20 ns back into the Aopen Vi11 mobo and jumpered to 128k. Put in ISA VGA card with VLB I/O. Tried to establish baseline. Doom completed.
2: Wrote batch file and looped demo3 4 times. Completed. No graphical corruption. No crashes.
3: Put in VLB card. Ran demo. Crashed. Changed "< 33 MHz | >= 33 MHz" jumper (believe this is actually the code name for wait state). Tried that. Didn't really help.
4: Put ISA back in and ran again. Doom still seems OK.
5: Moved to 256k. Ran Doom. Completed. Interesting.
6: Ran batch file. Run 1, 2, and 4 completed. Run 3 crashed (and obviously loaded run 4 immediately afterward and finished).

Power, thermal, speed, or combination? Why the obviously worse instability with the VLB card? Why the mostly OK yet still a crash... for the ISA card? Power drop? Tantalum caps not pulling their weight anymore? Man. I dunno. I just...don't want to give up.

I actually have some good news. Mostly.

Test 1 - Passed
Hardware - ISA VGA. L1 cache disabed. 256k L2 cache enabled. Pulled a fan/heatsink combo from a DX2-66 to slap on the SX-33.
Results - Ran somewhere around 4 to 6 Doom demo3 loops. Obviously slow. No crashes despite L2 cache enabled.

Test 2 - Fail (intentional)
Hardware - Re-enabled L2.
Results - 5 of 6 Doom tests with no crash. One test crashed. Expected.

Test 3 - Passed. An eye-opener.
Hardware - L1 and 256k L2. ISA VGA. Set AT clock select to CPUCLOCK/8 (It should be CPUCLOCK/4 for 33Mhz).
Results - 40 (Yes, 40) consecutive Doom tests without a crash.

Speedsys still generates the same results as earlier for CPU and RAM. Cachechk complains about a timer error, but finishes with decent scores.

I did try CPUCLOCK/5 a week or so ago while we were spitballing in this thread but stopped there in favor of continuing with other tweaks. Today, CPUCLOCK/6 didn't seem to get it done. Finally, CPUCLOCK/8 seemed to be the magic number. Supposedly half the speed of what it should be. I honestly didn't believe it worked - and that is why I ended up with 40 runs.

I changed the video card out for the VLB one - Crashed as usual, as expected, during the 70% mark of the first run. VESA local bus is, by design, its own beast.

My theory is that crystal Y2 took damage from heat either during or sometime prior to my board re-work. It literally sits between the two slots I desoldered.
Crystals are actually quite sensitive to heat.

Not sure where I want to go next - try to find an appropriate place to scope/meter, is it the crystal or a support component of it? Perhaps it is accurate but not stable? I have more research to do (and welcome any feedback on crystal testing, issues, etc), but I wanted to drop an update.

I can't really add anything to this thread, just wanted to say it's fun to read! You guys have a lot of knowledge! It might be useful to read this all again when I get some time to build a VLB system 😀

I found that even the not-so-expensive SRAM testers can save a lot of frustration with bad SRAM.

All the SRAM I've found for DIP 28 and DIP 32 have been 5 V.

Normally, you'd use two ordinary diodes in series to drop 5 V down to 3.3 V, not resistors. The diodes act as mini regulators in their own right.

Here is another combination for you to try - use an ISA I/O card and remove the VLB I/O card. Try with all ISA and 256K.

Also, try a different VLB graphics card. I find these older systems fussy about what cards they will work stable with.

ATCLOCK should be set to in the 8-10 MHz range. You are running it at 4 MHz. Something is up. I suspect the system does not have enough time to address all that cache due to some design flaw.

On my 386 boards with acid damage, the cyrstal also needed to be replaced, so your guess may be correct.

There could also be some vias which were damaged by the acid and are now so thin that there is intermittent conduction, or are acting as small resistors, or are altering the matched impedances of the transmission lines (traces).

I have some incredibly awesome bad-good news.

First, that second crystal is ~14.3Mhz. Like the larger silver box counterparts on 386 boards.

But the BIG news is - I have noise. I have noise in the AT bus - most notably on the CLK B 20 pin. So what should be chilling at ~8.25MHz (33MHz / 4) is mostly doing so - but hard drive activity (and most likely video activity) is represented inside the waveform, and that waveform will sometimes decay ever so slightly - resulting in my oscilloscope briefly displaying 4.XX MHz or 5.XX MHz in the middle of running Doom. ISA VGA can handle it most of the time, but VLB (as expected) has a response of "WHAT THE ---?"

I reexamined the backup, Soyo (SiS) 486 motherboard I used earlier, and it turns out one pin of one cache IC got turned when I inserted it back into the Soyo after testing in the AOpen. Good. I removed the cache, processor, RAM, clipped the battery, scrubbed the board to get rid of corrosion, dried it, put it back together, and booted. Runs great. 486DX2-66. Doom. Cachechk. Speedsys... They all look great - and with the Diamond Stealth 24 VLB to boot. Had Windows 95 up for a little bit as well as it was an old install that was still there on this system's HD.

So the AOpen problem isn't with the cache modules, themselves. Tantalum capacitors don't lose capacitance with age - but they can have trouble if exposed to high levels of heat and moisture. I don't really think they should be causing the problem, but I suppose it wouldn't be too bad to replace them. The resistor banks are also responsible for terminating signals on the parallel buses. It is possible I have issues there instead/as well.

I am going to temporarily move this bench PSU unit I've been using on the AOpen to the Soyo and make sure that I don't have TWO noisy power supplies causing my problems with the AOpen. If the signals hold strong like they do with the Soyo case's AT PSU, then the problem is definitely not the current PSU I have been using to test.