Yeah, but the LSD only does 256K. If you can get another board to match it at 256K, its another option. Given the larger assembly of the 486SPM, I doubt even your musical chairs will lead to the wait states of the LSD. Also, I didn't try any other BIOSes. The 486SPM's stock BIOS cannot use 64 MB modules. its possible that a BIOS switch would help the situation.

One positive to report from the tests: No more sound crackling in Duke3D introduction, this is in contrast to LSD. The same hardware was used on both boards.

For 486 systems the level 2 cache is one of the weakest points when it comes down to overclocking.
Lowering the amount of L2 cache was not very interesting at the time.
I guess i was in a different situation than you are today with that problematic LSD board.
You may be looking for a good alternative to it, while i was looking for something better than LSD/UUD.
So naturally i was trying to max the systems out to outdo UUD/LSD, otherwise i could get something that matches them at best.
I still have most of the tested 486 motherboards and can spend time on that with some of the best candidates at least.
That Chaintech board didn't handle very well 4x50 with trusted L2 cache modules that can do it fine on other boards.
4x50 is much less extreme than 3x66, so that was already a red mark that reduced my interest in it.

Since 256K generally works better at these high bus frequencies with tight timings, perhaps some of the once rejected boards will shine.

I modified my MS-4144 v2.1 board for the 30, 60, 66, 80 MHz bus options. Again, just one jumper added, with one lead at a convenient ground via and another to the S2 pin on the SC464 clock generator. This is the location I choose:

Although I was able to find some reduced timings for the Chaintech 486SPM board to work with 1024K and 180 MHz, the MS-4144 would not cooperate. On the other hand, though, the 256K setting on the MS-4144 at 180 MHz showed improved results compared to the Chaintech 486SPM with 256K/180 MHz.

I did not shuffle around cache chips, nor do I have as good of L2 chips as Pshipkov for tight timings, but this is what I came up with for timings: 2-1-3, 2, 0, 1, 1, 2, slower.

Cachechk
L1: 186.0 MB/s
L2: 91.4
RAM read: 52.8
RAM write: 83.4

Quake: 19.0 fps

Better than the Chaintech, but not up to the UUD's speed of 19.4 fps in DOS Quake. And certainly behind the 20.2 fps of LSD. But with proper 256K modules, I suspect the MS-4144 can reach UUD speeds at 180 MHz.

Unfortunately, my Am5x86 chips won't do 200 MHz.

EDIT:
I forgot to mention that I didn't have any serious issue with the PCI = 1/2*FSB feature on this motherboard. I did notice that, when loading MSCDEX.EXE (DOS CD-ROM access), it would hang when 1/2*FSB was selected. This also happened on the Chaintech board. However, I have since determined that if I remove the /E option from the autoexec.bat line corresponding to MSCDEX, then I can continue to boot. I did not have to do this when PCI = FSB. So far, this appears to be an issue with SiS496/497 chipsets.

From https://www.easydos.com/mscdex.html

1/E - Specifies that the CD-ROM driver be allowed to use expanded memory, if available, to store sector buffers.

Will link to these two posts from the "original" ones early in the thread.
Thanks for the additional details as well. Re: CDROM drivers and bus dividers, etc.

Your notes make me thing that it may be good to re-examine the motherboards with 256Kb level 2 cache only.
This may give a second chance of the ones who struggled with the 1Mb buffer size.
And who knows - there may be surprises in there.

---

Will have to revisit my stance on MSI MS-3124.
While the board is simply great and scales really well to 110MHz (2x55) CPU and 27.5MHz ISA bus, there is simply no FPU that is fully stable at 55MHz.
I am usually very conservative and punctual when it comes down to stability, but this time i spoke a bit too soon.
After range of grueling tests over the last few days i determined that the system cannot be fully stable at these frequencies with FPU installed.
Without FPU all is good, but that is non starter.
At 100MHz (2x50), 25MHz ISA bus with tightest timings, the board is slower than DTK PEM-4036Y.
Going to update the posts and charts accordingly in the coming days.

How many black-top Cyrix FasMath CPUs did you try? Maybe they need to be binned like Am5x86 and SXL-66 cihps?

Let's just leave it at this: i tried really hard a lot of FPUs.
Also, the 40MHz rated ULSI DX/DLC chips scale better than the black top FasMaths. That's for sure.
They almost can handle the 55MHz. Tried 4-5 of them, but they all ended up at "almost".
Blacktop FasMaths just don't go past 55MHz.
IITs are even worse.
At the bottom are Intels. They don't go past 40-45MHz, which is fair since they are 33MHz rated.

Situation is similar to the DTK PEM board. It can do 55MHz, but without FPUs. It is a lot more picky at that frequency than the MSI board.
MS-3124 is just hands free at 55MHz if we ignore the FPU.
Too bad.

Alright, I pulled out my MS-3124 after storing it away for some time and decided to give it a go with a PGA132 SXL-40 for the heck of it. The board worked pretty well, all things told. I didn't notice any stability issues, although CTCM1.6n hung. CTCM1.5b seemed okay, which is generally a measure of stability in my book, as it tends to invalidate and flush caches, which can hang and thus immediately alert as to cache coherency problems. I guess I retract my prior statement about DLC/SXL parts. Furthermore, I used Cyrix.exe to set the CPU up, as follows:

1Cyrix.exe -f -b- -m- -xA000,128 -xC000,256

This seemed to work just fine. The BIOS I have attached here is immediately aware of L1 cache, and is set via a hidden setting to enabled. This is probably not great, but it's what it is. I disabled it and then re-ran the above, but instead added the -e flag. Both cases still were stable.

I messed around with things a bit in AMISETUP v2.70 and discovered that there's all sorts of settings hidden away in this boards BIOS, including those related to Hidden Refresh and Slow Refresh, which are bound to help things a bit on a clock-for-clock basis. Additionally, I noticed a few interesting things about this board, at least with respect to mine relative to yours. Mine is a little older dated at 92, week 16 on the Contaq 592 IC and 92, week 20 on the Contaq 591. Yours possesses a Contaq 591 A, which I believe to be a slightly newer version, like how Contaq had a 596, 596 A, and even 596 A3. I doubt there's much difference there, but found it interesting nonetheless. Mine has a Chips & Technologies 206, but that's not really relevant to performance and rather just another observation.

I've attached my BIOS to this post. I am not certain if it's any different than yours.

As to the FPU situation, I am curious-have you any success on any board with a 55MHz FSB? I suspect that most of these 387s are 1.2 micron or thereabouts. The Chips J38700DX and ULSI DX/DLC supposedly are; that might be the explanation for why ~40-50MHz is about where they cap out. However, I am curious about FPU accuracy past, say, 40MHz. Have you-or has anyone-measured the actual accuracy of computations when FPUs are aggressively overclocked? I imagine that an IEEE conformance test is kind of useless in that regard, as they'll always be compliant, but there's something to be said about practicality in actual calculations past a certain limit. I guess the best way to approach that is by, perhaps, testing calculations and seeing if the proper values are being returned.

Regarding the IIT FPUs, a fellow user posted something here worthwhile. Check out this post; there are roughly five, and perhaps more, versions of the IIT 387 core. I've spoken with this user about the matter, and he has done some pretty extensive testing. He was telling me something intriguing-that being the IIT "v3" cores can interact with the Weitek 3167 utilities only on the PC Chips M321. That's kind of interesting, although I doubt that means too much, and so does he. The IIT v4 scales somewhat well to 40MHz, but I need to test the accuracy. I digress, however. Back to the main point-there are things to consider FPU-chipset interaction-wise, as demonstrated by this IIT v3 anomaly on the M321; perhaps the issues at 55MHz, which I suppose is a super-edge-case anyway, are due to the Contaq 591/592, at least in part? The 591/592 is found on a few 486 boards, but it was first developed, seemingly, as a 386 part. Or there are versions of it that are certified for 3/486 hybrid operations and versions that are not; I am not sure, and merely guessing, but this could be something to chase down further. Have you tried the ULSI DX/DLC on any other board at 55MHz FSB? I can't recall seeing it here, but I could be wrong; this thread is a goldmine of valuable information as it stands.

To AnonymousCoward's point-yes, I recall those strange Electroglas Peak/DM boards. They were pretty popular for a bit. I think the PGA socket on some of them is missing the extra pins required for the Chips J38605, but there might be versions with the proper socket, as all of them have the solder pads. How is the Peak/DM anyway? The VLSI TOPCAT and SiS Rabbit seem to be pretty fast for 386-only designs.

Feipoa, I really like the info on these FSB mods. I have these images saved in my archive, just for reference. I think you might be onto an interesting point; while 1024k of L2 is probably the "best" way to go about things on a 486, there are other considerations at hand. Quake, for instance, is a bad test because it tends to perform better on uncached memory and this anomaly doesn't really matter in the grand scheme of things, as Quake just has a bad way of dealing with cached memory, in my honest opinion. I say this as a mere novice programmer, but I don't think it's a wrong observation when Quake does better on cacheless 430FX systems than those with asynchronous L2; ergo, a 486 might need pipelined-burst cache to get anywhere, and that ALD board I demonstrated with such is just not really that great. A board that surpasses the LSD at 66MHz might not even need more L2, after all, the LSD only possesses 256k. I've never been the biggest fan of my LSD board, and I've found it to be somewhat buggy, noting the DMA issues you all have seen and noting, as well, the awful onboard Super I/O setup.

This is perhaps a dumb question, but have we considered any ALi M1489 boards at 66MHz? The ABIT PB4 does decently well against a UUD at 180MHz, but is hampered by single-banked cache and lack of 66MHz FSB. Are there any halfway decent (non-M918) M1489 boards that can do 66MHz and have double-banked L2? The ALi chipset has some pluses and minuses, but the largest plus is that, unlike the SiS496, which still possesses some VESA logic under the hood even on non-VLB boards (as far as I can tell), the ALi M1489 should be a full-fledged, PCI-only setup, and that might be something to consider as far as stability long-term goes. VLB, even VLB 2.0, does not really like 66MHz, although VLB 2.0 does support onboard devices at such a speed and can do 64-bit transfers as well. I admittedly am unfamiliar with the M1489 beyond a few posts on here, but it seems halfway decent, even in non-ideal configurations like that on the PB4.

Ugh this thread is not for the faint hearted. Guys please don't break your boards as they are not yours, they are on loan to you from the future generations.

@WJG

Like you, I'm finding the DMA issues with LSD troubling and have since been looking for possible alternatives for the Am5x86-180 setup. UUD works all around, no issues, full stop, but not quite fast enough unless you have pshipkov's magic L2 modules. I'm now on to testing the m919 v3.4BF, which has demonstrated remarkable speed at 180 MHz, faster than LSD and UUD. The onboard IDE is a slug though. You can use the UMC driver in DOS/W95 to help in this regard, but NT4's IDE performance is still abnormally slow. It benches at half the speed of the UUD, even though they have the same chipset. Instead, I'm now using CF card via an ACARD adaptor with SCSI. Some issues I've run into are some garbled characters on the NT4 desktop if a Voodoo2 card is installed. I'm not sure if it is the Matrox G200 + Voodoo2 combination, or if there's some general issues with Voodoo2's on the m919 in NT4. Anyone know? w95 was OK, but it hints at some issues on the PCI bus.

For anyone testing the m919, you'll want the 1M cache module and be sure to not use exactly 64 MB of RAM or you'll see a performance hit. You must use 64 MB +- x to avoid this performance hole. I'm using 64MB + 16MB for now.

After the m919, I will be moving onto the m918 and another ALi M1489-based board I have in my bin. I'm looking forward to seeing how these fly at 180 MHz. Anyone know if they support EDO?

@doublebuffer

Yeah, this thread went places.
But we fix boards, not break them. Well, mostly. My ratio at least is positive.

---

@WJG6260

What is this SXL-40 processor you tested with ?
The DLC/SXL2 chips here don't click with L2 cache active.
Can you clarify please ?
The issue for me is POST does not complete under this circumstance.

Thanks for the Contaq chipset notes and the BIOS.
The binary blob seems to match the one here.

Somehow missed the link with IIT FPUs.
From my experience the 33MHz rated chips don't go past 40MHz.
The 40MHz ones don't go past 47.5MHz.
That is with 7 chips 3x33MHz, 4x40MHz.
I run validation with offline 3D rendering.
In some cases when the FPUs are on the edge, the resulted graphics come differently funky - a clear indication about non-fatal failures.

As for cached/uncached memory access - at least for 386/486 machines, if the cache runs at tighter timings than the DRAM, then perf will be improved.
The only exception to this rule so far has been PC-Chips M918.

About Ali M1489. I have an item in the to-do list to look at clockgen mod, since they support 60/66Mhz.
But since the Abit boards didn't blow me away with 4x50, i left it for undefined later.
To Feipoa's question - they do support EDO RAM.

---

About this MSI MS-3124 guy.
I am going to walk back on my last statement about instabilities.

The next prerequisites are needed for a fully stable 110MHz system:
- good PSU with solid 5V line
- magical ULSI FPU (in addition to the magical already magical IBM BL3 CPU in use)
- selected 110MHz crystal oscillator (from tested 5-6 only 2 can do it, the rest made the system unstable, or no lights at all)
- this one is extra weird - RAM check during POST should not be interrupted, or the system gets flaky. 100% reproducible, but don't ask how that was determined.
So, i am back in business with this board after all, but things are on the edge. : )

@pshipkov
Apologies about the delay, but I did some more testing. I used a PGA132 SXL-40, like the one pictured here (actually, this is one of the two I have in my possession now). I don't have an SXL2-50, but the SXL-40 is the same pretty much; I don't know if it can do 55MHz, but it can do 50MHz without trouble, and it still has the clock-doubling PLL inside, despite the name. It may as well be the same chip as the SXL2-50, knowing TI's screwiness with DLC/SXL parts.

I realized that I might have been mistaken and so I pulled the board out once again. I used "10ns" cache and threw back in the SXL-40, and lo-and-behold, the board would not boot with the default CMOS settings. I think I must've modified something in AMISETUP 2.70 that allowed me to boot the board successfully with a DLC/SXL. Anyway, that's irrelevant, because I found a MR-BIOS image that accomplishes the same without any settings. I've attached it to this post, in case it might help out. I don't know exactly how stable I'd say the board is with SXL parts; it definitely isn't the most Cyrix-friendly board I've used, insofar as it doesn't set things in an agreeable way and the cyrix.exe program is basically needed to resolve cache coherency blues. This isn't really a problem, but it's frustrating, to say the least. I think the BARB method is the only thing that works on this board, as FLUSH gave me issues.

Interesting that the IIT parts cap out at 47.5MHz. I guess that makes the IIT X2 their lone silicon that could handle higher speeds. That probably makes sense from a matter of binning and, I guess, the use of clock-doubling to overcome this issue. Ah, okay, that makes sense that you use 3D rendering as a validation! I suppose I never thought about it in that manner, but it is a really good way of going about things because you can physically see when the calculations go awry. I wish there were more FPU tests, but it seems ASM for the x87 parts is just something that wasn't mainstream, until the Pentium brought the FPU by default, rather than as an option.

Your point about 3/486 boards and L2 reminds me: I can't help but wonder why the 430FX suffers so horribly with asynchronous SRAM. It uses 3-2-2-2 reads and 4-3-3-3 writes; that's not that much slower than the 3-2-2-2 reads and 4-2-2-2 writes of its 430NX and 430LX predecessors. They're pretty quick. The M918 is definitely one messed up situation; I don't understand that board. Very few ALi M1487/89 boards came with double-banked cache, and I guess that was for a reason? I don't know, but the M918 does seem to have some serious flaws insofar as to how it handles L2. That's not the only case, as far as the PC Chips and L2 weirdness goes. I have an M919 v1.5, which I guess is technically an "Amptron DX-9500," and it's 100% identical to the M919 except it uses standard DIP SRAMs. However, it comes equipped by default such that the SRAMs are set to 3.3v, and you have to add headers and jumpers to set 5v SRAM functionality.

I think that 1024k at 60+MHz is really touchy timing-wise. Referencing the above, I don't know what timings the non-Intel Pentium chipsets used, but I imagine that they couldn't be much better than 3-2-2-2/4-2-2-2. The OPTi VLB Pentium boards, however, can do tight timings, specifically those based on the 546/547. Those, however, are a different story, and I suspect highly that they are still slower on cache hits than their Intel/SiS/ALi counterparts. If the Pentium boards, which were more mature, had to run slow timings with 1024k at 60/66MHz, then I suspect only the latest of the late 486 boards could really get anything close to that. I'm planning on revisiting that ALD PCI 5433 fellow sometime soon because, if it can be modded to do 60/66MHz, then I suspect it can do very tight cache timings with its pipeline burst L2.

Looking forward to your ALi M1489 experiments. I have been on/off debating on picking up such a board. Right now, they don't interest me all of too much, but that may change.

Sounds the like MS-3124 is really on the edge, but glad to hear that it is stable. I am curious, though--how did you figure out that letting the DRAM test complete was one such key? That's wild to me, and such a weird thing! 🤣

---
@Feipoa
The UUD definitely sounds like a good alternative, but the M919 might be the better option. How is its stability at 180MHz? The v1.5 board I have isn't anything spectacular in that department. I have yet to truly get it there, but maybe the v3.3/3.4 variants are more ironed-out?

I suspect that the Voodoo2 issues could be related to the M919, but that's my guess. I don't particularly love the board, even though it is solid. I think issues on the PCI bus are a good guess. Have you run PCI.exe-that PCI diagnostics tool for DOS? I've attached it if not. Sometimes it helps reveal what's going on, just from a measure of gleaning the bigger picture about interrupt allocations and PCI configuration. I do know that the UMC chipset on the M919/UUD is a bit more refined when it comes to the PCI implementation than, say, the Intel Aries where you have to jumper IRQs manually, but maybe there's something screwy going on BIOS-wise?

The M919 v1.5 has the 64MB bug as well. Just want to add this out there for those reading these posts.

I think I've read somewhere that ALi M1489 boards and VIA 496G boards do really well with EDO vs FPM, insofar as they almost seem to prefer EDO. I am expecting to receive a Jetway J-435-B. It's a 496G board without the PCI bridge; I'm curious about its EDO capabilities. It can take 1024k L2, which is a plus.

That reminds me, @pshipkov, have you ever used a VIA 496G board without PCI? The PIO-3, as good as it is, still uses the VIA 505 VL/PCI bridge, which I think complicates things. Early tests of a Pentium 60/66 board I have that's VLB-only suggest better performance without the bridge, which might be the case here. The PIO-3 seemed pretty okay at 180MHz, but nothing crazy.

Thanks for the SXL-40 info.
Didn't know about them.

I tested the MSI MS-3124 with a Mr.BIOS image from TRW but it does not go past 45MHz FSB. That is with IBM BL3 processors.
Not sure why, but 50 and 55 MHz are off limit. Motherboard simply does not light-up with it.
But now when you mentioned it - i don't think i tested that BIOS with SXL2 CPU.
Going to run that over the weekend. It is reassuring that you see level 2 cache working there.
Wonder if it will hit 50MHz or more.
Good hint.

FPU is a minor story in the context of 386 class hardware. Still, without FPU the systems feel too incomplete.

I have very limited experience with Pentium (1, MMX, Pro) class hardware, so no idea about the 430FX/NX/LX chipsets and how they handle level 2 caching.
As for M918 - it is a a joke of a motherboard really. If you simply look at the posted performance metrics it can fool you for good. Otherwise it is quite a mess.

Will make the simple mods Feipoa posted above and see how far i can go with them - 60/66+1024Kb.
As for M918 at 60/66 - i don't remember seeing jumper configuration for 60/66MHz. So it will probably need a simple mod too.

As for MSI MS-3124 and memory check during POST.
Initially the board didn't work well at 55MHz because i actively tried to make things happen.
Over time the initial energy started running out and i was getting distracted inspecting jumper configs and notes between restarts.
When the memory check completed things were glorious. So in one out of X runs the board was killing it while in the rest was flaking.
This was very confusing. It took some time to notice the dependency. Once i spotted it i had hard time believing what i see, but was quickly convinced.
C’est la vie ...

I think M919 is the fastest motherboard for 3x60MHz. But only if we consider the 1Mb level 2 cache module. That module also allows tight wait states and hustle free experience.
Its HDD controller is a weak spot, but that's the case with all mobos based on this UMC chipset.
The only weird thing is the automatic PCI bus divider over 40MHz FSB that can be mitigated with switching frequency on the fly, or start with turbo off. Minor issue, but still.
Otherwise the board works really well at 3x60.

Good to know that version 1.5 has the same 64Mb issue.
I mean, this is not good news really, but at least it confirms consistency.

Looking at previous notes - the M1489 and 496G seems to prefer EDO.
Unfortunately didn't have the chance to try VIA ISA/VLB-only mobo.
It will be great to hear from you what you find there (Jetway J-435-B).

Can you give a brief summary of the PCI.EXE utility ?

My pleasure! 😀 I have had trouble procuring an SXL2-50, so these have made do in the meanwhile. I hope to find an SXL2-50 in PGA132 someday.

The SXL PGA168 interposer has of course added lots of variety to the mix, however!

Interesting! I wonder why it is that the MR-BIOS is more limited FSB-wise. Timings, perhaps? It didn't seem too much faster, if at all, though. I would be curious to see an SXL2-80 or SXL2-90 if it can be managed with the MR-BIOS on this board. I'm eagerly awaiting your results!

FPUs are sort of fun in the own ways. I agree with you completely that they are needed to complete a system. I appreciate the advancements they made too; IIT, for example, improved performance with each new variation. They also had that neat 4x4 matrix multiplication extensions, which weren't really used, but are kind of fun to mess with in the demo utilities.

I think that the early, early Pentium-class chipsets are more-or-less late 486 chipsets with some extra things bolted on. The OPTi 571 is actually a 486 chipset that was used with the Pentium, 32-bit cache/memory interfaces and all! I suspect there are differences in the design, and I think the 486 might be more likely to handle tighter L2 timings overall.

The M918 is kind of hilarious. I loved your comment that it's a Paper Tiger; if anything, it's the truest Paper Tiger board I've ever seen!

Keep us posted on your findings!

Been there, as far as those moments where something good magically happens when you just kind of lose the initial energy. Glad to hear that you were able to figure out one of the mysteries. The MS-3124 is a weird board and it feels like it's on the knife's edge stability-wise. I haven't broken it out for some time because of that but I am slowly regaining interest. I recently bought another 386 board, however, that will be taking more of my time. And numbers on that one are sure to come...

I recently picked up a UUD Rev. 2 to join this UMC experience and see what it's about. I kind of want to try the Cyrix 5x86 route, though. I'm undecided at the moment.

Thanks for the turbo notes. I have heard this before, and forgot about it. CPU Galaxy used a switch attached to his FSB jumpers to mitigate this, but the turbo seems easier. Is the bus divider 1/2 or 2/3.

The v1.5 is basically the same, but a little rougher around the edges. It's so rough, in fact, that the cache setup is beyond borked. By that, I mean to say that the TAG is fed 5v by default, and the rest of the L2 is set to 3.3v (which is actually ~3.6v)! There are factory-set jumpers, which can be modified with headers, to fix this and set 5v to the cache. I'd get a v3.4 if they weren't so darned pricey these days and if I didn't feel like this v1.5 wasn't worth exploring for convenience sake. The BIOS is pretty much identical too, and the later dated v3.4 BIOSes work.

I will share my findings for sure. I have more time these days, so looking forward to it! 😀
I'm candidly not expecting much, but hoping to be surprised. I found that a Pentium 60/66 VLB-only board was faster than the PCI/VL boards I have, and I suspect that's due to the lack of the 82C822 bridge chip. Maybe the VIA 496G will be the same without the -505 bridge?

PCI.EXE basically just dumps all the PCI info and lets you view a report of all assigned resources, configuration, etc. It's kind of like AIDA16 for DOS, but mostly for the PCI bus and a little more detailed. I figured it might have some data that could be used alongside MOJO/the DOS glide utilities and see what's up there.

I see the thread with the Panda board. Hope you figure it out, but even with the last VLB slot silent it is still testable.

One of my UUD boards fell silent recently. I have been messing around with it too much and far too long.
It is on the short list to see if can be awakened.

The UMC chipset used in M919 and UUD can apply 1/2 and 2/3 PCI bus dividers. Cannot remember from the top of my head if M919 can do both. Need to check to remember.

This reminds me that at least 1 or 2 of the examined 386 boards exhibited similar symptoms - tag chips get hot. Probably higher voltage compared to the rest. Worth checking for clarity at some point later ...
It is amusing to me to compare the different versions of the M919 mobo. So much funky stuff going on. : )

Your observations for PCI-only or VLB-only boards being faster are inline with what many of us see as well.

Thanks for the notes about PCI.EXE

Good to hear you are getting more time available for the retro hobby. Let's see where the Panda takes you.
However it is the contrary here ...

@WJG6260

With Mr.BIOS i can get the SXL2 to boot into DOS.
ISA bus frequency cannot be higher than 12.5MHz.
Everything works really, except level 2 cache.
Do you see the same ?

@WJG

M919 v3.4 with the 1024K module at 2-1-2 and 60 MHz is fine, but it needs the 1024K module with the 12 ns SRAM chips. I also need to use a 50 ns EDO stick that is 128 MB. My 50 ns 64 MB EDO stick didn't suffice, but pshipkov ran some tests and his was OK. So I guess his 64 MB sticks are just better than mine.

I think the issue with V2 + G200 was the G200 conflicting with the V2. I am now using a VLB graphics card, the ARK1000VL and the V2 and ARK work fine in NT4. There is definitely some bus mastering issues on the M919. Sometimes SCSI will get hung up on boot (NT4). It gets permanently hung up if trying to install W2K (UUD is fine though). I recall mkarcher or someone else having a solution for this, but I forget what it was, or if it was for another 8881 based board.

There is still some issues in NT4 when reading from an IDE CD-ROM. It is a small issue, but hints at underlying problems. If I play a sound from my Cambridge Advanced Learner's Dictionary, and those wave files are stored on a CD-ROM, it will read the word twice with a skip sound between the readings. Other motherboards had no issue here. I haven't done w95 testing yet, but I suspect it will be fine.

Regarding MR BIOS, I think we have concluded that when pushing the FSB beyond 45 MHz, MR BIOS cannot cope.

Regarding the M918 - my plan was not to use the PC Chips BIOS, but to use other Ali socket 3 BIOSes. I remember having tested the m918 with the PC Chips BIOS 5 or 6 years ago and was not impressed, but I did not try the BIOSes from my other ALi board on it. Did you?

To mitigate the M919's automatic PCI divisor for 40+ MHz, you need to use a double-pole, single-throw latching switch (DPST). Leave a jumper on the middle pins and connect the DPST switch leads to the two outer FSB jumpers. With the switch on, it will boot at 30 MHz FSB. At the DOS prompt, de-latch the switch, and your FSB is at 60 MHz and so is your PCI bus. The de-turbo header does not help for the PCI divisor issue.

Note that the M919 also has a very bizarre 64 MB performance hole problem. Do not use exactly 64 MB of RAM. You must use 64 MB +- any amount to avoid the performance tanking. For example, you can use 48 MB, 80 MB, or 128 MB and not have the performance hit bug, but not 64 MB. I know it is hard to believe, but test it for yourself and you will see it. Features like this are exclusive to PC Chips and sort of adds to their charm. Also, there's PCI bus mastering issues, but 180 MHz performance is best of all boards I've tested so far.

After the unexpected outcome with MSI MS-3124 version 2.1 based on Contaq 82C591, 82C592 my interest in Contaq chipset piqued and wanted to see how their stuff does in the realm of 486.

Addtech Galaxy II 486 revision 1.0 based on Contaq 82C596 A3, 82C599.

The motherboard is in visually perfect condition.
Even the battery didn't leak after all the years, but removed it anyway.
Lots of slots - 4 PCI, 4 ISA 16-bit ISA, 1 8-bit ISA, 2 VLB slots.
Interesting clock generator that supports up to 100MHz frequencies.
Jumpers for 3.45V and 5V CPUs.

Lit-up right away, but the clock generator was stuck at 8MHz for some reason.
Quickly realized that there is an electrical issue with its control jumpers.
More information in this thread.
Won't go in details here. In short - socketed the clockgen chip and connected the FS1/2/3/4 pins to GND or +5V pins on the board for direct control.
With that out of the way the board was ready for testing.

Used 1024Kb level 2 cache. The board is not very picky, so finding the right chips was quick.
Ark1000VL didn't work. Used S3 Trio64 VLB and Matrox Millennium PCI graphics cards. Both work just fine. Motherboard preferred the VLB card - much better performance.
Promise EIDE 2300Plus VLB controller.
60ns 32Mb FPM RAM. EDO RAM is not supported.

--- Am5x86 at 160MHz (4x40)

All BIOS settings on max.
Everything just works.
Nothing more to say really.
Nice experience.

Btw, the BIOS contains interesting settings that i haven't seen in microcodes for other chipsets. Take a look:

Level 1 cache policy is stuck in WT mode. If force WB mode with an interposer, performance drops significantly.

benchmark results
Not a great performer overall - below the average in most tests.

--- Am5x86 at 200MHz (4x50)

All BIOS setting on max, except SRAM READ BURST = 3222.
Anything tighter than that and POST does not complete.
It is not the cache chips - they handle 2111 with other boards just fine.
Still, tried to find a combination of them that can eventually do it, but fairly convinced it is the motherboard itself.

benchmark results

Performance is much worse than 4x40MHz. Apparently the inflated L2 cache timings are taking their toll.
Disabling L2 cache entirely further degrades performance.

--- Am5x86 at 200MHz (3x66)

Board does not light-up.

--- Intel P24T at 100MHz (2.5x40)

System is unreliable.
Board does not light-up every time.
Not sure why is that.
Tried hard to figure it out, but without success.

---

Not the fastest assembly out there, but works well at up to 160MHz.
Not great at overclocking and the POD100 issues give me a pause.

I haven't seen any other motherboard with 4 PCI + 2 VLB, let alone with a single 8-bit ISA slot. Interesting layout.

Did the ARK1000VL not work even with the 1ws jumper enabled? I noticed the M919 wanted the 1WS jumper set w/ARK card.

Level 1 cache policy is stuck in WT mode. If force WB mode with an interposer, performance drops significantly.

I'm not sure if you can completely force L1:WB thru WB/WT# pin if the BIOS doesn't have support for it. If it has worked in the past, then probably that BIOS had some WB support.

I've begun setting up my Gigabyte GA-5486AL Rev.2A, which is a PCI socket 3 based on the ALi M1489 A1 / M1487 B1. This board also has some funny BIOS settings, like:

Fast back to back
CPU to PCI byte merge

I will report back when I have some results. The corrosion has hastened over the 8-ish years sitting in storage. Cleaned it up again, but serial ports still don't work. They never worked 8 years ago either. Either the board's pinout doesn't follow one of the two common serial pinout conventions or something else is wrong with it. I've already reflowed the Super I/O and serial chips. Nonetheless, Rio444's PS2 serial port emulator card works, so I will test with this. I've uncovered the undocumented the 50 and 60 Mhz settings, as follows:

50 MHz
JP9, JP8, JP7, JP6
1-2, 1-2, 1-2, 2-3

60 MHz
JP9, JP8, JP7, JP6
1-2, 1-2, 2-3, 1-2

The jumper which is supposed to set PCI = 1/2*FSB doesn't do anything.

The maximum voltage output is only 3.85 V, even on the 4 V jumper, so I'm not sure if I can do any stability testing with my Am5x86 CPUs at 180 MHz. I normally run them at 4 V.

Unfortunately, it contains only single-banked cache, which I'm hoping will work well enough with 256K and 60 Mhz. However, in my notes from when I tested it 8 years ago, I have written, "system is fixed in L2 write-back mode. no write-thru option" But also in my notes is written, "at 33 MHz, ALi M1489 has fastest clock-for-clock memory reads".

My plan was to first test out the GA-5486AL on its own, then put its BIOS into the M918. Has anyone tried the M918 with alternate BIOSes?

I ran a few quick tests at 180 MHz. Indeed, clock-for-clock, it has the fastest DRAM read times. Quick comparison w/cachechk and L2 disabled and fastest DRAM timings:

GA-5486AL
L1 = 184.2 MB/s
RAM read = 70.7
RAM write = 82.5
Quake = 19.5 fps

M919
L1 = 183.5
RAM read = 62.4
RAM write = 82.8
Quake = 19.2 fps

UUD
L1 = 183.8
RAM read = 66.9
RAM write = 125.2
Quake = 19.7 fps

I guess the UUD jumps ahead in the Quake score because of the DRAM write speed when using EDO. I didn't notice any speed difference on the GA-5486AL using FPM or EDO. Maybe EDO is working in FPM mode?

Unfortunately, I don't have any LSD numbers with the L2 disabled. I have timings with L2 enabled, but I'm not sure if this has altered the DRAM read times at all.

LSD
L1 = 186.5
RAM read = 71.7
RAM write = 125.3
Quake = I did not run Quake with L2 disabled on this motherboard.

Back to the GA-5486AL, I could not get 128K or 512K to work at all at 60 MHz. I could get 256K working, but I had to reduce the DRAM read times from fastest to fast, and SRAM timings at 3-2-2 read, 0ws write. This reduced performance as shown below.

GA-5486AL w/256K L2
L1 = 184.2 MB/s
L2 = 66.1
RAM read = 55.0
RAM write = 82.4
Quake = 19.3

Perhaps some fancy cache could work with faster timings. But the board still has this odd limitation of L2 being stuck in write-back mode. I checked modbin for hidden settings, but there weren't any. I ran TweakBIOS, but it could not read the BIOS of this board. CTCHIP34 doesn't have an ALi m1489 file. With 256K, I can CTCM and it showed I have 256K direct-mapped cache in write-back mode. I then ran CTCM7 and it showed I have 64 MB memory and no holes in the L2 cache range, which must be incorrect for direct-mapped RAM. So I installed 128 MB and ran CTCM7 again but then it indicated I have 896 (+640KB) memory, with 6 holes found. It also said the L2 ache range was 897 MB, no holes. It is way off!

Quite a few extension slots on this board.
Unusual for sure.

L1 WB mode:
I use an interposer to force things on hardware level. Works fine if BIOS is handling it. Not in this case.

Ark1000VL is rejected entirely, regardless of wait states.

---

I only have 2 Abit boards based on ALi M148#
Their clockgens don't have jumpers for 60/66MHz, so only tested with 4x50.
They handle well 512Kb singled banked L2 cache at 2111 timings in that configuration.
Retesting several boards at 60/66 is surfacing up in my to-do list.

From my experience this chipset is very good, but not great compared to the best UMC and SiS based boards out there.
So, not surprised you see the same pattern.

I didn't test for it, but I'm surprised you could do 2-1-2 at 50 Mhz with 512KB L2.

Did you have any trouble setting L2 into WT mode on your Abit boards?

Could you share your BIOSes from the Abit boards? What are their model numbers?