Isn't the IT8888 configured in some transparent mode where it masks itself like intel PCI2ISA bridge? Look at full PCI devices listing if you find some...

hpxca wrote on 2026-02-11, 23:24:

Edit: I guess it's because it's the older ITE8888F instead of the newer ITE8888G. Might still work since as best I can tell they are very similar, but the current program doesn't recognize it.

The F and G variants appear to be the same chip with a different package, so there is likely something else stopping it from working

Yeah, it's somehow hidden or lying. I tried PCICFG and pcisleep under DOS. Both list everything you'd expect including the usb controller and Ethernet controllers (when they're enabled). But the IT8888F isn't listed. There is however an Intel PCI to ISA bridge listed. So if that's not actually the chipset then that must be it.

hpxca wrote on 2026-02-12, 04:14:

Yeah, it's somehow hidden or lying. I tried PCICFG and pcisleep under DOS. Both list everything you'd expect including the usb controller and Ethernet controllers (when they're enabled). But the IT8888F isn't listed. There is however an Intel PCI to ISA bridge listed. So if that's not actually the chipset then that must be it.

The Intel PCI to ISA bridge would be the the LPC interface on the ICH4 southbridge which is used to connect to the Winbond Super I/O chip

So my knowledge of how PCI works is pretty limited, but the AI has been teaching me a lot. Digging through the datasheet of the IT8888F I can't find anything that suggests it can hide itself intentionally, like a setting in a configuration register or a strapping resistor. It does support subtractive decode though and I think that's probably what's going on here. Given this is an ICH4 southbridge I kind of expected DMA to just work and as @KYA mentioned in the original post the ICH4 supports PPDMA so why wouldn't it just use that? I wondering if maybe the BIOS just isn't configuring it properly? The chip supports configuration via an external serial EEPROM as well, but I see no such EEPROM anywhere on the board around the chip so I assume that the BIOS is setting up the registers at boot. I even dumped the BIOS of this board and put it into modbin6 to see if there was something hidden in there that might be related to it, but nothing stood out. I can't find any other versions of the BIOS for this board anywhere.

With some AI help I might try a few things to play with the configuration registers and see if I can somehow "turn on" PPDMA? But i'm not sure I can make it appear on the BUS so that KYAs program can find it, though I may be able to write something that can detect it anyway...

hpxca wrote on 2026-02-12, 04:14:

Yeah, it's somehow hidden or lying.

ICH settings usually hide PCI-ISA bridge (IT8888) to avoid conflicts.
You need to search ICH datasheet for something like this.

Ah yes, it should be like this. So to check and clear bit 24. But it seems also this feature is depending on HW configuration - if Ad22 line is routed to ITE as described...

Thanks guys, I installed Open Watcom v2 on my K6-2 and with a little help from Gemini wrote a simple C program with DOS32/A to read and modify bit 24 in the GEN_CNTL register of the ICH4. This worked to unhide the ITE PCI to ISA bridge on that Pentium 4 board which was on Bus 2 Device 6. With this done the itexxx.exe had no issue finding it and configuring it for DDMA. Unfortunately, this is where the good news ends. I tried two low-end Vibra16 sound cards, the really, really low-end CT4170 which really has no 16-bit DMA at all (the pins aren't even there on the ISA connector, so high DMA = low) and the CT4180 on which high DMA works. I tried both DMA 1 and 3 for low, and 5 for high on the CT4180. In all cases, as soon as any attempt to do DMA takes place the system just locks up. This happens in the SB "diagnose.exe" when it tries to test DMA and when doom is started after it tries to initialize the sound.

Notably, in the datasheet above bit 25 seems to be there to switch the PPDMA request/grant pair. As a separate little project, I also tried to set bit 25 (without the PCI/ISA bridge unhidden) and checked that the pins(s) were not being used for GPIO in GPIO_USE_SEL as the datasheet recommends. Everything in the PCI_DMA_CFG register suggests that the board is all setup to do PC/PCI DMA (as opposed to DDMA), but despite trying both pairs DMA still doesn't work.

It was a fun little project and I learned a lot about PCI in the process, but it's a shame that boards ISA slots remain DMA-less.

Did you run VDMA8 driver as described in the 1st post?

I did yes right after itexxx.exe, it ran, did its thing (stayed resident I assume) and returned me to the command prompt, then I ran the game (doom) or diagnose. Doom locks up at sound init, diagnose got through the base address, midi address and IRQ and then the system locks up at the DMA test.

rasz_pl wrote on 2026-02-01, 07:27:

Do I understand correctly IT8888G DDMA slave lights up DACK on ISA slot and you program which one goes active?

IT8888 contains a DMA controller which is functionally compatible with Intel's original 8237. Among other things it replies with a DACK if a device in ISA slot sends a DREQ.
I program this DMA controller's registers by writing to certain ports (just like the original DMA controller) to set a base address, and a counter, and then unmask the appropriate channel.
The difference from the original DMA controller is that IT8888G's port addresses do not match those of an original controller.

The SBEMU-based TSR traps port IO to original DMA controller adresses (0-f, 8*h,c*h,d*h) and redirects it to IT8888's ports (with some necessary modifications).

rasz_pl wrote on 2026-02-01, 07:27:

Afaik SOFTMPU has perfect software compatibility thanks to relying on battle tested emm386.

I don't know if there's much difference (in terms of game compatibility) between jemmex and emm386. When I was talking about incompatible games, I meant those that can't tolerate any V86 manager, be it jemmex or emm386. For example, those working in "unreal mode", or the ones using pmodew, or pharlap dos extender, or some other VCPI host (where they run at ring 0, and there's no way to set a port trap).

hpxca wrote on Yesterday, 02:15:

In all cases, as soon as any attempt to do DMA takes place the system just locks up

Sorry for asking an obvious thing you already mentioned, but are you sure you have both REQ5 and GNT5 pins set to native function?
I've had the same symptoms on my IMBA board, when GNT5 was GPIO, which is quite understandable. The bridge sends a REQ to become a bus master, but never gets a GNT. PCI bus (and the entire system) locks up.

A quick glance at the ICH4 datasheet reveals that REQ5 is also multiplexed with REQB! Three functions on one pin... So you have to somehow tell the chipset, you want to use that pin as REQ5, not as REQB. By disabling PPDMA in ICH4 somehow?

hpxca wrote on Yesterday, 02:15:

Everything in the PCI_DMA_CFG register suggests that the board is all setup to do PC/PCI DMA (as opposed to DDMA), but despite trying both pairs DMA still doesn't work.

Yes, if I were you, then first I'd try to initialize this board to PPDMA. The question is - how did they wire the IT8888 chip to the ICH4? ICH4 has two pairs of PPDMA lines: REQA/GNTA, REQB/GNTB. The latter are multiplexed with REQ5/GNT5 PCI bus master lines. If they have connected ICH4_REQA<-IT8888_PPDREQ, ICH4_GNTA->IT8888_PPDGNT, ICH4_REQ5<-IT8888_IREQ, ICH4_GNT5->IT8888_IGNT, then it may be possible to use IT8888 in both modes (PPDMA and DDMA). But if they needed REQA/GNTA for a SuperIO chip, for example, they'd have to choose where to connect the remaing REQ5/GNT5 lines - to PP* pins (PPDMA) or to regular IREQ/IGNT pins (DDMA) of IT8888, thus making only PPDMA or DDMA mode possible.

Also you may check IT8888 PCI configuration space if PPDMA is enabled. By default it is, but what if they modify the value in BIOS? By the way, ITEXXX disables PPDMA in IT8888, because it was aimed at later chipsets, where PPDMA is absent.