Hello,

On the GA-P43-ES3G motherboard (LGA775 socket, P43 Northbridge in DDR2, ICH10 Southbridge), there are probably no third-party drivers for components not originally recognised by Windows 98 SE. The HCDP (i.e. LBA48), SATA and AHCI patches by Rudolph Loew are the exception, and allow the 6 SATA ports to be used.

Here are the components for which Windows 98 SE either cannot install a driver or cannot resolve a resource conflict:

• IDE controller JMicron JMB368 : VEN_197B DEV_2368
• Gigabit Ethernet controller Realtek RTL8111C : VEN_10EC DEV_8168
• USB 2.0 controller Intel ICH10 EHCI : VEN_8086 DEV_3A3A

The USB 1.1 controller Intel ICH10 UHCI is supported correctly : VEN_8086 DEV_3A34 to 3A39

At the moment, my concern is with the JMicron IDE controller. My boot disk is a CompactFlash volume, connected via a simple mechanical adapter to this JMB368 IDE controller. Windows starts up in Virtual Mode I/O (BIOS int 13h), and then ‘something’ prevents it from switching to its 32-bit ESDI_506.PDR driver to access the CompactFlash. Once the desktop is displayed, all access to the C: volume continues to be done in 16-bit MS-DOS compatible mode. That's a bummer.

According to msinfo32, error code 29 prevents Windows from using the JMB368 VEN_197B DEV_2368. The issues raised by JMB368 are not new to our forum. Curiously, the name JMicron's controller bears here is ‘Standard Dual PCI Sata Controller’. msinfo32 also reports that an ACPI\*PNP0C02 component is unusable due to a resource conflict (error code 15). No further details are provided. Based on these observations, Gemini proposes the following theory:

The link with the ACPI conflict: It is very common for the BIOS to attempt to ‘hide’ the JMicron controller behind an ACPI layer so that it appears to be a standard (Legacy) IDE port. The *PNP0C02 (Code 15) conflict is probably due to the JMicron chip attempting to appropriate interrupts IRQ 14 or 15 (the classic IDE ports) when the Intel ICH10 chipset has already ‘ghost’ reserved them for its own SATA channels.

But it doesn't stop there; it also offers me the following workaround, in the form of an INF file:

Why can this fix Code 15?
By associating the ID VEN_197B&DEV_2368 with the section NO_DRV (No Driver), we are telling Windows: ‘I know what this is, it's a legitimate system component, don't try to stick an exotic driver on it that will conflict with ACPI’. This often transforms a ‘Device with error’ into a passive ‘System device’, freeing up resources so that the IDE driver can work in peace.

Here is the code. Is this an appropriate way to help Windows load its 32-bit ESDI_506.PDR driver to handle the CompactFlash connected to the JMicron controller?

1[Version]
2Signature="$CHICAGO$"
3Class=System
4Provider=%MFG%
5
6[Manufacturer]
7%MFG%=Intel_ICH10
8
9; --- Storage Section (Passive ID) ---
10"Intel(R) ICH10 SATA AHCI Controller (Identification)"=NO_DRV, PCI\VEN_8086&DEV_3A22
11"JMicron JMB368 IDE Controller (Identification)"=NO_DRV, PCI\VEN_197B&DEV_2368
12"JMicron JMB368 IDE Controller (MF)"=NO_DRV, MF\VEN_197B&DEV_2368
13
14[NO_DRV]
15AddReg=Common_AddReg
16
17[Common_AddReg]
18; No specific binary binding - Identification only
19
20[Strings]
21MFG="Gemini AI Support"

Thank you for your advice!