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 2026-02-13, 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 2026-02-13, 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.

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.

Hi KYA, thanks for the interesting tips here. Your answer clarifies a few things, and since I'm fortunate enough to have a microscope (because I love tinkering with the hardware) and because the ITE888F is a QFP package I can answer a few of these questions:

First off, there is a winbond super I/O chip on this board handling the serial and parallel ports. So I believe your 2nd scenario is the one we have here. This is further backed up by what I can see of the wiring.

Pin 131 (PPDGNT#)/Pin 132 (PPDREQ#) - These run to the ICH4. I can't see the traces in their entirety, some run on inside layers and they're very hard to follow, but I can follow them far enough to know that these signals are going toward the south bridge chip. Unfortunately, given the ICH4 is a BGA chip there's no way I can be 100% sure what pins they run to without removing the chip (and I'm fully capable of doing that - but I'm not capable of reballing it and putting it back on) - so i'm not willing to risk it.

Pin 138 (IGNT#)/Pin 139 (IREQ#) - Pin 138 is pulled up via a 4.7k resistor to 3.3V. If there's another trace running from this pin it's hidden under the chip. Pin 139 may be completely unconnected or the trace may also run under the chip where I can't see it. But given there's nothing more then a pull-up resistor on 138 that I can clearly see, I have a feeling this pair isn't used.

That would be to say then based on what you said, DDMA can't work on this board the way it is wired. So the real question is why doesn't PPDMA work? I spent much of my morning trying to answer that and I pulled all the PCI configuration registers for the devices below and examined any registers related to PPDMA (or even DMA in general on them).

8086:1A30 - PCI Host Bridge - Didn't find much of interest here.

8086:24C0 - LPC Interface ICH4 - Lots of interesting stuff here as you'd expect

GEN_CNTL 32-bits starting at offset D0h - The initial value setup by the BIOS if you read this register after boot is 0x01002187. The interesting bits here are 24 and 25, which in this case are respectively 1 and 0. Bit 24 being 1 is of course what caused me so many issues earlier, that hides the bridge since IDSEL is indeed connected to AD22 (proven with my multimeter) and clearing this bit makes the bridge start to respond to configuration cycles. Bit 25 is the really interesting one here because it's initialized to 0 and yet according to the ICH4 datasheet this need to be 1 for REQ5 and GNT5 to be REQB and GNTB notwithstanding the contents of GPIO_USE_SEL.

So, I took a look at GPIO_USE_SEL since REQ5 could also be GPIO1 and GNT5 could also be GPIO17. GPIO_USE_SEL is initialized to 0x01A203180. Based on that Bits 1 and 17 are clear, so these pins aren't used for GPIO.

So I tried it, just set bit 25 and write 0x02002187 to offset D0h, clearing bit 24 (though this isn't critical it also shouldn't matter for DOS) and setting bit 25, but alas. No go, DMA still doesn't work.

PCI_DMA_CFG 16-bits at offset 90h - The initial value setup by the BIOS if you read this register after boot is 0x54d5. That would map the DMA's as follows:

DMA 0 - PC/PCI
DMA 1 - PC/PCI
DMA 2 - PC/PCI
DMA 3 - LPC
DMA 5 - PC/PCI
DMA 6 - PC/PCI
DMA 7 - PC/PCI

I think they reserved DMA 3 for the Super I/O parallel port - in one of the modes I think it defaults to using DMA 3. So that's not going to work regardless on the ISA bus, but this should not be an issue with the more common choices of 1 and 5. Interesting, but not really a problem.

I tried a few other misc things like turning off ACPI - none of it made any difference.

8086:244E - PCI Hub - Didn't find much of interest here.

1283:8888 - ITE8888F - So what of the bridge itself?

PPD_REGISTER 8-bits at offset 0x48 - The default value is 0xFF and if you unhide the bridge and read this register the value is 0xFF. As far as I can tell this is what it needs to be for PPDMA to work.

CMD_REGISTER 16-bits at offset 0x04 - I think that for PPDMA the bridge needs to be able to act as a bus master??? The default value for this register is 0x07 which would enable that (bit 2) and if you unhide the bridge and read it this register returns 0x07.

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?

This makes me wonder then, can you confirm with your knowledge, does the ITE8888F need to become a bus master for PPDMA to work? Because from the looks of how IREQ and IGNT are wired I'm not sure that it can. Bit 2 of the control register is Read-Only and the timing diagrams don't show IREQ or IGNT being used. I have a feeling this is a design flaw on the board where the designers may have thought that PPDREQ# and PPDGNT# alone were sufficient in this case, but I think they need IGNT# and IREQ# too. Maybe the same as your IMBA board.

download/file.php?mode=view&id=236341

Are they also connected to traces under the chip? Is it normal to pull up IGNT#?