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
Compare access mechanism overhead under the same logical I/O pattern.
Simulates 32MB of memory I/O, represented by 64Kb working window. Throughput is reported as Kb/s.

Unreal mode
Measures CPU-level unreal access cost, plus unavoidable write-side segment/mode overhead.
Locks a 64KB XMS block, enables A20, enters unreal mode, copies with custom assembly.
Read path is direct FS-based copy from extended memory.
Write path includes per-chunk CR0 toggle to load ES with the unreal descriptor, then copy.

XMS test:
Measures XMS API cost per transfer: driver call + move struct handling + internal transfer.
Uses xms_copy_from_xms / xms_copy_to_xms functions from a well optimized library around XMS API (ollow the DOS-media-library link in my signature) for each 1KB transfer with the same scattered offset pattern.

EMS test
Measures page mapping overhead amortized over 16 transfers plus the far memory transfer cost.
Allocates 4 EMS pages (64KB total).
Performs 16 1Kb accesses inside one mapped page, then remaps to another logical page.
Data movement uses _fmemcpy.

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 the XMS driver to be faster than Unreal mode and EMS. 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, then EMS, then XMS.
The lesson here is that emulators can be misleading.

Note: unreal mode implementation is targeting 386 or later CPUs. 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.

Sorry I missed some points earlier -

About the sanded 286:
I generally run into similar performance when testing my various chips to failure, for this example let's consider a chip I tested "good to 34 mhz"

~37 mhz: post limit with peltier pre-cooling
~36 mhz: -- -- post at ambient temps
~ 35 mhz: starts post, usually fails to boot into OS
~34.5 mhz: manages to boot, has filesystem errors soon after boot, etc
~ 34 mhz: runs stable 3-5 minutes on air cooling, enough to do some benches
~ 32-33 mhz: runs well on air cooling long term.

So in my experience if you take this chip and sand it down, it should be able to run 34 mhz long term now instead of 32-33 mhz. Normally the chip cooks itself before the heat is able to escape the plastic packaging. But with the plastic layer out of the way you can get the heat to escape fast enough to prevent this.

Some notes if anyone is going to attempt that: 1. practice sanding technique on undesirable chips first. Keep an eye on the edges of plastic. You usually have to change angles based on which side has more plastic left, sanding in a circle can have a tendency to build a dome with a raised middle and you actually want the opposite - you want to reach the middle as soon as possible. ALSO - you don't want to breathe microscopic plastic fragments. This stuff is toxic, might as well be breathing asbestos. So use appropriate ventilation and good breathing mask, etc.

---
Router SCAT Motherboard:

This is the one: https://theretroweb.com/motherboards/s/jc-inf … ration-jcs286-s . I think there is a vogons thread about it.
I'm very curious where these routers came from. I wonder if the token ring router model is known.

With SCAT or NEAT, max performance should be achievable if all 4 banks are populated to max out interleave gains. I think not every board exposes 4 banks. Also I've had some poor performing SCAT boards that cant do more than 12 mhz, so the key seems to be to find the 16 mhz stamped chips? This seems to be equivalent to my experience with SCAT as well.

I'm very curious about the GW286 CT GEAR motherboard. I have one that is not working, but seems fixable. It has the 16 MHZ stamped chips and I'm familiar with it because 86box emulates it. I think this board was sold in Europe and not the US (like many other fast 286 boards) so it took a couple years of looking just to find that broken one.

---
Memory types:

In RealDOOM, most memory operations are probably 1-4 byte prefetch (depending on bus width) by the processor, and large copies are pretty rare. And almost never are large copies over 16kb or 64kb or whatever. So the comparison of large memory copies with in-between repagination logic doesn't represent program behavior.

One thing I'm not clear on - does Unreal Mode involve descriptor caches being updated on segment changes? If so it just won't work from a program perspective for various reasons. Segment registers are regularly used to cached 16 bit register values without going to cache for example, and LES etc often used to load dwords. These values that get stored in the segment registers are logical values and have nothing to do with memory mapping.

Chipset builds (SCAMP/TOPCAT/SCAT/HT18) have extremely fast pagination because I just hit the chipset registers directly, no function call and no interrupt. It's more or less just a 'rep outsw' call to change multiple page paginations so 384 kb could probably be remapped in under 100 cycles for example.

There is a custom embedded virtual 8086 mode in the works for RealDOOM that zer0318 wrote and hasnt been tested yet. LikecChipset builds this should be 1-2% faster than using the EMM386 or other ems driver. This will also use less memory and is probably represent the fastest it will get on 386, since we directly hit the page table to remap memory on the fly.

Anyway, at the end of the day the program is called RealDOOM and not UnRealDOOM, so if it doesn't work on 8088 hardware it kind of goes against the spirit of the project. For the same reason, 286 protected mode and other such things weren't considered.

Thanks for the "shaving" notes and what the skinny 286 chips deliver - basically, increase of overclocking limit by ~3-6%.

This CHIPS motherboard looks quite tight indeed. Did you try the SIM slot already?
I have seen 72-pin slots on 386 motherboards, but this is even more weird.

About GW286
Unmarked main IC - clearly a hybrid 286/386 silicon. BIOS is 386-like - lots of options. Supports up to 16Mb of RAM. Slow, very slow board. With all BIOS settings on max it is still choked by wait states or something. I guess that allows it to scale well on overclocking, but even at 33-35MHz long-term stable its performance is nothing to write home about.

Yeah, i looked at the RealDoom repo (very cool stuff) and counted a bit.
If i get it right:
The runtime dataset of about 100 EMS pages.
It is composed of several caches in the range of ~30-400Kb each.
Over 20 page-ins per frame (game tick + render) and over 100 memory access calls within the mapped pages - what you said - bits and bobs per access.
So, yes, the pattern is quite different than my simple test.
Btw, in case it was not clear - i am not pressing for anything at all - unreal mode or whatever. Just chatting as you got me thinking about that stuff.

Didn't understand the meaning of "embedded virtual 8086 mode" - in the form of a driver, or something bound to the RealDoom runtime?

Hmm too bad about the GW286... did you try full memory slots? Four way Interleaving should help at least 10%. Wait states would be a problem though. If iI can get mine working I'll need to try a different BIOS or hits the chipset directly to see if I can force 0ws. I did notice the 86box performance was terrible but I had assumed it was just inaccurate emulation.

Yep, the SIMM slot on the JCS router board works just fine with an 8 MB stick. I use those slots exclusively, otherwise the dips just get you to 2 MB. One thing that comes to mind is the boards all failed around 27-28 mhz, and I wonder if that is just the speed of most of these 60 ns sticks. Maybe if i tried an EEPROM, and tried different sticks I might even get it to work faster than 27. Usually I just run them at 25 mhz as a baseline for benchmarking though.

RealDOOM - yes theres about 100 EMS pages, the idea is 256 KB + 2 MB EMS, which includes 384 KB backfill to 640kb, leaving about 104 swappable pages.

As for embedded virtual 8086 mode I was referring to the idea of including our own page table. Almost like emm386 embedded in the program. The 386 supports virtual mappings of memory in 4 KB increments. You point to some page table in memory for the virtual mappings and we'd make these equivalent to the EMS mappings, just that there's four repeats to get 16 KB level pagination. I'm sure EMM386 internally works this way to some extent to provide EMS-like mapping. Then instead of calling int67 to have emm386 adjust the virtual memory mappings with all the interrupt overhead we would inline update entries to the page table which would probably be cached in FS/GS or whatever throughout runtime. It would be configured to work in real mode but point certain memory regions to virtual addresses to get access to higher memory. These tables and entries could be statically included in the EXE or loaded somewhere in memory after startup. It would not be compatible with emm386 and you would use it in place of an EMS driver. (These things are always tricky to make play nice with other drivers that may try and use XMS, etc though.)

I have a few fast 287s and had not really experimented with them much but I think you said some of those Cyrix ones should be good up to high clock speeds? That's interesting and I might try it out. There are some large division operations I might want to try out FPU performance on with RealDOOM. If the FPU can keep up with faster clocks, then thats especially great.

Makes sense. Let's see how this pans-out.

Yeah, many 25MHz rated several 287 chips can go 30-35MHz, but not sure if FPU heavy code will get you anywhere performance-wise for realtime graphics on this class machines.

Which FPUs are actually rated for 25MHz? The only one I know of is the IIT.
The Intel 287XL only claims up to 12.5MHz on the box, large due to intel not making 286s faster than that, and I don't recall with the Cyrix, but at least the original 82S87 was only rated up to 20MHz. Maybe the Cyrix 287 with the revised core was actually officially rated for 25?

Take a look here - one of the intermediate steps before arriving at 30MHz 0-wait-states (implied long-term stable).
3 FPUs do well at 30MHz or higher.
My wording in the previous reply was incorrect. Scratched part of it for correctness.