Yeah, i know the feeling as i had few motherboards acting like that. Why? I don't know.
Btw, change the keyboard controller and see if that makes a difference.

Hi there! I also have this board ..

pshipkov wrote on 2023-02-25, 22:47:

First in line is Matra 486SLC2 VESA based on EFAR Microsystems 82EC392, 82EC495 (relabeled OPTi 82C392, 82C495B) chipset, hidden under cool stickers with the word "PATH" written on them.
...
The AWARD 4.51 BIOS resembles 486 layout and type of options. There are quite a few timing settings.

Do you happen to have this BIOS dumped? TRW only has the 4.50 BIOS (same as I have on my board).

pshipkov wrote on 2023-02-25, 22:47:

Similar to Alaris Leopard this motherboard was not happy with most VLB EIDE controllers - their DOS drivers hang during initialization.
DTC 2278E worked fine but had to be slowed down a lot which kind of defeated the point of using an EIDE controller. If nothing else it proved that 2278E is one of the most compatible guys around.

I also have a few Leopards, and my usual Promise DC4030VL-2, EIDE4030PLUS, DC200 (ISA) and Tekram/Buslogic DC690C/CD controllers work just fine on those. On this board, however, nothing with a boot BIOS seems to work properly:
- The DC4030VL-2 and DC200 triggers the BIOS, but if external cache is enabled, it hangs when attempting to boot from HDD. It's a full-on wedge; reset required. With external cache disabled, they work fine.
- The Tekram DC690C will not trigger the BIOS at all.
- The EIDE4030PLUS causes "HDD controller failure" after a long pause during POST.

No amount of modifying timings or shadow/cache settings (in system BIOS or controller BIOS) makes a difference. I have also triple-checked the onboard cache; it does seem to be configured correctly.

Do you have any idea what might be wrong here? I'm hoping a newer BIOS might help. There should also be an MRBIOS out there for this card, but I haven't seen it..

Nevermind most of the below: Seems like my upper 128KB cache was bad; reducing to 128KB allowed the system to boot with the DC200 and the 4030VL-2.

My sysbench scores are about the same as yours. I'd like to find RAM that is fast enough that I can use "quick write" as well, not just "quick read".

Also curious how much past 80MHz I can push the CPU, but that's for another day .. first I have to find out why the cache is bad.

At least now I can run a 3-card VLB system - VGA, IDE *and* Ethernet :D

/Eirik

ltning wrote on 2026-02-16, 22:41:

Hi there! I also have this board .. […]
Show full quote

Hi there! I also have this board ..

pshipkov wrote on 2023-02-25, 22:47:

First in line is Matra 486SLC2 VESA based on EFAR Microsystems 82EC392, 82EC495 (relabeled OPTi 82C392, 82C495B) chipset, hidden under cool stickers with the word "PATH" written on them.
...
The AWARD 4.51 BIOS resembles 486 layout and type of options. There are quite a few timing settings.

Do you happen to have this BIOS dumped? TRW only has the 4.50 BIOS (same as I have on my board).

pshipkov wrote on 2023-02-25, 22:47:

Similar to Alaris Leopard this motherboard was not happy with most VLB EIDE controllers - their DOS drivers hang during initialization.
DTC 2278E worked fine but had to be slowed down a lot which kind of defeated the point of using an EIDE controller. If nothing else it proved that 2278E is one of the most compatible guys around.

I also have a few Leopards, and my usual Promise DC4030VL-2, EIDE4030PLUS, DC200 (ISA) and Tekram/Buslogic DC690C/CD controllers work just fine on those. On this board, however, nothing with a boot BIOS seems to work properly:
- The DC4030VL-2 and DC200 triggers the BIOS, but if external cache is enabled, it hangs when attempting to boot from HDD. It's a full-on wedge; reset required. With external cache disabled, they work fine.
- The Tekram DC690C will not trigger the BIOS at all.
- The EIDE4030PLUS causes "HDD controller failure" after a long pause during POST.

No amount of modifying timings or shadow/cache settings (in system BIOS or controller BIOS) makes a difference. I have also triple-checked the onboard cache; it does seem to be configured correctly.

Do you have any idea what might be wrong here? I'm hoping a newer BIOS might help. There should also be an MRBIOS out there for this card, but I haven't seen it..

My notes are about overclocked systems. Will reword the previous posts to clarify that. But i doubt this is actually a big factor.
Will retest with Alaris Leopard soon as i dont have the Matra board anymore.
What video card you are testing with?
Did you test the VLB EIDE/SCSI adapters with their DOS drivers loaded? That's were i had problems.

Will link your posts here from my older posts as you bring a change to the story. Thanks.

Yes, 4.51 BIOS version, but recent NAS issue corrupted some files. Including this one.
EDIT: May ask the new owner of the board to provide the microcode.

Here is that Matra SLC bios. I have not really gotten around to playing with the board yet. All my free time has been tied up in 286 overclocking or RealDOOM development.

I have run a similar board (IBM 486SLC2) at 80 mhz before. Some benches were recorded here:

https://www.youtube.com/watch?v=9kKBbYy0zoM

I see you managed 2x50 mhz as well, very cool. I recall i had to do multiple boots with different jumper positions to trigger a boot at these speeds. I wonder if a 50 mhz clock was possible somehow, but I also don't just have spare IBM SLC/BL chips lying around to bin like I do with other processors.

I also have some recordings of 286 at 37.5 mhz on the SCAMP chipset there. I have posted as high as 41 mhz, really the RAM and then CPU become the limiting issue.

Some notes on video cards...

Recently I discovered the ET4000W32/I to be my best performer, but they are a little hard to find. Aside from that, the 5426/5429 based Diamond Speedstar Pros are pretty common and should outperform ET4000AX, but it's close. They do regularly tolerate bus speeds of 33-37 mhz while most ET4000AX fail around 24-25 mhz. Mostly i think this results in better synthetic scores (chr/ms and such) but it doesn't translate to a lot of fps gain in game etc benchmarks.

I may modify a 5434 bios soon for 286 compatibility. I disassembled the diamond one a while back ( https://github.com/sqpat/5434bios/blob/main/5434bios.asm ) and determined it shouldn't be too much work. Ironically the 32 bit code is mostly looking for the pci bus for conflicting vga cards on the bus, to disable the isa card if a pci vga card is found. It's a bit obfuscated and I haven't gotten around to it but I had interest it seeing if it would outperform the other top ISA cards in dos performance.

First of all - thank you for the quick turnaround providing the bios.

Let me unpack your post as it is contains quite a bit of interesting information.

Real Doom - very cool. Been watching on and off that project.
Did you consider unreal mode access to extended memory?
This may be perf net-negative for 286 cpus - tbd. And a deal breaker for 808#. But still.

Share more info for the SCAMP 286 overclock. Is it long term stable? Which motherboard? This chipset is very slow, maybe thats why it offers such overclocking room.
What CPU was used? So far all Intersils and Harrisses here start to flake at ~35mhz on air cooling.

I assume you are talking about ISA video cards, correct?
My findings are similar. ET cards are good if playing safe, otherwise CL gets you much further.

Getting CL GD-5434 to be 286 compatible will be very welcome. Let us know if you make it happen.

Hmm. I don't think unreal mode will be great for RealDOOM, segment changes are frequent and my understanding is they are quite slow when descriptor caches are involved. It would also not be a very easy rewrite from the current code due to a lot of assumptions in the code about things being in real mode, segments 16 bytes apart, etc. More likely is an EMS 3.2 version that would be more compatible with chipsets such as HT-12, NEAT, etc. This will probably also come with a 10 or 15 percent speed loss too though, as I can't maintain large texture caches.

---

The SCAMP overclock came off a Biostar MB-1220VS. One neat thing is it has a separate crystal for bus and cpu clock so you can actually run them at completely independent speeds, including a faster bus clock than cpu clock. I have run bus as high as 43 mhz I believe (with slower cpu clocks). As for stability, at 37.5 mhz maybe it could be stable eventually. I do not think the chipset or cpu in my case are the problem, the problem is really the ram at 0 ws. I don't have ram that can keep up with those speeds. I think I actually put the ram and video card in the freezer for 5 minutes to get the 37.5 mhz case to work (a nice quick and easy alternative to peltier etc for light testing, put it in a bag in the freezer to precool to near freezing temps). I since have gotten more stable video cards but RAM is still an issue. Anything over 33 mhz or so is always a problem for long run times. If I had RAM tolerant of higher speeds, then I think 37 might be stable for the machine. I might have to try some things like windows, etc to see if the graphics card is stable outside of dos in some other applications. I even have some simms with FPM drams marked 45/50 ns but they do not keep up with some of these ibm branded 60 ns chips. I'd really like to investigate modern faster ram designs at some point in the future. In the worst case, maybe a dram module benchmarker, such that individual simms could be put together with high performing dram modules only.

If I had faster ram with a lot of overhead, I would love to try to get some bench high scores and pushing a chip with peltier/etc past 45 mhz, maybe even 50 on the board. But if i wanted to stop somewhere stable, I think 35-38 range would be where I would stop. The graphics card starts to glitch in some video modes a few mhz above that, and I would want to give the cpu a little bit of breathing room too.

As far as stable performance, this reminds me - One thing I have experimented with is sanding the tops of 286 cpus. You can sand several mm off the top of the 286 and reveal the copper(?) ground plane inside the cpu eventually. (My understanding is the core is on the underside of the PLCC packaging). If you get to the copper core, my experience in air cooling is that now you can maintain higher stable temperatures than before. For example a cpu that posts at 34 but crashes after 3-5 minutes of running will run at least 15-20 minutes, maybe indefinitely in this state. I attached an example photo.

On the subject of fast 286, I've been thru a few hundred chips and binned quite a lot. I think in general the "cs80c286-25" available from china is in the best case rebadged cs80c286-20 (and sometimes outright different plcc68 chips), so I've stopped buying the 25s and started buying more 20s because at least they are less likely to be modified with faked batch codes and dates and I can collect better information on chips. Of these 20 mhz chips, yeah I think in general 34-35 mhz starts to become difficult to beat. I think if you can find date codes before 1994 or so, the silicon seems to be better, or maybe it was less aggressively binned to other SKUs back then. All my really good chips seem to be in those dates. I have some guesses but no evidence - I think maybe they started to bin better chips and selling them as IS80C286-20/25 after some date. I can't find any legitimate stock of these outside of the ones that are priced very expensive.

I have purchased many of the new stock chips (intersil, harris..) as well. They are usually disappointing, most are in the 27-31 mhz range. I can't say for sure that they will all be this way, but when you buy the new chips you will keep getting the same batch codes, so it's not a surprise the performance will be very similar across them. I have tried to ask suppliers for older stock but they more or less just ignore you. Maybe there do exist good newer chips too, but I haven't seen them and its hard to get variety.

In the past 1-2 years there was a seller on ebay with some legitimate cs80c286-25 stock in the US, and there have been a few with cs80c286r1787 stock. Some of those cs80c286r1787 will do really well. If you have one soldered to a random ht-12 board or something it might be worth desoldering and checking out on another board. I think they are all early 90's chips from the same general stock that made cs80c286-20/25.

---

I also attached a photo of a fan mount i 3d printed for a 286 in this state. To be honest the airflow is not great. Probably better off with a case fan sucking airflow thru the front of the case is much better, but it's cute. The mount essentially must be glued to the top of the cpu and the fan is offset a bit such that the air should hit the fins of the heat sink. If you have any interest I can post those stl files.

M2 heatsinks are conveniently perfectly sized for cooling 30 pin SIMMs. It will require some sort of thermal glue or tape to stick to the dram modules. I have not been able to determine this helps with stability. I think the dram packages overheat before they can be cooled thru their packaging.

Rodney over at the vcfed forum has been working on 286 board designs for a couple years. https://forum.vcfed.org/index.php?threads/pro … m-5170.1243108/

His most recent work is on a FPGA based chipset, which is not complete yet. But prior to this was a CPLD based chipset. He built it with SRAM, but it turns out SRAM is not as easy to get 0 ws because of the way 286 pipelines high address bits which is more conducive to dram and chip select. He got that board stable at 20 mhz though, and designed an EMS 4.0 compatible memory controller and I wrote an EMS driver for him and he ran RealDOOM on the board which was very cool. I've sent him some hardware and faster chips for him to be able to tes this designs with. Who knows, maybe the FPGA design will reach 25-30 mhz with 0 ws as he experiments with different things. He has also experimented with TOPCAT and SCAMP based designs.

Never benchmarked “direct” memory access via unreal mode against EMM386 based paging, so speculating here...
EMM386 access is fast within the mapped page, but switching pages is expensive. If the source data for rendering is spread across different pages, that can be very costly at runtime.
Unreal mode is established once at the start of a session, after that extended memory is accessed directly with no additional overhead.
It is a headache for 286 processors and not an option for 808# entirely, so at best, it can be a side-by-side optimization and a further fragmented codebase.

Thanks for expanding on your 286 overclocking activities. Very interesting.
Without particular order ...
The highest long-term stable overclock in terms of CPU frequency that i was able to achieve was with Ilon USA M216A motherboard - 35MHz, simple air cooling. Like you, i had to increased DRAM wait states. With the chocked DRAM i was even able to run 16Mb buffer - kind of crazy for such FSB speed. The board is slow by itself on top of that. At the end, the actual performance was disappointing - much lower than what a sharp 0WS VLSI-200 or Headland HT-18 can do.
Do you have any perf metrics from your 37MHz tests on that Biostar motherboard? I still have a SCAMP board around here. The chipset seems to be relatively slow on a clock-to-clock basis - maybe that allows it to climb steadily on overclock. But my board does not overclock well at all. Need to double check that now.
I confirm your findings that 45ns 1Mb FPM RAM perform worse than selected 60ns ones. Wonder if these 45ns chips are actually relabeled fraud ...
Good notes on the 286 CPUs. Will watch for these cs80c286r1787.
Is sanding the CPUs to metal actually helps? Any before/after metrics?
How is your fan contraption attached to the heatsink? It almost feels that you need a bigger heatsink with directly attached to it fan.
Btw, recently put together a fan funnel that turned out quite well - big fast fan at the entrance compressing the air down = increased airflow. Sharing for reference.

Oh, here were some bench recordings from the 37.5 mhz run:

https://www.youtube.com/watch?v=oIMfdz-EzTA

Looks like this one had 98 on topbench and unfortunately the 3d bench run crashed. I did a screenblocks 9 quality 2 run of realdoom timedemo 3 in 3913 realtics (which doesn't mean much by itself, but my 386DX-40 with 256kb cache and ISA tseng et4000ax achieved 3693 on the same version, which is almost 1:1 perf per clock). I must have some other videos on the pc that recorded these, I will have to check. Most of my youtube uploads have been realdoom related.

With Hercules ISA Bus Dynamite (ET4000/w32i) I managed:
4 sticks at 0 WS, 33 mhz: 12.9 3D bench, 92 Topbench, 47.53 Landmark, 13,107.20 chr/ms
2 sticks at 0 WS, 37.5 mhz: 99 Topbench (Freezer-cooed DRAM)
2 sticks at 0 WS, 38.4 mhz: 100 Topbench (Freezer-cooled DRAM)
These were pretty short power ons, I was definitely pushing the ram hard and booting with turbo to halve clocks. I think I really just wanted to hit 100 score there.

It seems I did a 1 WS run of topbench at 41.25 MhZ (with CLGD5426) and achieved 94 on topbench, but overall it was not too stable. When I push the video cards really hard i also tend to get glitches, sometimes in text mode and sometimes in video modes. If i had tried with the Hercules Dynamite maybe it would have been more stable.

My best 3D bench score (14.2) came at 38 Mhz with a ATI Mach32 (Freezer-cooled DRAM). This one card is stable up to 43 mhz, but does not post great synthetic scores so it does not do well in topbench for example.

I did not bench wolf 3d too much but did once get 2294 / 21.7 with just 33 mhz and a tseng et4000ax. Most of my scores have been 3DBench (if i want something fair), TopBench (if i want something a little bit synthetic), and otherwise RealDOOM.

I feel my good sticks are degrading slowly as I put them thru these more extreme overclocks, so I have been using them a little less. I have meant to try more 1 ws overclocks with 4 sticks of ram. The wait state robs 20-25% performance but the 4 sticks of ram and interleaving ought to gain back 5-10% , then I can probably also easily increase clocks another 5-10% and earn back most (but not all) of the performance loss.(I also notice with this scamp board that 4 sticks is less stable at the same clocks than 2, I think the interleaving performance boost also simultaneously works the ram sticks harder.

---

On other chipsets...

I don't know if you ever saw those JCS "router" 286 boards with the SCAT chipset that were on ebay over the past few years. I picked up a whole bunch of them because the chipset handles EMS 4.0 and works well with RealDOOM. They are CHIPS SCAT chips with the 16 mhz stamp on them. They all seem to reach around 26, 27 mhz before failing and otherwise handle 25 mhz great, even though they came stock with 12 mhz chips. They also have a 72 pin simm slot header which is not too hard to solder a slot into, allowing for an 8 MB simm which i think is treated like 8x1MB 30 pin simms, you get quad bank interleaving performance. It's a nice no-nonsense 286 board. With a Tseng ET4000AX, 25 mhz they do 10.0 in 3dBench and 65 in topbench which is not bad.

In general I think those headland HT-12 boards do great perf per clock but they seem to fail around 23, 24 mhz. A CHIPS NEAT with quad interleave can also have similar performance but also tends to fail at similar speeds in my experience. SCAT is sort of in this same ball park of performance but tends to fail around 27 mhz on the high end versions. I don't have enough experience with HT18/HT21 but i have a board or two lying around I would like to test more thoroughly. The HT18 like the SCAT, SCAMP, TOPCAT has EMS 4.0 functionality which I like because it means it will run RealDOOM. I actually don't have a 286 TOPCAT - my understanding is actually it does not overclock as high as the scamp, even though it is newer and has some more advanced features (both VLSI).

---

EMM 386 pagination is relatively slow, but segment changes themselves are still quick in real mode. In RealDOOM pagination is fairly infrequent but segment changes are very common. For example when we switch from physics to render once per frame, we page most of 384kb of pageable memory at once. Then within render mode, we fairly infrequently page again because there are all kinds of texture caches etc in play, Anyway, the goal is less about a 286 or a 386 specifically and more about having something that runs in real mode, so if its something that makes my 5150 no longer run it then I won't bother with it anyway. But the performance on a 386 is really good too, possibly faster than FastDOOM on a 386DX depending on machine and definitely on a 386SX. There are also some plans to basically have a built-in faster EMM386 like implementation such that EMS interrupts can be bypassed an the pagination can be inlined into the code in 386 modes.

I wanted to add a bit more info on a board I feel is very special (if you like all ISA 486 boards that is). The DTK PKM-0031Y based on the Symphony Haydn II chipset. I had previously posted about my experiences with one of these boards a few years ago here: Re: 3 (+3 more) retro battle stations, and finally have found more time to deal with another spare I have. I had to remove the dead Dallas RTC and install a socket and an aftermarket Dallas replacement, replace the original 66MHz crystal with an 80MHz crystal for 40MHz bus, replace the 20ns 64kb cache with 256kb of 15ns cache, install an Evergreen 5x86 upgrade CPU jumpered to 4X multiplier, install 32MB of 9-chip 60ns SIMMs, put the BIOS on a 45ns EEPROM in place of the original 150ns EPROM, and put board on my test bench with a Paradise WD90C31 1MB ISA video card, and a DTC 2230 ISA controller card and a floppy drive - no hard drive used yet.

Here are my basic results below with the 5x86 at 160MHz, and the ISA bus at 16MHz stable. 3DBench 1.0C turns in a score of 68.4FPS!!!! Who needs VLB 😀 😀! And the speedsys results look nice too. I will post more from Phils benchmark suite once I get a hard drive installed. Also I have attached a rare 1992 version of the Ami Color BIOS to go along with the 1991 version originally supplied by forum user 'Anonymous Coward' that will work on the DTK PKM-0031, PKM-3331 boards that have two 486 sockets. This 1992 BIOS doesn't work correctly on the very similar PKM-0030Y with the Weitek socket though (hangs when saving and exiting and may/may not save your changes).

@386DX40

As stated, multiple times before - this chipset is the 386/486 ISA blaster.
16MHz ISA bus is great. Cannot remember if the board offers more favorable dividers to boost it further. Need to look that up. It diminishes the need to move to VLB.
What numbers you get in Doom and Wolf3D?
Thanks for the BIOS.

---

@sqpat

It is awesome to see such peak overclocks. I understand they may not be long term stable but still 40+ MHz on a puny 286 - impressive.
Superscape at 14.2 is the highest number. Wolf3D running at 33MHz however is lower than what i would expect - probably chipset and DRAM wait states.
I may add RealDoom to the benchmarking suite here. Looks like a great candidate for pumped 286es.

These router CHIPS SCAT boards may be the best assemblies based on this chipset, as everything else SCAT i touched is just weak. Good tip. Do you have a pic or a TRW reference for them?

I had good experience with HT12/16/18 boards. At least better than what you are seeing on your side. Wonder why. Especially HT18 is a beast. But i didn't do anything with EMS on them, but RealDoom is a forcing factor for it as most assemblies come up with support for up to 4-5 Mb of maximum system memory.

I spent a moment to actually benchmark EMM, XMS and unreal mode. Here is the result running in dosbox, 386DX33 profile.

Testing approach:

Unreal mode - accesses locked XMS memory directly via unreal mode segment state, then measures 1KB read/write throughput with wrapped 16Kb offsets.

XMS mode - using a well optimized library around XMS API (follow the DOS-media-library link in my signature).
Uses xms_copy_from_xms and xms_copy_to_xms for each 1Kb chunk.

EMS mode, 1 page-in - maps one EMS page then repeatedly copies 1Kb chunks within it.

EMS mode, 8192 page-ins - performs a page map before every 1Kb chunk access. Demonstrates worst-case data locality for EMS.

For unreal and EMS modes two methods of data access implemented and reported:
- custom asm path (rep movsd), no INT 67h per chunk, closest to raw CPU memory access
- standard memcpy

So, if my testing is not entirely wrong, it looks like the order in terms of performance is like this: XMS, unreal mode and EMS with ideal data layout, then EMS with suboptimal data layout.
EDIT:
Friday evening here and now i can think more carefully about what i observed early in dosbox.
It didn't make sense for XMS driver to be so much faster than movsd and memcpy techniques used in Unreal mode and EMS tests. Something is off in the dosbox emulated environment.
Ran the tests on a real hardware (Alaris Cougar II + IBM BL3 100MHz (2x50)) and the results are a lot more in-line with my expectations.

Unreal mode offers the highest throughput to memory above the 1Mb, then EMS with good data locality (minimal paging), then XMS, and finally EMS with unfavorable data locality. Now that last case is not guaranteed to be slower than XMS as if data layout is not too bad the number of page-ins can be small enough to outperform XMS API.
The lesson here is that emulators can be misleading.

Unreal mode implementation is targeting 386 or later CPUs only. It will be interesting how this goes for 286 processors ...

(can share code for cross-checking of approach)

Yep, I've had a lot of 486 hardware over the years, and this board is by far my favorite. Anyways I did hook up a hard drive to my test bench and got some additional numbers. I will consider this project a success! Sorry no Wolf3d benchmarks yet, give me a bit and I will do so.

By the way the VGA card appears to handle the ISA bus at 20MHz but my various controller cards laughed at that, no floppy/HDD access.

Ok, found the Wolf3D benchmark file set located earlier in this thread and ran it.

Re: 3 (+3 more) retro battle stations

@386DX40
Great perf indeed. Thanks for sharing.

---

Edited my post above with some updates to the information i shared regarding different memory access techniques.
It is best to run such tests on a real hardware.