A place for me to post about my card and driver development without spamming other's threads. I have recently made a huge win. Real data from a PicoGus on Windows 10!

---

For those unaware, I've been working on a weird but promising setup: using an IT8888 PCI-to-ISA bridge behind an IT8893 PCIe-to-PCI bridge, under Windows 10, with the goal of eventually supporting ISA DMA / DDMA-style access for things like PicoGUS. Specifically my goal is to support old CNC ISA cards, which is a much bigger task than something like a GUS.

The hardware topology currently looks like this:

1Lenovo ThinkCentre M93p / Intel i7-4790 / Chipset Intel Q87
2Intel PCIe Root Port
3  -> ITE IT8893 PCIe-to-PCI bridge (on motherboard)
4      -> ITE IT8888 PCI-to-ISA bridge (my PCI-ISA card)
5          -> ISA slot
6              -> PicoGUS / ISA POST card

The IT8888 is detected by Windows as a PCI device. I wrote a KMDF diagnostic driver and a user-mode tool, "it8888ctl.exe", to poke at PCI config space, IT8888 config registers, port I/O, DDMA registers, traces, and a DMA common buffer.

At first, the IT8888 itself looked alive: PCI config reads worked, the device started, and I could program its positive decode windows. For example, the IT8888 was configured with classic legacy-style I/O decode windows:

1cfg58 = e4000220   ; SB-ish 0x220 window
2cfg5c = e3000330   ; MPU/GUS-ish 0x330 window
3cfg60 = e2000388   ; OPL 0x388 window

But actual ISA I/O reads from "0x220", "0x330", and "0x388" all returned "0xFF". At first I thought maybe the IT8888 was not initialized correctly, or maybe the ISA device was not responding.

The real issue turned out to be upstream bridge forwarding.

I added a "pci-dumpcfg" command to dump arbitrary PCI config space by bus/device/function. That showed the IT8893 bridge and the Intel root port both had their I/O forwarding windows effectively disabled/inverted:

1I/O base = 0xf0/f1
2I/O limit = 0x00/0x01
3decoded as base 0xf000, limit 0x0fff

So even though the IT8888 was configured to decode "0x220", the upstream PCIe/PCI bridge chain was not forwarding those low I/O cycles to it.

I then added raw CF8/CFC PCI config access to the driver, because Windows/HAL config writes were failing for the bridge registers. With that, I could manually open the bridge I/O windows.

For example, opening both bridges to forward "0x8000–0x8FFF" now works:

1bridge-iowin 0:28.3 0x8000-0x8fff
2  command old=0x0404 new=0x0405
3  io base  new=0x80
4  io limit new=0x80
5
6bridge-iowin 3:0.0 0x8000-0x8fff
7  command old=0x0407 new=0x0407
8  io base  new=0x80
9  io limit new=0x80

"pci-dumpcfg" then confirms:

1I/O window decoded: 0x00008000-0x00008fff
2contains 0x8390: YES

I tried two approaches after that.

First, I tried mapping legacy ISA ports into the high forwarded window:

10x220 -> 0x8220
20x330 -> 0x8330
30x388 -> 0x8788

The IT8888 accepted these high decode values:

1cfg58 = e4008220
2cfg5c = e3008330
3cfg60 = e2008788

Port I/O to those addresses now reaches the driver and is forwarded by the bridges, but plain reads from an ISA POST card naturally just return "0xFF" because a POST card mostly cares about writes to port "0x80".

I also tried opening the bridge windows to "0x0000–0x0FFF" for true legacy I/O. That technically works, but it is dangerous and started causing hangs after some commands. That makes sense: forwarding the whole low legacy I/O page through a PCI bridge can collide with chipset/PIC/PIT/DMA/ACPI/VGA legacy regions. So I am avoiding that except for very short controlled tests.

The big breakthrough was with PicoGUS.

PicoGUS has its own management/control protocol at:

1control: 0x1D0
2data low: 0x1D1
3data high: 0x1D2

So I mapped that into the safe high bridge window: IT8888 cfg60 = e20081d0

Then I opened both upstream bridges to "0x8000–0x8FFF" and talked to PicoGUS at "0x81D0–0x81D2".

This worked.

Protocol read:

1out 0x81D0 <- 0xCC
2out 0x81D0 <- 0x01
3in  0x81D2 -> 0x03

Firmware string read:

1out 0x81D0 <- 0xCC
2out 0x81D0 <- 0x02
3in  0x81D2 -> 0x70
4in  0x81D2 -> 0x69
5in  0x81D2 -> 0x63
6in  0x81D2 -> 0x6f
7in  0x81D2 -> 0x67
8in  0x81D2 -> 0x75
9in  0x81D2 -> 0x73
10in  0x81D2 -> 0x2d

Which decodes to:

1picogus-

This text is actually from the PicoGUS, specifically it's part of the "picogus-gus vX.X.X" text where X.X.X is the version number. pgusinit tells you this text and version number when it detects a PicoGUS. The fact we can see this in Win10 is a major step. After 2 years of messing about, I finally got provable real data from an ISA card on Windows 10 on a modern-ish PC (4th gen chipset Q87).

So the full path is proven:

1Windows 10 kernel driver
2 -> Intel PCIe root port
3 -> IT8893 PCIe-to-PCI bridge
4 -> IT8888 PCI-to-ISA bridge
5 -> ISA bus
6 -> PicoGUS

This is a pretty big milestone. It means the card is reachable through the bridge chain if the bridge I/O windows and IT8888 decode windows are configured carefully.

Current lessons learned:

1The IT8888 was not the only problem.
2The upstream IT8893/root-port I/O forwarding windows matter.
3Windows does not necessarily allocate/enable legacy I/O forwarding for this bridge chain.
4Raw PCI config writes via CF8/CFC were needed to force bridge I/O windows open.
5Forwarding 0x0000–0x0FFF is risky and can hang the system.
6A safer strategy is forwarding 0x8000–0x8FFF and mapping IT8888 decode windows into that range.
7PicoGUS management/control protocol works through a high alias, proven by reading the firmware string.

The next step is to add proper PicoGUS helper commands to "it8888ctl", instead of manually doing byte pokes. Something like:

1pgus-protocol
2pgus-fwstring
3pgus-read <cmd> <count>
4pgus-write8 <cmd> <value>
5pgus-write16 <cmd> <value>
6pgus-get-sb
7pgus-set-sb 0x220 irq dma type

After that, the next milestone is configuring PicoGUS into SB mode and testing SB DSP reset through an aliased SB window:

1IT8888 cfg58 = e4008220   ; SB alias
2IT8888 cfg5c = e3008330   ; MPU alias
3IT8888 cfg60 = e2008788   ; OPL alias

Then test:

1out 0x8226 <- 1
2out 0x8226 <- 0
3in  0x822E
4in  0x822A

The hoped-for result is the classic SB reset response:

10x822A -> 0xAA

There is still a lot left, like supporting real CNC ISA cards, especially real DMA/DDMA behavior. But at this point I have proven that real ISA hardware behind a PCIe-to-PCI-to-ISA chain can be reached from Windows 10, as long as the bridge and IT8888 decode windows are configured manually.

All my hardware, code, docs, and tests are in the repo in my signature, and specifically for this thread, the folder contains the code and driver in "DartFrogTek/PCIe-PCI-ISA/DFT_VMDA8/it8888vdma_win10_predosbox"

What i'm currently working on:

1Stop manually poking bytes and add real it8888ctl PicoGUS helpers, including real DMA/DDMA work.

---

Below is a section to talk about why im doing this on Win10, there is method to the madness.

Why Windows 10? wrote:

I'm doing this under Windows 10 first because it is the harshest and most useful test environment for this project. […]
Show full quote

I'm doing this under Windows 10 first because it is the harshest and most useful test environment for this project.

In DOS or Windows 9x, software can usually hit legacy ISA I/O ports directly and the system firmware/chipset may already have some legacy behavior enabled. That makes it easier to get a sound card or POST card to respond, but it also hides which part of the bridge chain is actually working.

Windows 10 is much stricter. It does not automatically make this PCIe -> PCI -> ISA chain behave like a real 1990s ISA bus. The OS did not give the upstream bridges useful legacy I/O forwarding windows, and normal low ISA ports like `0x220`, `0x330`, and `0x388` were not forwarded to the IT8888 at all. I had to prove and manually configure each layer:

Copy code to clipboard

1PCI config access works
2IT8893/root port I/O forwarding works
3IT8888 positive decode works
4kernel port I/O reaches the bridge
5real ISA hardware responds

That is why Windows 10 is useful here: if I can make the chain work from a modern protected OS with manually configured bridge windows, then I have proven the actual hardware path is functional instead of relying on BIOS magic.

It also makes DOS and older Windows easier to reason about later. Once the correct IT8893 bridge window and IT8888 decode settings are known, I can reproduce those settings from a DOS tool, Windows 9x VxD/WDM driver, or even an option-ROM/init utility. The working Windows 10 driver gives me a known-good register recipe.

So this is not "Windows 10 because I expect Win10 to be the final ISA gaming environment." It is more like a diagnostic proving ground. If PicoGUS answers through this chain on Windows 10, then the same bridge/decode configuration should be portable to DOS or older Windows, where the software stack is actually more compatible with ISA sound hardware.

The current PicoGUS result is exactly that kind of proof:

Copy code to clipboard

1Windows 10 driver
2  -> manually opens root port + IT8893 I/O window
3  -> programs IT8888 decode window
4  -> performs port I/O
5  -> PicoGUS returns firmware string bytes: "picogus-"

That means the electrical and bridge path is real. The next job is packaging the same initialization into a cleaner tool/driver so DOS, Win9x, or other older environments can set the bridges up before using the ISA device normally.

---

A small section about possible address-translation fallback via FPGA incase some legacy ISA devices require the IT8888 or ISA bus to see the original low addresses exactly, an FPGA could translate the address phase of PCI transactions:

Possible FPGA address-translation fallback wrote:

One possible fallback is a small FPGA/CPLD interposer that performs address translation on the PCI side before the IT8888 sees t […]
Show full quote

One possible fallback is a small FPGA/CPLD interposer that performs address translation on the PCI side before the IT8888 sees the cycle.

The current software approach is to keep the upstream bridges forwarding a safe high I/O window, such as:

Copy code to clipboard

10x8000–0x8FFF

and then program the IT8888 to decode high aliases like:

Copy code to clipboard

10x81D0 for PicoGUS control
20x8220 for Sound Blaster
30x8330 for MPU-401
40x8788 for OPL

This already works for PicoGUS control access, so an FPGA is not needed for that part. However, if some legacy ISA devices require the IT8888 or ISA bus to see the original low addresses exactly, an FPGA could translate the address phase of PCI transactions:

Copy code to clipboard

10x8220 -> 0x0220
20x8330 -> 0x0330
30x8788 -> 0x0388

while leaving data phases unchanged.

That would let the host and upstream bridges use a safe high I/O window, while the IT8888/ISA side sees traditional legacy addresses. This is not the first choice because modifying PCI address/data lines in real time is timing-sensitive and should be done with proper glue logic, not a microcontroller bit-bang hack. A small CPLD/FPGA would be the right tool if it becomes necessary.

For now, the better result is that PicoGUS has already responded through a pure software-configured high alias. The FPGA idea remains a fallback only if certain ISA devices cannot tolerate high-address aliasing or if real SB/DMA behavior requires exact low-address presentation.