Did more testing with P4Tool, this time benchmarking the low end of performance with cache disabled.

First chart is using the 17x multiplier for the Pentium 4, second chart is with 12x multiplier. JEMM386 and HIMEMX was used for these benchmarks. For comparison, I included benchmarks from my 486 DX-33 and 386 DX-40 systems.

With just cache disabled, it performs like a mid-range 486. At the lowest level of performance with 12x multiplier, DS+BTS option, and cache fully disabled, the Pentium 4 is about the level of a 386 DX-40.

With cache disabled combined with the multiplier and DS/DS+BTS throttling options, the Cedar Mill P4 nicely covers a range of speeds from fast 386 to low/mid-range 486.

Benchmarks with 3D Bench and PC Player benchmarks testing throttling methods and combinations. These were undertaken with JEMM386 and HIMEMX enabled.

System reference scores for 3D Bench were taken from Phil's 136-in-1 Pentium MMX project. Reference scores for PC Player bench were taken from some of Phil's benchmark references and my own benchmarking.

I do find it interesting that the 3D Bench scores are comparatively lower than PC Player benchmark scores. The 3D Bench scores indicates performance going down to 386 levels, whereas PC Player bench stops at the lower-end of 486 performance. I imagine in practice it will come down to trial-and-error to hit specific performance levels in different games.

Of course the Pentium 4 can go even lower using ACPI and/or ODCM throttling.

The p3 era had a prochot signal (processor hot) that allowed the system monitor chip to tell the chipset to sleep the processor up to 75%.

If you're decent at coding, look up whether the p4 retained it, and the sysmon datasheets.

myne wrote on 2026-04-08, 02:36:

The p3 era had a prochot signal (processor hot) that allowed the system monitor chip to tell the chipset to sleep the processor up to 75%.

If you're decent at coding, look up whether the p4 retained it, and the sysmon datasheets.

I did some research into this. From what I can gather, when prochot signal is triggered, it introduced halt states based on a frequency cycle (PWM). It sounds like it's doing the same thing that ODCM and ACPI throttling methods do.

So I suspect that functionality is already available through tools like CPUSPD which include those throttling options.

Probably. I doubt they left many stones unturned, but you could potentially check with something like wpcredit. I assume the sysmon will be present there.

Hey, would you recommend buying this IMB200 motherboard for a multiboot retropc, say over an AIMB865 ver. xxx.2? I am very intrigued by these industrial motherboards that support ISA cards. Thanks

Mao wrote on 2026-05-02, 08:19:

Hey, would you recommend buying this IMB200 motherboard for a multiboot retropc, say over an AIMB865 ver. xxx.2? I am very intrigued by these industrial motherboards that support ISA cards. Thanks

I've only used the IMB200 motherboard. Based on my testing, it works well with ISA sound cards in DOS, if that's what you are looking for.

Since I've never owned or used an AIMB865, I can't say how the two motherboards would compare.

Hey, thanks for your reply. I just ordered an IMB200 from eBay, but in the end I have decided to get both motherboards and build two systems around them. Yes, what I mean is to have many oss on them, from DOS with ISA historic and modern sound cards up to XP. I will eagerly read *all* your threads!

Mao wrote on 2026-05-03, 07:35:

Hey, thanks for your reply. I just ordered an IMB200 from eBay, but in the end I have decided to get both motherboards and build two systems around them. Yes, what I mean is to have many oss on them, from DOS with ISA historic and modern sound cards up to XP. I will eagerly read *all* your threads!

Good luck! I'll be interested to see the results of your builds.

Like to share a little problem/solution that I had on my ITOX. It's with GUS digital not working (MK1869 Xtreme for me). I'm not sure if it's unique to my MB or all ITOX.

Disabling LAN/PXE Boot ROM (while keeping other settings active)

1. Go to Onboard Device → Set LAN (and LAN 2 if present) to [Enabled]

2. Go to Advanced BIOS Features → Set First Boot Device to [LAN]

3. In Advanced BIOS Features, set Boot Other Device to [Enabled]

4. Go to Integrated Peripherals → Set Onboard LAN Boot ROM to [Enabled]

5. Save & reboot.

6. During early boot (when basic POST info appears), press Shift + F10
to enter the Realtek LAN Boot Agent Configuration Menu.

7. In the LAN Boot GUI:
- Set Boot Order to [ROM Disable]
- Set Show Config Message to 1 Second
- Press F4 to save and exit.

8. Return to BIOS → Go back to Advanced BIOS Features → Change
First Boot Device back to [Floppy] (or your preferred boot device).
Save and reboot.

Current situation on my system:
I need to leave most of these settings active. For some reason, if I disable
[Boot Other Device] or [Onboard LAN Boot ROM], the system reverts to its
original legacy state and I lose digital sound on my Gravis UltraSound (GUS).

It's not a big deal though — the only downside is that you'll briefly see the
Realtek RTL8110SC Gigabit Boot Agent message for about 1 second during boot.
I'll happily take that small hit to keep GUS digital sound working properly.

Reason for this workaround:

When the LAN/ROM is loaded into memory, it causes all sorts of funky issues.
On my system, for example, I cannot load EMM386 + HIMEM functions when the
PXE ROM is active. This was actually the clue that led me to the fix.

The Realtek option ROM installs itself as a resident handler. It hooks
interrupts (e.g. INT 13h for the boot device chain or INT 19h) and may
probe hardware resources to prepare for network boot.

If LAN boot/PXE is enabled in BIOS (or the NIC has its boot ROM/PXE option
ROM active), the card’s option ROM loads early in POST. It can temporarily
“probe” or reserve DMA resources — which causes the GUS initialization
(IWINIT or UNISOUND) to misconfigure or fail silently on DMA.

Many NIC option ROMs perform legacy resource probes during init. They
temporarily test or claim DMA channels (e.g. DMA 1–3 or 5–7), IRQs
(often 9–12), or I/O ports (e.g. 300h–380h range).

Even if they don’t fully claim the resources permanently, the probe can:
- Leave the DMA controller in a weird state
- Temporarily mask or alter IRQ lines
- Shadow/occupy memory regions that DOS programs expect to be free