Mike1978 wrote on 2026-08-09, 20:00:

The blue lightning has 16kb l1 cache as I recall and up to 3x clock multiplier. […]
Show full quote

Disruptor wrote on 2026-08-09, 19:26:

Unfortuneately the Intel Inboard 386/PC does not contain any cache where the the Intel Inboard 386/AT does have 64 kB of cache. […]
Show full quote

red-ray wrote on 2026-08-09, 16:49:

Thank you, I half guessed this could be the situation. Does the Intel Inboard 386/pc have a motherboard cache?

Unfortuneately the Intel Inboard 386/PC does not contain any cache where the the Intel Inboard 386/AT does have 64 kB of cache.
Perhaps it has something to do with the DMA problem. PC and PC/XT use an 8 bit MFM controller which uses DMA on every data transfer. In the AT access through PIO is faster.

Mike, do you face any DMA problems with the BL?
Perhaps the solution flushes the BL's cache on every DMA access to overcome this problem.

The blue lightning has 16kb l1 cache as I recall and up to 3x clock multiplier.

The original 16mhz Intel 386 would have had none

I had been controlling some of the multiplier via software with revto486.sys to increase the multiplier to 2x and that did also do things with the CPU registers

I have a screenshot but not from the win95 boot this is dos / 3.11 where it works seemlessly

So far getting the revto486 to boot on 95 has proven difficult. One to revisit.

The attachment IMG_0766.jpeg is no longer available

I got the equivalent of running revto486.sys but using ctchip34.exe and set a number of registers at boot via autoexec.bat I’ve got the CPU speed back at 2x as wanted and the L1 cache enabled.

Thank you for trying, given msvcrt is missing I suspect you need to install vcredist_60_x86.exe, see Re: SIV support for 386/486/586 class CPUs and 3Dfx + Matrox GPUs. It would also be a good idea to install the Tahoma Font+DLLs.

Mike1978 wrote on 2026-08-27, 17:03:

Gave this a go and got a missing msvcrt error is this a known requirement on Win 95 ? I’m recalling this from memory as it was very late when I tried it.

As for updates on what else is now working.

I had to patch the Creative Labs Soundblaster Pro driver and now my SB pro 2 ct1600 is now fully working.

Network is working 3c509b standard driver worked immediately and just needed to be hand configured

ATI Mach 8 Ultra driver from Windows 95 unmodified worked fully also though I had to configure it manually once done it took and worked so all good runs at 1024x768x256

I identified an issue with the FDD drives I have an extended bios and 1.44 support via a Sergey Kisalev floppy controller with serial. Initial thoughts are it’s trying to load via bios but not there and real mode of course. Adding the windows Floppy driver Adapter in device manager got it further actually attempts to show the content of the drive but fails part way through. The second 1.2mb 5.25 geometry also misidentifies as 1.44 3.5 so some work there patching the windows driver wasn’t being read so may need to do some work on the DMA similar to the SB Pro driver.

It does work in DOS and previously in Windows 3.11 so it should be possible to find a solution.

Likewise all drives currently loading in real mode so would be good to try and fix, adding in device manager defaults to IRQ14 on a standard IDE / ESDI controller so again likely need to patch the driver

Progress though with video, sound and network all working and getting the CPU cache working and Speed clocked appropriately.

Never will be speedy but it’s working

All details on my git, I’ve also been patching and fixing up the emulation in 86 box as well, it is now in the main 86 box branch.. There’s potentially still a few issues but it’s been invaluable for development and test.

red-ray wrote on 2026-08-27, 17:12:

Thank you for trying, given msvcrt is missing I suspect you need to install vcredist_60_x86.exe, see Re: SIV support for 386/486/586 class CPUs and 3Dfx + Matrox GPUs. It would also be a good idea to install the Tahoma Font+DLLs.

Mike1978 wrote on 2026-08-27, 17:03:

Gave this a go and got a missing msvcrt error is this a known requirement on Win 95 ? I’m recalling this from memory as it was very late when I tried it.

Thanks I think I actually have that on disk I think to deploy. Will try once more after I confirm.

red-ray wrote on 2026-08-27, 17:12:

Thank you for trying, given msvcrt is missing I suspect you need to install vcredist_60_x86.exe, see Re: SIV support for 386/486/586 class CPUs and 3Dfx + Matrox GPUs. It would also be a good idea to install the Tahoma Font+DLLs.

Mike1978 wrote on 2026-08-27, 17:03:

Gave this a go and got a missing msvcrt error is this a known requirement on Win 95 ? I’m recalling this from memory as it was very late when I tried it.

Hi Ray

Ok update for you, the distribution fixed the error but the fonts reported as not being valid and failed to load.

I’ve got it to load it took minutes. Currently saving the information.

Minor misreporting on ram but unsurprisingly saying 8mb I have 5mb but seems to be the same in a few apps I tried re the ram.

Saving to local as I speak and it’s going to take some time to complete. The disk is slow and real mode atm hopefully one I can address but the bus speed will always be tricky and likely so will disk.

I’ll share the file when complete

Mike

Mike1978 wrote on 2026-08-27, 17:03:

Hi again, […]
Show full quote

red-ray wrote on 2026-08-09, 16:49:

Mike1978 wrote on 2026-08-07, 17:23:

I can explain it the base card is an Intel Inboard 386/pc but I have running in the card a CPU interposer I-O Data PK-A486BL 386/486 Blue Lightning Processor Upgrade CPU BL3 60MHz 486DLC.

Thank you, I half guessed this could be the situation. Does the Intel Inboard 386/pc have a motherboard cache?

Some time ago I updated SIV to detect and report the 486DLC L1 cache size so I would be good if you tried SIV32L.exe and posted the screen shot and Menu->File->Save Local file so I can see how the new code does.

Hi again,

Gave this a go and got a missing msvcrt error is this a known requirement on Win 95 ? I’m recalling this from memory as it was very late when I tried it.

I’ll give it another spin after a few more installs as it maybe packaged up with the likes of MS Internet explorer 5.5 sp2 etc.. it is OSR1 and will in the future be giving osr2 another attempt.

Mike

I had to kill it it was making the box unresponsive but here's the partial file output

Edit - it got further than I thought. It looked dead so I pulled it, but the CPU sections did complete, so there is usable data in there after all.

On the 486DLC L1 cache detection you asked me to try, the new code reports:

L1 Unified Cache 4-way 16-byte 8KB
L2 Unified Cache Unknown

The Blue Lightning BL3 has 16KB, so it is reading half. My guess is it is falling back to the generic i486 default rather than probing, because CPUID is not available on this chip - [_]CPUID is clear in the [cpuid] section - but you will know far better than me whether the new detection path needs CPUID to run at all.

The clock is the part I would most like your view on:

CPU-0 Generic 486 DX2 STK 65.131MHz CPU 65.131MHz FSB 32.565MHz
CPU-0 65.1MHz x2 32.6MHz

The x2 is correct and genuinely useful to see confirmed - that is the clock multiplier I set with CTCHIP34, so it is holding. But the base reads 32.6MHz and I have a 40MHz crystal fitted, swapped up from the original 32MHz. CheckCPU and CheckIt both measure around 83.5MHz from DOS, which fits 40 x 2. SIV under Windows makes it 65, which fits the old 32MHz crystal.

So either the clock is not holding under Windows, which would be well worth me chasing as there is real performance in it, or the timing loop is struggling on this hardware. With no TSC on this chip I assume it is PIT calibrated, and this machine is awkward - the Inboard has its own local bus and speed register while the ISA side stays at 4.77MHz. How much would you trust that figure here?

Two other things you may want, since SIV is not going to meet this hardware often:

- RAM reads 8.00MB against 5MB actual, and it reports "Chips 1 SIMMs 4" plus two 4MB SPD entries. There are no SIMM sockets on this machine at all - it is 1MB on the Inboard plus a 4MB piggyback.
- Every section took 7 to 14 seconds, a couple over 20 ([features] was 21s), which is what made it look hung rather than slow. I assume that is SMBus/ACPI/PnP probing timing out against a 1983 machine.

The BIOS line came out exactly right, for what it is worth: "Unknown Motherboard BIOS C1.10 Copyright IBM Corp 1981 05/09/86" - that is the correct 09MAY86 5160 ROM.

Mike

Second edit - correcting myself on the cache, having gone through the file properly.

The 8KB is not a failed probe, it looks like it never probed at all. "486DLC" does not appear anywhere in the file, SIV classifies the chip as "Generic" throughout, and there is a line reading "CPU Tweak is Not Supported for the Generic 486 DX2 65MHz CPU". The 8KB 4-way 16-byte figure is just the stock Intel 486DX descriptor, so it would print the same whether the cache is enabled or not.

More usefully, and this is what I missed first time round - the very last line of the file is the latency section header with nothing under it. That is exactly where I killed it. So the cache latency test, the one thing that would have measured rather than classified, never ran.

What sits immediately before it explains why the machine looked dead. It was not hung at all, it was benchmarking:

benchmark-dd Integer 2, Float 2 - 106.44 seconds
benchmark-dw Integer 1, Float 2 - about 87 seconds
latency - killed here

So I pulled it roughly two minutes too early, right as the cache test was starting. That one is on me, not on SIV.

Happy to run it again and leave it completely alone this time if the latency numbers would be useful to you. Just say and I will let it run to completion however long it takes, and post the full file.

Mike1978 wrote on 2026-08-27, 22:34:

More usefully, and this is what I missed first time round - the very last line of the file is the latency section header with nothing under it. That is exactly where I killed it. So the cache latency test, the one thing that would have measured rather than classified, never ran.

That is what I have noted on some of my older machines too.
First I thought it was due to the low RAM, but my 16 or 32 MB should be fine for that checks.

Mike1978 wrote on 2026-08-27, 22:34:

I had to kill it it was making the box unresponsive but here's the partial file output […]
Show full quote

I had to kill it it was making the box unresponsive but here's the partial file output

The Blue Lightning BL3 has 16KB, so it is reading half. My guess is it is falling back to the generic i486 default rather than probing, because CPUID is not available on this chip - [_]CPUID is clear in the [cpuid] section - but you will know far better than me whether the new detection path needs CPUID to run at all.

The x2 is correct and genuinely useful to see confirmed - that is the clock multiplier I set with CTCHIP34, so it is holding. But the base reads 32.6MHz and I have a 40MHz crystal fitted, swapped up from the original 32MHz. CheckCPU and CheckIt both measure around 83.5MHz from DOS, which fits 40 x 2. SIV under Windows makes it 65, which fits the old 32MHz crystal.

- RAM reads reported as 8.00MB against 5MB actual, and it reports "Chips 1 SIMMs 4" plus two 4MB SPD entries. There are no SIMM sockets on this machine at all - it is 1MB on the Inboard plus a 4MB piggyback.
- Every section took 7 to 14 seconds, a couple over 20 ([features] was 21s), which is what made it look hung rather than slow. I assume that is SMBus/ACPI/PnP probing timing out against a 1983 machine.

Thank you, as I suspected SIV needs some adjustment. The memory being reported as 8MB was easy to fix, SIV32L V5.88 Beta-09 should fix this, does it please?

I suspect with more memory SIV would be less slow, how much memory can the system support?

SIV should have reported IBM 486BLX2 and I can't see why it didn't, please do SIV32L -DBGCPU -EXIT=20 > SIV_DBGOUT.log and post the .log file.

The AAM is used to measure the CPU speed and for IBM Blue Lightning it takes 17 rather than 15 cycles, allowing for this 65.1 * 17 / 15 = 73.78 which is still low, please post a screen shot of Menu->Help->Conversions->CPU MHz so I can see what get's reported.

I expected SIV to report 16KB as the L1 cache size and I can't see why it didn't, I would like to see what [latency] reports, but it's not there.

Please try the save again, ideally start the save then just let it run. If there is an issue with a section do Menu->File->Save->Save Selected and deselect that section before pressing [ Start ].

red-ray wrote on 2026-08-28, 08:19:

I suspect with more memory SIV would be less slow, how much memory can the system support?

It is already maxed at 5 MB. 1 MB onboard + 2 expansion boards each 2 MB.

The system is maxed at 5mb currently, I’m working on a few speed improvements. I hadn’t realised I was on an XT and not XT+ build of xub for my xtide that opens up a few minor improvements.

I’m also attempting to make an xtide Windows 9x driver but it’s taking time to get things recognised but once out of real mode it may help.

It’s never going to be fast but hopefully each tweak gets me closer to it being more usable.

Will revisit as I can and run the above once more

Mike

Perhaps you can provide some source code too.
Unfortuneately we do not have an Inboard XT here too but it would be interesting if there is a possibility to add support for a ST01 SCSI controller too.
My pal mkarcher is using an ST01 with a 1 GB HDD in his turbo XT. That ST01 is using ISA DMA transfer too. However, his support is limited to the controller's SCSI BIOS. No ASPI driver, nothing else.

Mike, I'm not sure what will more help.
Your driver will both get you
- out of real mode
- allow CPU to do other tasks using internal cache while DMA transfers are pending.

Worth noting I have been building and testing a lot of my work in emulation I’ve since added the inboard in an XT to 86 Box ported from unipcemu and a few fixes along the way.

I have finished my xtide driver now, so out of real mode and I found a Trantor / Adaptec driver for my Trantor t130b SCSI that runs under 9x but was never bundled by Microsoft. Looking online the ST01 never had a Windows driver but it was written for Linux so it might be possible to port it across using the a Linux source as a template.

Xtide driver is here https://github.com/Mike1978uk/win95-intel-inb … ivers/xtide_mpd

There might be a bit more to do with it but it’s working fine now for my lotech card.

I will return to the SIV test when I can.

As for providing source code I’m not against it at all.

Will follow up of course.

I’m burning tokens like crazy with Claude and I’ve my LS120 driver to finish the existing Windows Protected mode driver breaks my keyboard through some calls that are unnecessary so I’m fixing that based on the DOS sys real mode driver that works flawlessly that’s the last of my real mode drivers to fix. I have everything then though a few tweaks here and there could add a tiny bit of performance which is worth the investigation.

I’ve added an issue in GitHub to reply more generally to both the ST01 and maybe a guide on how to but remember I’m using Claude to aid me in development and secondly to close the loop on the SIV ask.

At the minute disk activity is slow it feels measurably slower than Win 3.11 but then I’m pushing the system much harder and I’ve the XT bus to work with. There’s possibly a cap on performance but it’s likely my next focus to eek out as much as I can.

Since the lotech card is really just an 8bit IDE with waitstate driven sequential latching of Hi and Low byte of a 16bit IDE, (Basically a multiplexer), I assume that this miniport driver aims to support this, so windows does not complain about using the 'msdos compatibility' int13 mode?

One does not explicitly need a fancy bit of unobtanium to test this driver.

A 486 with isa slots, no onboard IDE, and a lotech card should suffice?

wierd_w wrote on Yesterday, 17:33:

Since the lotech card is really just an 8bit IDE with waitstate driven sequential latching of Hi and Low byte of a 16bit IDE, (Basically a multiplexer), I assume that this miniport driver aims to support this, so windows does not complain about using the 'msdos compatibility' int13 mode?

One does not explicitly need a fancy bit of unobtanium to test this driver.

A 486 with isa slots, no onboard IDE, and a lotech card should suffice?

Exactly that just gets you out of real mode no inboard or XT required it’s more general and I think that possibly is a nice to have outside of my project that it’s generally available. I did post to a few forums about it so far and asked it’s hosted here by the xub maintainers for wider availability.

I’ve yet to hear back

https://www.xtideuniversalbios.org/

Minor correction to be clear there is a hi-speed mode on some Xtide cards that might be rejected by the driver. So do make sure you back up any CF you use first. As always with new code there’s some risk.

I am intending to revisit the hi speed mode support as it’s just a table in the driver and it may have a minor boost through grouping CPU instructions. That’s on my list

It should support both stride 1 (older cards) and stride 2 card natively though.

Do feedback and you can leave issues on my git,, likewise positive it works on this type of card feedback is also useful to share.. only in that I have limited cards to try and the xtide emulation in 86 box does work with the driver also.

Mike1978 wrote on Yesterday, 18:03:

Exactly that just gets you out of real mode no inboard or XT required it’s more general and I think that possibly is a nice to h […]
Show full quote

wierd_w wrote on Yesterday, 17:33:

Since the lotech card is really just an 8bit IDE with waitstate driven sequential latching of Hi and Low byte of a 16bit IDE, (Basically a multiplexer), I assume that this miniport driver aims to support this, so windows does not complain about using the 'msdos compatibility' int13 mode?

One does not explicitly need a fancy bit of unobtanium to test this driver.

A 486 with isa slots, no onboard IDE, and a lotech card should suffice?

Exactly that just gets you out of real mode no inboard or XT required it’s more general and I think that possibly is a nice to have outside of my project that it’s generally available. I did post to a few forums about it so far and asked it’s hosted here by the xub maintainers for wider availability.

I’ve yet to hear back

https://www.xtideuniversalbios.org/

Minor correction to be clear there is a hi-speed mode on some Xtide cards that might be rejected by the driver. So do make sure you back up any CF you use first. As always with new code there’s some risk.

I am intending to revisit the hi speed mode support as it’s just a table in the driver and it may have a minor boost through grouping CPU instructions. That’s on my list

It should support both stride 1 (older cards) and stride 2 card natively though.

Do feedback and you can leave issues on my git,, likewise positive it works on this type of card feedback is also useful to share.. only in that I have limited cards to try and the xtide emulation in 86 box does work with the driver also.

486 with odd edge cases (like DX50) would be great hardware to stress this driver on.

I dont own any, sadly, but the oddball bus freq of such machines would be great to validate against.

Disruptor wrote on 2026-08-28, 15:24:

red-ray wrote on 2026-08-28, 08:19:

I suspect with more memory SIV would be less slow, how much memory can the system support?

It is already maxed at 5 MB. 1 MB onboard + 2 expansion boards each 2 MB.

Latest output for you Ray from your beta

Hope it captured what you were after - the ram seemed correct this time around and a photo to go along with it.

Mike1978 wrote on Today, 13:21:

Hope it captured what you were after - the ram seemed correct this time around and a photo to go along with it.

Thank you, I will check the save file shortly, but I can see there is an issue with the CPU detection, please do as below.

red-ray wrote on 2026-08-28, 08:19:

SIV should have reported IBM 486BLX2 and I can't see why it didn't, please do SIV32L -DBGCPU -EXIT=20 > SIV_DBGOUT.log and post the .log file.

red-ray wrote on 2026-08-27, 17:12:

It would also be a good idea to install the Tahoma Font, see Re: SIV support for 386/486/586 class CPUs and 3Dfx + Matrox GPUs.

I noticed you did SIV32L -save -noacpi -nopci -nosmb, why did you do this rather than run SIV32L then do Menu->File->Save Local as I specified?

BTW do you have a MCA (Microchannel) system running Windows 9x/NT please?