Chronologically the stable-ish 3x33 Alaris Cougar came after the DTK PEM-4036Y + BL3 post you looked at.
The Cougar numbers there came from previous data where i had to slow things down for improved stability.
Updated the charts with the latest perf metrics. I think this is fine because nobody will is going to flip through all the pages to find the chain of events.
You will need to hard-refresh the page/post to see the updated images.

In short - Alaris Cougar 3x33 with 0-WS Diamond S3 Trio64 produce 27.5 fps in Doom. Ark1000VL never completes that test.

I tried to flip through your data, but it was not always clear to me which FSB and which graphics was being employed.

Hmmm... I guess the extra 1 fps the Cougar gets compared to the Panda could be attributable to the chipset or BIOS features. Looking at TwkBIOS for the Panda board, there's at least 50% of BIOS settings hidden, which is unusual.

I know what you mean. Thread and its data swell too much, that's why i started consolidating benchmarked numbers and sanitizing the individual posts accordingly.

Cannot tell why the perf difference between Cougar and Panda boards.
They are different architectures based on common specifications (386, buses, etc).
So naturally chipset + BIOS microcodes bubble up to different performance.

What is more interesting to me is that your Symphony board with same CPU and video card lags a frame or two behind what i see here.
Looking at the board - it is the same chipset, same amount of cache and as far as i can tell same BIOS (including used settings), basically same everything.
So, why the difference ?
Can this be DOS version or something in the software setup ?

Could be. I'm using MS-DOS 6.22. If you can run by me exactly what hardware (motherboard, CPU, FSB, RAM, etc) you are using, which software, which BIOS settings, and drivers I can look into it. I assume you are referring to the Symphony ISA board. I should have this back on the bench tomorrow to investigate your comments concerning DOS=UMB and LIGHT486.SYS.

I did try XTOUT=0 and gained about 20 realtics.

Could you refresh my memory - is the Kingston Light486.sys the driver which requires using the installer, which then modifies the *.sys driver file? I remember one such hardware driver doing something like this, which causes us a headache.

Yes, some installer tried too hard to help, cannot remember if it was the Kingston one.
I just call LGHT486.SYS /2 in CONFIG.SYS and that's it.

That appears to be the same Kingston driver file I also have. I bet there was only one revision.

I have taken some time to analyse your comments concerning the LGHT486 vs. REVTO486 drivers. I have updated my thread concerning various CPU processor register settings, Register settings for various CPUs

In short, the Kingston driver has a non-optimal FPU setting which showed a marked reduction in performance, at least in Landmark Speed test. On the flip side, the Kingston driver has confirmed my suspicion, that XTOUT = 0 . This is the source of your increased performance from DOOM using the Kingston driver. There's one other notable setting difference, that is, disabling L1 while not in use. Kingston does this by default, which costs 4 realtics in DOOM, but since we are overclocking these rare processors, I think it might be the preferred setting. My full diagnosis is as follows.

The Evergreen driver and the Kingston driver setup the register a little differently. The most notable concerning performance are:

Processor Operation Register, Byte 1, or 1000h:1
Bit 7, CNPX - REVTO486 sets as 1, while LGHT486 sets to 0. The optimal setting is 1. Setting it to 0 drops FPU performance, as witnessed in Landmark Speed from 224.8 to 203.9

Bit 4, XTOUT - REVTO486 sets as 1, while LGHT486 sets as 0. The optimal setting is 0. Setting it to 1 drops DOOM score by 49 realtics.

These two settings can be set optimal using CTCHIP34. The command line option for this would be:
CTCHIP34 IBM486 /1000h:1:=%1xx0xxxx

If you are wanting to place this in autoexec.bat, you need an extra %, that is:
CTCHIP34 IBM486 /1000h:1:=%%1xx0xxxx

If for some reason, it is still not working correctly with autoexec.bat, use HEX syntax (but cannot set don't care's):
CTCHIP34 IBM486 /1000h:1:=8C

Processor Control Register, Byte 3, or 1000h:3
Bit 4, CLP - REVTO486 sets as 0, while LGHT486 sets as 1. Setting this to 1 lets the L1 cache turn off while not in use to save power, but doing so drops 4 realtics in DOOM. However, if you are overclocking your CPU, and given the rarity of these chips now, it may be more beneficial to turn L1 off while not in use.

If you want to force disable of L1 power savings, use CTCHIP34 IBM486 /1004h:3:=00

If you want to force enable of L1 power savings, use CTCHIP34 IBM486 /1004h:3:=10

Many systems have trouble with the IBM Blue Lightning BL2/BL3/DLC3 chip. Use HIMEM with /TESTMEM:on for an initial test. The following HIMEM settings have helped the BL3 work on many of my systems,
/MACHINE:1
/CPUCLOCK:ON

e.g. in config.sys, DEVICE=HIMEM.SYS /TESTMEM:on /CPUCLOCK:on /MACHINE:1 /V

The best outcome appears to be loading the REVTO486.SYS or LGHT486.SYS right before HIMEM, however this may lead to a HIMEM error. On my SiS Rabbit system, I have thus set /TESTMEM:off and have not witnessed any issues in DOS or Windows 3.11

You can also load REVTO486.SYS after HIMEM, but for applications in DOS/WIN311 to run properly, I have had to set DOS=UMB in config.sys rather than DOS=HIGH,UMB. Thanks to user pshipkov for this hint.

There are also some slight differences between REVTO486.sys and LGHT486.sys which I have not noticed any performance differences. These are as follows.

Processor Operation Register, Byte 0 or 1000h:0
Bit 6, DBCS, Cache Double Byte Character Set. REVTO486.sys sets this to 0, while LGHT486.sys sets to 1
Bit 1, CPC, Cache Parity Checking. REVTO486.SYS sets to 1, while LGHT486.sys sets to 0

Cache Region Control Register, Byte 3, or 1001h:3
Bits 7-0, LMROR, 1 Meg Read only hi-byte. REVTO486.sys sets this to 00000000, while LGHT486.sys sets to 00010000

Cache Region Control Register, Byte 1, or 1001h:1
Bits 7-9, LMCR, 1 Meg Cacheable hi-byte. REVTO486.sys sets this to 00000011, while LGHT486.sys sets to 00010011

Great details. Thanks.
I tried ctchip34 before but it didnt make a difference, or better i didnt pay attention to subtleties like what you defined above.
Testing your recommendation now. I am not convinced yet it works the way you described it. Will clarify later.

As for not able to run the ctchip34 command from within autoexec.bat - simply escape the % character by prepending one more % to it.
It is a special character used in batch scripts.

Ok, i confirm that CTCHIP34 improves slightly on FPU performance.
Great hint. Appreciate it.

The best combination of drivers looks like this:

CONFIG.SYS

1DOS=UMB
2DEVICE=HIMEM.SYS /TESTMEM:OFF /M:1
3DEVICE=LGHT486.SYS /2

AUTOEXEC.BAT

1CTCHIP34.EXE IBM486 /1000h:1:=%%1xx0xxxx

Noticing something unexpected with DOS=HIGH (or DOS=UMB,HIGH).
Actually, i believe i stumbled upon this before, but forgot.
Remembering it now. Basically,
If DOS=UMB,HIGH then MSDOS.SYS gets partially moved out from the conventional memory.
Free conventional memory grows to about 620Kb which is pretty nice.
Unfortunately in this configuration the BL3 CPU performance drops significantly.
Test apps still see the CPU running at 100MHz. So something else is at play.
If DOS=UMB then the available conventional memory shrinks to 560-570Kb, but BL3 performance is as expected.

Note that the himem handler setting of /M:1 is the same as /MACHINE:1

How did you figure out the mishap with CTCHIP in autoexec.bat whereby you need an extra % when designating a binary value? It appears to work, but how did this occur to you?

With the DOS=UMB setting, do you have enough conventional memory to run Wolf3D?

Could you let me know which of your BL3 systems you are able to run LGHT486 or REVTO486 drivers before HIMEM with /TESTMEM:on and not receive an error?

About %%.
Check my previous previous post, in case you missed it.
Basically, variables in DOS batch scripts start with the % sign, or are enclosed by it.
Escaping special/illegal characters in strings is a common programming construct that most code parsers provide options for.
COMMAND.COM's batch script parser will interpret two %% signs in a row as a single % character of type string.
In other words, %1xx0xxxx denotes variable which has not been defined in the first place, while %%1xx0xxxx will be interpreted as the string "%1xx0xxxx".
As a result, the CTCHIP32 command will be invoked with the expected argument.

Wolf3D can fit within ~300Kb conventional memory.
F-15 Strike Eagle III and Formula 1 Grand Prix II are the only games i encountered so far that complained about not enough conventional memory due to MSDOS.SYS being loaded there entirely.

LGHT486 hangs the system during DOS boot if loaded before HIMEM.SYS /TESTMEM:ON.
REVTO486 causes HIMEM.SYS /TESTMEM:ON to throw an error about corrupted address.
Loading them after HIMEM.SYS works fine.

Thanks. Yes I saw your previous post, but wasn't sure how you arrived at the idea to double the % character. Your latest explanation is more telling. I am surprised that CTCHIP would use this special character for command line instruction, given that people would be using CTCHIP commands in autoexec.bat.

I guess I have a lot more programs or drivers consuming my conventional memory than you do because I find it a constant struggle on my various systems to get Wolf3D running. To run this game in the past, I've been having to find items to REM in my configuration files. I think it is mostly my Windows 95 and newer systems, which aren't as much of an interest for wolf3D. If I recall right, even though I had over 500 KB free of conventional memory free, Wolf3d wouldn't run. I had to get it up to 570 KB or so free to run wolf3d. I haven't looked into it much because I was just wanting to get a quick benchmark.

At least on the SiS Rabbit motherboard so for, I haven't had any issues running LGHT486.sys or REVTO486.sys prior to himem, provided I do not run the memory test. I am surprised that you are unable to run LGHT486 before himem. Curiously, I think when I used the actual Evergreen Revto486 upgrade interposer, I was able to test memory in himem if REVTO486 was loaded first, however I'd have to double check this to ensure my recall is correct.

Nonetheless, with the noted CTCHIP fix, both BL3 drivers provide the same performance. I haven't checked to see how much space savings there is with the LGHT486 vs. REVTO486 driver.

Just checked online that Wolf3D requires 528Kb RAM.
So i stand corrected.

I only tested LGHT486 and REVTO486 on a Symphony board.
Pretty sure it is the same for Um82C491F based boards, since recently one was on the test bench.
Will confirm with Opti 495SX and 495SLC tomorrow.
If HIMEM's memory test is disabled then things work on all boards that light up with BL3 processors for sure.

I tend to recall the same for IO-DATA adapters. Don't think i experience any driver related issues.

I thought 300K for Wolf3D sounded very low. Be careful when trusting your own memory. When I was a kid, I had a knack for remembering numbers when placed with an idea, but this magic ability I once had has long since vanished, but my mind keeps thinking I still have it.

I ran a bit more analysis. Results are weird.

You can also load REVTO486.SYS or LGHT486.sys after HIMEM, but for applications in DOS/WIN311 to run properly, adhere to:
if DOS=UMB in config.sys
You can load either driver before HIMEM or after HIMEM.
On my test system, free conventional memory = 506K w/LGHT486 and 505K w/REVTO486.

if DOS=HIGH,UMB in config.sys
You can only load either driver before HIMEM.
On my test system, free conventional memory = 477K for both drivers.

If you try to load the drivers after HIMEM, REVTO486 hangs during SCSI driver loading, while LGHT486 completes loading w/566K free, however DOOM was running abnormally slow. I analysed this a little further and discovered that LGHT486 is setting all the RAM not cacheable via 1001h:4, that is, setting this to 00000000. I think the driver is a little smarter and is able to detect conflicts, which is why it disabled caching of RAM. You can manually re-enable it at the command line with CTCHIP34 IBM486 1001h:4:=%11110000. This will let you run DOOM, but if you try to load Windows or even do CHKCPU, the system will crash.

So it does appear that using DOS=UMB is universally more ideal, however for my test system, free conventional memory is too low for WOLF3D.

In some cases, LGHT486 may save 1 KB, while in others it did not. I suspect the significant digits being truncated is affecting this. Is there a way to run mem with more significant digits?

Thinking about things a little further, I think I know why the Kingston driver installer is trying to help the user with installation. The installer is probably trying to determine:

Cache Region Control Register Byte 3, 1001h:3
which cache blocks in the first 1024K are read-only, meaning contain ROM data so that writes to this range are not updated in cache. Evergreen just puts this register at all 0's, so 00000000 but I noticed the Kingston driver tries to enable some bits here, as does my Daewoo BIOS. If this register contains 10000000, as is the case w/Daewoo, this would indicate that the last 64K at segment F000h is ROM and writes to this range are not to be updated in cache. Kingston has this value as 0001000.

Cache Region Control Register Bytes 1 & 0
This determines which of the first 1024K memory is set to cacheable, where each bit is a 64K block of memory.

Evergreen does what I'd expect and sets the first 640 KB as cacheable, and the rest non-cacheable, e.g. Bytes 1&0: 00000011_11111111

Daewoo does something different based on, I think, what is setup in the BIOS: 10000011_11111111. So first 640K is cacheable AND the very last 64K block within the first 1024K is set cacheable.

Kingston's default is: 00010011_11111111. Again, first 640K cacheable AND a 64K block starting at the 768K boundary set to cacheable. Is the Kingston driver able to auto-detect which upper memory blocks aren't be used by expansion ROMs?

Note that the cacheable range of the BL3 isn't really 16 Megabytes, it is 1 MB + 15.9375 MB, or 16.9375 Megabytes. If you want the extra 960K, you can set 1001h:4 to 11111111 instead of 11110000.

Is DOS 6.22 and later able to actively determine which upper memory blocks are free to use by software if HIMEM is loaded, or is EMM386 still required?

If I load EMM386, I am not able to use CTCHIP to adjust the registers. This is why I try to avoid EMM386 - I always run into something requiring more research, then walk away. I guess CTCHIP would need to be loaded in config.sys using DDL or something similar if you wanted to use EMM386.

I decided to mull over this a little more. Some important observations when using DOS=UMB were,

a) issues with soft-reset.
b) hang when loading speedsys with garbled image
c) cannot display DOOM result after benchmark
d) hang at DOS prompt when exiting Windows 3.11

The issues disappear with DOS=HIGH,UMB.

I can see why the Daewoo board is setting the last 64K block of upper memory as ROM in 1001h:3 since this is the shadow of the system BIOS. Why why don't the Evergreen and Kingston drivers also set this? Curiously, Kingston sets a block as ROM correctly, which is my VGA+SCSI ROM, but Evergreen does not. If we break down the upper memory region as,

640K - 704K = A0000 - AFFFF (sometimes VGA shadow goes here)
704K - 768K = B0000 - BFFFF
768K - 832K = C0000 - CFFFF = VGA BIOS starting at C0000 and SCSI BIOS starting at C8000
832K - 896K = D0000 - DFFFF
896K - 960K = E0000 - EFFFF
960K - 1024K - F0000 - FFFFF = SYSTEM BIOS SHADOW

So if we wanted to identify these as ROMs, then a write to these regions will not be updated in cache. Theoretically, should be more efficient, but why would there ever be writes to these regions if they are reserved to begin with? Anyway, so we would set the Cache Region Control Register Byte 3 (the Hi-byte), 1001h:3 as, 100100xx

Similarly, if we want to have these shadowed regions read cacheable, we'd identify them in Cache Region Control Register Byte 1 (hi-byte0, 1001h:1 as 100100xx

Kingston does identify as default in their driver the loction of the VGA/SCSI BIOS ROM, but not the system ROM.. Curious. Conversely, my Daewoo board, which is BL3 aware, only identifies the system ROM here, not the hard drive controller. Nonetheless, these are the options I have ended up with after loading either the Kingston or Evergreen drivers:

1CTCHIP34 IBM486 /1000h:0:=%%x1xxxx1x
2CTCHIP34 IBM486 /1000h:1:=%%1xx0xxxx
3CTCHIP34 IBM486 /1004h:3:=%%xxx1xxxx
4CTCHIP34 IBM486 /1001h:3:=%%100100xx
5CTCHIP34 IBM486 /1001h:1:=%%100100xx

If you don't know the location of your HDD controller's ROM, remove the middle 1 and put a 0 on the last two.

For best compatibility and least problems on my SiS Rabbit board, it is best to have DOS=HIGH,UMB and loading driver before HIMEM. But there is more to this mystery still.

If I press F5 at boot to bypass all my config files, I have 578K conventional memory free.

If I load all but the Blue Lightning drivers, I have 567K conventional memory free. Meaning, my drivers only taking 11 KB.

If I load with Blue Lightning drivers, I have 477K conventional memory free. Meaning the driver is taking an additional 90 KB. How is this possible, I thought all the driver was doing was to set CPU registers?

Loading a BL3 driver before HIMEM.SYS forces MSDOS.SYS to reside in the conventional memory entirely.
That's why you see less conventional memory in this configuration.
What exactly causes this behavior is unclear to me at this point.

Listed issues:
a) issues with soft-reset.
b) hang when loading speedsys with garbled image
c) cannot display DOOM result after benchmark
d) hang at DOS prompt when exiting Windows 3.11

The situation here:
a) No soft-reset issues on any of the tested motherboards.
b) I have seen that on some mobos. The simple cure ? Run Win3.11 then go back to DOS. SpeedSys works. Surprise surprise. No idea why.
c) I think i got this with RevTo486 at some point, but not the case anymore. Cannot replicate it at least.
d) Haven't seen that so far.

Are you sure the BL3 chip is stable-stable (on air cooling) ?

All those issues completely vanish when I run DOS=HIGH,UMB and load either REVTO486 or LGHT486 before HIMEM. I'm pretty sure the Evergreen documentation also recommended this sequence, but I'd have to double check my memory.

I've not had any issues with the chip at 3.6 V and 100 Mhz with a heatsink/fan when following DOS=HIGH,UMB and loading driver before HIMEM. Keep in mind that we use different hardware. I'm using a SiS Rabbit with SCSI.

The desire to do DOS=UMB and loading driver after HIMEM is of little value because the amount of free conventional memory is still less than what is needed to run Wolf3D.

I ran a few tests with my Daewoo board which doesn't need a driver for the BL3.

With DOS=HIGH,UMB and numerous DOS drivers loaded, like Promise, mouse, sound, zip, CD-ROM, etc I have 478 KB free conventional memory.

With DOS=UMB and numerous DOS drivers loaded, like Promise, mouse, sound, zip, CD-ROM, etc I have 418 KB free conventional memory.

With DOS=HIGH,UMB and only my mouse driver installed, I have 582 KB free conventional memory.

A user in another thread located this application hint from Micrel concerning the IBM Blue Lightning voltages.
It mentions that either 3.3 V or 3.6 V was nominal for the IBM BL3, with "some versions operate at 3.3 V, while higher performance devices require 3.6V, 3.8V, and even 4.1V. With internal clock tripling circuitry, they dissipate up to a maximum of 3.6W, drawing about 1A.

This helps to explain why we are witnessing such a wide variation for this CPU on commercial upgrade adapters, that is, from 3.5V - 4.1V. It looks like IBM us up to the same tricks as Cyrix was to increase yields. The document mentions 1 A as a worst case, but Micrel selects a 1.5 A regulator for this design, MIC29152BU. Unfortunately, I couldn't locate a 1.5 A regulator with ultra-low dropout (300 mV or less) in a SOT-223 package. I am using TPS72501DCQR, which is 1 A, and it seems to be holding up OK and not overheating.

Someone asked if I could provide a bit more detail on the assembly of this unit. The next 6 posts will contain this additional information for a second unit I assembled recently.

Finding IBM Blue Lightning BL2/BL3 CPUs which run at 100 MHz can be difficult. Of the six BL3 chips I've encountered, they all have been able to perform at 75 MHz, but only two are fully stable at 100 MHz or more. To locate the BL3 chips, you normally need to salvage them from Buffalo or IODATA upgrade interposers, which were intended for the Japanese PC-98 market. Today, these adaptors are selling in the $300 range, which makes replicating my hack job more costly. Fortunately, I bought mine some years ago in the $50-75 range.

A few months ago, there were some of these IBM BL3 chips on eBay, NOS, for about $40 each. The seller had 5 - I bought 2. They had 50G3589 listed on the top of the IC. I don't know the significance of this number, but my Evergreen BL3 adaptor has 50G3588. These NOS CPUs from ebay weren't able to handle 100 MHz. I got 75 MHz out of one and 80 Mhz out of another, with the later being almost stable at 3x30 MHz. This was at 3.8 V though and I did not push higher. I tested them on the IODATA interposer. I have since taken the BL3 CPU from the Buffalo and IODATA interposers and are using them on my BL3 hacks. Similarly, I have placed the eBAY BL3 chips onto the Buffalo and IODATA interposers.

I originally only had 4 100 nF decoupling caps on the BL3 hack, but ultimately decided upon 10. I measured the noise in the 5 KHz range with the 10 caps, which is shown below: