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. However, this chip uses the LPC interface, it's not a PCI device, so I don't think that it needs REQA/GNTA.

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.

Based on what you said, if IREQ# and IGNT# aren't connected, 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

Sorry for asking an obvious thing you already mentioned, but are you sure you have both REQ5 and GNT5 pins set to native function?

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?

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. However, given the winbond chip is on the LPC bus, I think this is being accurately set and that the ITE8888F is using REQA and GNTA (but I can't prove it). I tried it, though - I wrote 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.

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.

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

Secondary Master Latency Timer 8-bits at offset 1Bh - Default in the datasheet is 00h, but the recommended value is 32 cycles (0x20). Reading this register after boot the value is 0x20.

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.

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.

This makes me wonder then, can you confirm with your knowledge, does the ITE8888F need to become a bus master for PPDMA to work? Are all 4 of PPDREQ#, PPDGNT#, IREQ# and IGNT# required? The AI (Gemini) seems to think so. I wish I could see for certain if IREQ# and IGNT# were wired to something - I might even remove the chip and take a look (i've removed and soldered large QFPs before). The ICH4 can have a maximum of 6 bus masters on the PCI bus. But there's an issue here - this board has 2x 1GE NICs, 4x PCI slots and the ITE8888F = 7 total potential bus masters. Did they run out of pins so they sacrificed DMA on the ITE8888F? If so why did they bother wiring PPDREQ# and PPDGNT# though?

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

Are they also connected to traces under the chip?

So I "borrowed" the IREQ# and IGNT# signals from the 4th PCI slot as shown in the photo and DDMA works! I have sound! Just don't use PCI slot 4 😀 So for sure that's why it was locking up, the same issue KYA had on his one board.

I don't have a lot of games on it, but here's what I tried.

Wolf3d - Works with sound
Keen 6 - Works with sound
Battlebugs - Runs, music but no sound
Terminal Velocity - Sound works in the setup program, but the game locks up the computer immediately after launching.
Doom - Works (somewhat oddly) with sound. The game runs and there is sound, but it "pauses" periodically for several seconds trying to perform disk operations. I'm not sure if it relates to the DDMA or my somewhat unusual PCI setup.

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

Even with the borrowed IREQ# and IGNT# PPDMA still doesn't work. The ITE datasheet suggests IREQ# an IGNT# aren't needed and in the PPDMA scenario the ITE8888F remains a target and not a master.

hpxca wrote on 2026-02-15, 03:06:

So I "borrowed" the IREQ# and IGNT# signals from the 4th PCI slot as shown in the photo and DDMA works! I have sound!

Great!!! Congratulations!

hpxca wrote on 2026-02-15, 03:06:

Doom - Works (somewhat oddly) with sound. The game runs and there is sound, but it "pauses" periodically for several seconds trying to perform disk operations. I'm not sure if it relates to the DDMA or my somewhat unusual PCI setup.

Strange. I have played both Doom and Heretic for about an hour on my Core2Duo system, and experienced no delays whatsoever.
I've had delays in Duke3d at 800x600, 44khz stereo, 8 voices (isn't maxing out everything a reason we build such systems?). Had to lower it down to 22hkz 4 voices.
But I think the problem is with Duke's sound library. Quake runs flawlessly at 1280x1024 without any hiccups.

hpxca wrote on 2026-02-15, 03:06:

Even with the borrowed IREQ# and IGNT# PPDMA still doesn't work. The ITE datasheet suggests IREQ# an IGNT# aren't needed and in the PPDMA scenario the ITE8888F remains a target and not a master.

ICH4 datasheet also clearly states that ICH's DMA controller is a master during PPDMA transactions. So, I believe, there's no need to connect REQ/GNT to have working PPDMA.
On your board Portwell guys have tried to configure it for PPDMA exclusively (which is natural for pre-pcie systems), but seem to have screwed out something.

I never tried to enable PPDMA myself, so I'm not an expert, but it seems you've found every relevant register in ICH4 datasheet.

I have an Advantech ICH4 board working in both PPDMA and DDMA modes away in the storage. In the end of the next week I'll try to dig it out and make PCI config space dumps for ICH4 host, ICH4 LPC and IT8888, to compare them to yours.
As far as I remember there was only one deviation from default values in IT8888 config space. Bit 30 of Cfg_54h register was set to one instead of zero.

I mean this one:
"1: Enabled, IT8888G will issue a dummy PPDREQ# message (empty requests) to update the PPDREQ# decoding in core logic chipset."
Maybe it's worth a try enabling it in your system... (the entire value of Cfg_54h should be CC003F3F instead of default 8C003F3F)

I mean this one:
"1: Enabled, IT8888G will issue a dummy PPDREQ# message (empty requests) to update the PPDREQ# decoding in core logic chipset."
Maybe it's worth a try enabling it in your system... (the entire value of Cfg_54h should be CC003F3F instead of default 8C003F3F)

@KYA thanks so much for your suggestions on this again. I checked this and actually on my board the config of that register was the same as yours 0xCC003F3F. I think the issue with Doom in the DDMA scenario was bus timing issues and not the DDMA itself. Those two bodge wires stealing the REQ/GNT signals are very long and honestly quite different lengths too. Due to this I think the PCI bus was having timing issues and having to retry many times causing bus contention. Since I think the IDE controller in the ICH4 is on the PCI bus when this happened and doom tried to access the disk the game would hang for a few seconds. I have a feeling that with better, more careful wiring that wouldn't have been an issue.

After this test I decided it was time to bite the bullet and take a closer look at the wiring. And I found it! The designers swapped PPDREQ# and PPDGNT# running PPDREQ# to GNT(A) and PPDGNT# to REQ(A). I cut the traces and swapped the signals - PPDMA now works. The dirty details are in the thread linked below because it seemed more relevant to that thread and the section of the forums then this one.

Pentium 4 industrial motherboard ? Portwell PEB-7702G2A with ISA slots!

It was a fun project and I learned a lot about DMA and PCI in the process!

Sorry I missed all this until now. Fantastic stuff. The DDMA master emulator is a large undertaking. Insane work. Really great job. This is probably one of the coolest double niche things I've seen in a really long time.

If that VDMA8 can see my ITE8888 based pci to isa slot card and talk to it, then that's it, it should work. The device manager in windows 10 can see my ite8888 card, so there should be no reason VDMA8 can't see my card in DOS. This has a real shot at working because since we are not messing with the ITE8888 trying to force it to act as the master, that job is now taken over by VDMA8, it significantly reduces problem points. Also if it doesn't work and I can get the source code, there might be ways to make it work. Does this master emulator support a 4x ISA bus? The ITE8888 can do 4 slots/cards iirc.

All my retro stuff is in storage atm, though I can make it up there in a week or so to grab stuff. I do have one pci to isa slot card on my desk and a lenovo thinkcentre M93p/i7 4790/(has pci slot still) to test with but i don't actually have an isa card to verify it's actually working. I'll make sure to grab a few machines and some isa cards asap.

From what I understand there's a few things people want me to test? My ITE8888 based pci to isa slot card with ITEXXX/VDMA8 (this thread)? and my card with some ASM for DOS given to me by Rabanik? which is a hardcoded board/chipset patcher that he said makes ISA DMA/IRQ to work on an ASRock ConRoe865PE, but from my research that board doesn't have an ISA slot/bus and it doesn't even have an 8888 (has Winbond, from what I seen), yet the code does configure both an 8888 the ich5 that is on that board. How curious. I can't test this, but I've seen it and It's interesting point of reference.

Anyway, I've finally seen both and I'll get back to work asap. I hope VDMA8 will work. if my card works with VDMA8, this would get us: [DOS, modern-ish MOBO (PCI slot), real ISA hardware] ... if my card works with VDMA8 and a PCIe converter with DMA, this would get us: [DOS, MOBO (PCIe slot), real ISA hardware], This is really interesting because it's a DOS path and imo has a much better chance of working since the whole slave/master inversion. Though this makes me wonder if you could build a version of VDMA8 to bypass DOS, but I assume since it's based on SBEMU, it's tied to DOS pretty well. Like, the trapping is likely all dos based. Would be nice to read VDMA8's code. Edit: Actually yeah nvm. KYA is right, put it all into SMM, something I think I said in the dISAppointment thread too. I can't do this. I've kinda tried. I'm not nearly good enough.

Something I see far more likely since it's no where near SMM level of bullshit, is modify VDMA8 and DOSBox, so it acts as the virtual DMA master front end, and a host bridge layer + host driver/library turns the guest’s DMA programming into commands for the real IT8888, which then serves the real ISA slot. Run whatever OS you want, dosbox-modified runs your programs which require some real isa dma, it then hands it off to the actual hardware. This obviously requires a lot of work, but this is do able without SMM knowledge.

Is this tied to the ITE8888 only? I mean the reason I was using the ITE8888 was because it was one of the only DDMA masters, but if it's only needing a DDMA slave, why not expand this to other chips that have DDMA slave? This could be a significant win in two ways.

"IT8888G has 16bit DMA channels, but it seems I've messed up something in my code, so they don't work. Descent 2 sound test does not play 16bit sound at all via DMA5. So, for now, only 8bit sound is working."

Interesting, wish I could help.

KYA, would it be possible to send me the source for both ITEXXX.EXE and vdma8.exe, or possibly release them as open source?

I would keep the source confidential if you preferred to send it privately. I built a PCI-to-ISA slot adapter using the IT8888 chip, and I am trying to verify a few things I am seeing on real hardware.

My guess is that ITEXXX.EXE is mostly straightforward IT8888 PCI/config/DDMA setup code. vdma8.exe is the more interesting one to me, since the virtual 8237/DMA translation layer is probably the key part. Right now I cannot tell whether the behavior I am seeing comes from the IT8888 initialization, the DDMA channel programming, the PCI/PCIe bridge path, or the VDMA translation logic.

One extra detail: this is not only on old DOS-era hardware. On my Z390 system, Windows 10 can see the IT8888-based PCI-to-ISA adapter through a PCIe-to-PCI bridge. I have also verified that I can send and receive certain low-level hardware/debugging commands from Windows 10 to the IT8888, and I can see that activity on my TLA714 logic analyzer. So at least some PCI/config or I/O traffic is definitely reaching the chip through the bridge path.

However, the behavior is not fully consistent yet. Some accesses appear to hit the IT8888, while others do not seem to reach it, at least based on what I am seeing on the logic analyzer. That is part of why I am trying to understand the exact initialization and DDMA programming sequence instead of guessing from the binaries.

Without getting hopes up too much, I think there may be a path to making ISA DMA work outside of plain DOS, possibly even from a modern OS through a PCIe-to-PCI bridge into an IT8888-based PCI-to-ISA adapter. PCILeech got me thinking about the PCIe bus-master/DMA plumbing side of the problem, but the goal here would not be arbitrary host-memory access. I am thinking more along the lines of a controlled host driver or virtual 8237 layer using locked DMA-safe buffers, which then programs the IT8888 DDMA slave for real ISA transfers.

In other words, the IT8888 would still be treated as the PCI-to-ISA bridge/DDMA slave endpoint, while the host driver or emulator layer would provide the missing virtual 8237 side. vdma8.exe seems especially relevant because it already does some version of that translation for DOS.

Having the source would make it much easier to understand the exact IT8888 register programming and avoid guessing from the binaries.