myne wrote on 2025-04-25, 00:43:

So if my understanding is correct, it is basically the same as any pci era southbridge Eg pii4x - without the extras. […]
Show full quote

So if my understanding is correct, it is basically the same as any pci era southbridge Eg pii4x - without the extras.

I looked at the board I extracted, and the chip itself doesn't really seem to need many supporting components.

BTW, I forgot to update the nets on the schematic.
I'll upload the one I have that is slightly updated and key components moved.

I had a quick read through some of the pii4x docs and yes seems very similar.

Thank you, that's very helpful!

RayeR wrote on 2025-04-25, 04:13:

Yes, this would solve the problem if both DMA devices are on the same PCI(e) bus. But the IT8888 will be connected to different […]
Show full quote

Yes, this would solve the problem if both DMA devices are on the same PCI(e) bus. But the IT8888 will be connected to different PCI bus than PCH's LPC-DMA. It depends on where the ITE will be connected, according to Z390 block diag:
https://www.guru3d.com/data/publish/200/f1ec0 … ock-diagram.png it may be attached to CPU PCIe or PCH PCIe so it depends on configuration of root PCIe bridge in CPU and PCH too. It may just happen that desired DMA IO transaction don't reach the slave PCI bus where IT8888 is waiting for bot will go to other bus with LPC block (and I guess this is the default settings as PCH still/may implements other legacy stuff like KBC, timers...), need to be checked. Maybe for some quick testing one could use some PCIe POST card: https://en.wikipedia.org/wiki/File:BIOS_POST_ … and_LPC_bus.jpg
and check if he can pass some OUT writes to port 80h at the PCIe bus supposed to connect IT8888...

BTW form previous discussion I recall that intel PCH 5xx series and newer dicarded the LPC block but it still doesn't answer where legacy IO port access is routed. I don't have such new HW so can't test...

I understand now. Yeah, you're right. It absolutely matters how the motherboard implements its PCI hierarchy and where the IT8888 is attached. I would suspect that all southbridge/PCH implementations act as the sole subtractive decode agent, since there's only one subtractive decode agent allowed per PCI bus segment. This ensures that if no user device claims legacy I/O addresses, the PCH will handle them by default.

However, whether user slots are connected to that same bus or behind a PCI-PCI bridge is up to the motherboard's design. And that matters because PCI-PCI bridges typically only forward I/O transactions if the address is within their configured I/O range. From my research subtractive decode downstream of a bridge is uncommon these days, and even when possible, it still depends on whether the transaction reaches the downstream bus segment.

So realistically, the IT8888 card will only see legacy DMA I/O cycles if one of these conditions is true:

• It's on the same root PCI bus segment as the legacy I/O initiator (CPU or PCH).
• It's behind a bridge that forwards I/O cycles for the legacy DMA address ranges.
• It's behind bridge that can be configured to forward those legacy I/O ranges; which isn't always possible without BIOS or firmware support.

This IT8888 PCI/ISA card will have specific motherboard compatibility depending on it's design, and probably won't support that many boards considering how narrow the conditions I outlined above are. Even though this is all true, I will still complete the prototype and finish the PCB. There's no real reason not to. The more boards we can allow ISA, the better. I will also make the PC/PCI DMA lines easy to solder to and try to provide a non-DDMA configuration BIN so that the card can target as many boards as possible.

RayeR wrote on 2025-04-25, 04:43:

UPDATE, something from PCH 6xx datasheet:
...
so legacy DMA ports are not there but as the real IO port scan could show something different...

Quickly using RWEverything on the wife's z390, only one of the five PCI-PCI bridges had I/O forwarding and not in legacy I/O ranges (IO Range 0x00003000 - 0x00003FFF). This bridge connects bus 0 to bus 1. Devices on bus 1 are behind this bridge. It's not going to work on her desktop as is. (I have a laptop so it's not worth checking).

Interesting. So basically for the maximum motherboard compatibility, you'd actually need to use a FPGA, since it's possible to emulate DMA controller registers at say some available forwarded I/O space like 0x3000–0x301F (in reference to the z390 range above). Realistically using a FPGA as a protocol converter (PCIe to ISA) and PCIe TLP modifier would be the end all be all solution, since you could largely do whatever you wanted and map it to whatever was available provided there were some forwarded I/O space the card had access to, or better yet rely on OS provided BAR resources. It's also possible you could use the IT8888 chip to handle all the ISA stuff and provide the FPGA with PCI transactions and convert the transactions into the remapped io range. Perhaps use a PCI/PCIe bridge as well to provide the FPGA with PCIe TLPs and let the FPGA only modify the TLP. Also this adds a layer so timing/latency might be an issue, so the less bridging the better. An ideal world would be FPGA implementation only. It's not magically going to support everything either. You'd still need to rewrite drivers or software to target whatever addresses too, to effectively replace the legacy path.

kagura1050 wrote on 2025-04-25, 05:46:

I found a (possibly complete) schematic for a simple PCI-ISA adapter using the IT8888F on an old website of a Taiwanese prototyp […]
Show full quote

I found a (possibly complete) schematic for a simple PCI-ISA adapter using the IT8888F on an old website of a Taiwanese prototyping board company.
Creating a clone of this circuit might be a good starting point.

https://www.costronic.com/Ev71pkit.htm
https://www.costronic.com/SH8888.pdf

Hey thanks! I mentioned costronic a page or two ago. I had no idea they had schematics. What a great find! Also the schematic clears up a confusion I had about why they wanted you to use PC/PCI DMA over DDMA, which it seems the card configuration was up to the end user so they could do either. So it's already helpful. Thanks again.

Hmm.
I figured the southbridge would be a blocker, but I didn't suspect a pcie to pci bridge would be a blocker.
I was thinking of a pci bridge as basically a blind protocol converter like any bridge in networking is.

Why would it be a blocker? Arent those bridges completely transparent basically?

Bacause not all IO tranactions are passed everywhere through bus tree as we discussed just above.

https://www.digikey.in/Site/Global/Layouts/Do … 883CF3B830B07EC

https://www.amd.com/en/products/adaptive-socs … scale-plus.html

Possible fpga pcie bridge.
Hobbiests have implemented isa, so I'd guess the dma controller would be the hard part.

I spent today asking a few people and there is a possibility of PCIe/PCI Bridge configuration via ACPI SSDT or via UEFI DXE Driver. One guy on the phone called me daft and mad but then later emailed both ACPI SSDT and DXE boilerplate with/without DMA, 🤣. Lots of this post are copy/pasted from emails and or transcribed from phone conversations. I've added/removed parts and made edits here where needed.

The key advantage of using an SSDT is that you don't need to modify firmware or develop UEFI code. The SSDT approach should be less invasive and is generally safer than developing and installing custom DXE drivers.

• ACPI SSDT (Secondary System Description Table):
  • Loaded by the operating system during boot
  • Provides configuration through ACPI methods that the OS understands
  • Platform independent (works across operating systems)
  • Changes take effect after OS handoff

• DXE Driver (Driver Execution Environment):
  • Runs during the UEFI pre-boot phase
  • Configures hardware before the operating system loads
  • Part of the firmware ecosystem
  • Changes take effect before OS handoff

Both of these potential solutions below do not fully account for the complexity of I/O transactions across a multilayered bus topology. So systems with multiple PCI buses, like for example southbridge/PCH on bus 0, and PCI slots on bus 1, then the IT8888F card would specifically need to be attached to a PCI slot that has the proper bus mastering path back to system memory. Although it may still be possible to configure all bridges within a system to handle I/O transactions properly across complex topologies; it becomes very challenging with more modern systems.

The key is to configure each bridge in the path to:

• Pass through the specific I/O address ranges needed by the ISA devices
• Enable appropriate forwarding of bus master transactions
• Handle memory address translations correctly

For this to work:

• Map all bridges in the system topology and their relationships
• Create custom ACPI SSDTs for each bridge that requires configuration
• Configure I/O and memory ranges to not overlap but still cover all needed addresses
• Ensure proper transaction forwarding between all bridges

The PCI specification provides mechanisms to make this work, even in complex topologies. Each bridge in the PCI/PCIe hierarchy has:

• I/O base and limit registers to define forwarding ranges
• Memory base and limit registers
• Prefetchable memory base and limit registers
• Configuration options for transaction forwarding behavior

The more complex the topology, the more challenging it becomes to ensure every bridge in the chain is properly configured. But theoretically with the right configuration of each bridge element, it's possible to create a path for ISA DMA transactions to flow through the system regardless of the specific topology.

The main problem is when a PCI bus with PCI slots is disconnected from other PCI buses which are attached to southbridge/PCH, which can happen. When a PCI bus with PCI slots is structurally disconnected from other PCI buses attached to the southbridge/PCH, this creates a fundamental topology issue. This issue is physically unsolvable, these kinds of motherboards will simply be unsupported.

Keep in mind that some modern chipsets might also have limitations in how they handle certain legacy transactions, so while it's theoretically possible, we might encounter hardware level restrictions that can't be overcome through software configuration.

~

DXE Driver (Driver Execution Environment):

This would be an absolutely last resort but I should mention the UEFI spec does have an EFI_PCI_ATTRIBUTE_ISA_MOTHERBOARD_IO Attribute bit.
"If this bit is set, then the PCI I/O cycles between 0x00000000 and 0x000000FF are forwarded onto a PCI root bridge. This bit is used to forward I/O cycles for ISA motherboard devices onto a PCI root bridge."
https://uefi.org/specs/UEFI/2.11/14_Protocols … us_Support.html

It's possible the reason my wife's z390 didn't have that address range forwarded on the bridge is because there wasn't hardware asking for it or a DXE driver setting that bit. Not to mention it's entirely possible that a system's UEFI firmware doesn't implement or honor EFI_PCI_ATTRIBUTE_ISA_MOTHERBOARD_IO, even though it's defined in the UEFI spec. The main problem with setting up a DXE driver to set that bit, is that it likely needs to be signed for secure boot, if secure boot is turned off then you can load DXE via UEFI shell from USB boot on real hardware. This is not ideal. For testing it's also possible to use UEFI Shell + OVMF (QEMU/VMware).

It also should be mentioned that just setting this bit alone is not the full story. It's possible that just setting this bit would allow ISA DMA to traverse the bus topology, however, we'd likely need to create a UEFI DXE driver that exposes a protocol for the OS to interact with while also setting the attribute flag. Which has it's own problems. If IO forwarding happens to work with bit setting and custom protocol, then I'm not sure many will want to disable secure boot and load a random DXE driver to get an ISA card working. Like I said absolutely last resort.

~

Testing rig:

I do have a Lenovo ThinkCentre M93p. which has i7-4790, 32gig, Quadro K2200, the motherboard has Lynx Point Q87 PCH and IT8733 and IT8893 chips. It's got a physical PCI slot. Likely connected via IT8893 since it's a PCI Express to PCI Bridge. I I found a "M93p" schematic from badcaps but it claims to not have a IT8893 chip or physical PCI slot, this actually aligns with the M73p instead. Can't find a datasheet for the IT8733 but looks like a SIO Chip on LPC bus which provides 2 COM and PRT ports over a cable based on the M93p/M73p schematic. The Q87 PCH does not have a PCI bus, which makes the appearance of the IT8893 logical. The IT8893 does in fact have a ISA Enable (I_EN) function on the Bridge Control Register (BRIDGE_CNT) and also supports PCI-to-PCI bridge with subtractive decode for legacy devices. M93p Topology: PCH -> IT8893 -> PCI Slot. At first glance this looks like an ideal system to test a DXE driver with EFI_PCI_ATTRIBUTE_ISA_MOTHERBOARD_IO set for ISA IO forwarding to PCI bridge. Then probe around and see if the IO range is actually forwarded.

It will take me a day or two to get the M93p system setup for messing around with it. I'll setup a github with kicad stuff, docs/datasheets, ACPI SSDT stuff, boilerplate DXE drivers setting the bit with and without DMA, etc... Link is in my sig.

I can't tell you which "gadget-manual" to search for. 😉

Grub, the boot loader, has a setpci command. This can be used to change the configuration of the bridges before the start of the operating system...

EduBat wrote on 2025-04-26, 11:24:

Grub, the boot loader, has a setpci command. This can be used to change the configuration of the bridges before the start of the operating system...

Yeah, that's true, good idea. The more options the better. Though requires GRUB and the setpci command might be restricted or blocked when Secure Boot is enabled due to GRUB's lockdown mode.

If you found that board, which should be similar to the one you have, the bios might show you some tricks too.

I have the first pass of the schematic largely done. I have sourced all the symbols and footprints. I tried following the Costronic schematic as close as possible. I left out BCLK cap, FLASHROM, and ROMCS/NOGO jumpers for now. Other than that it's basically the same. I have yet to mess around with routing/placement of anything. I selected footprints/components that would be easy to hand solder, like 1808 caps and rest through hole components. You're welcome to critique and/or make changes. You can submit a pull request for the schematic/board via link in sig if you want. (ISA8888_KiCAD folder.)

Not keen on the smd RNs as used in the board I posted?

myne wrote on 2025-04-27, 07:03:

Not keen on the smd RNs as used in the board I posted?

I wanted to since it would make routing so much easier but I thought people might have trouble with hand-soldering, aren't they like 0402s? I'm not sure what people would be willing to put up with. Ideally we would have the boards assembled with all smd parts where possible from the fab house, and only leave the IT8888, jumper headers, ISA connector, and electrolytics for the user to solder.

At the moment, since we don't even know if it will work, I was thinking it would be beneficial to be able to clip a oscilloscope / logic analyzer probe on through-hole components. The ISA bus can be probed via pin headers jammed into each edge of the ISA socket. I was probably going to add a pin header in between all the pins on the PCI bus too.

I think if someone is confident enough to tackle the ite, they'll be ok with a few 0603 RNs

As for isa, there's always the option of not cutting the pins once soldered.

Personally, I'd just 1:1 copy the Asus board I found. Ie the schematic.
It's already proven by one of the largest oems in the world.

The odds of screwing it up go way down unless you're a complete monkey with the layout.

dartfrog wrote on 2025-04-27, 09:32:

At the moment, since we don't even know if it will work

I thought there's issue with DMA port range routing, which is in some way glued to the PCH/Southbridge.
Maybe there's some PCI(e) dev card(s) where we may check is it possible at all prematurely ?

I saw this type of riser cards PCI-ISA mentioned earlier (by Costronic IIRC), which I contacted few weeks ago with no luck, but I saw those cards reported working on ICH5 motherboards like venerable P5PE-VM and 775i65G, because of full DMA support in the ICH. DOS SB Pro/SB16 emulation in SB Live/Ensoniq ES137x ended after ICH5, because no legacy DMA in the ICH anymore.
I saw some ISA-capable industrial MOBOs with ICH6 and up which is clearly stated there's PCI-ISA bridge with no DMA support. I own P4BWA which has +0x800 port range shift at the ISA slot BTW with Winbond PCI-ISA bridge, capable of DMA but no support of -.

Just in case, I own two 4690k's and two 4670k's (they're 15-20$ delivered here), all reached 1.29V 4.5GHz and 1.36V 4.8GHz, only one core enabled and 37-38C which is massive overkill even for CPU hungry DOS titles: 300+ FPS for build games 1600x1200 (seems measurement bug, because FPS quantized like 240/360, nothing inbetween), 150 FPS Q1sse/Q2sse DOS 1600x1200 with GM music and SB Pro via V0.2 adapter. IGP even faster. FASTDOOM 1280x1024 everything maxed out - 350 fps capped. Seems we're now somewhere near LFB write speed constraint.

Dartfrog, I see one potential problem with ISA IO bit. As stated:
"If this bit is set, then the PCI I/O cycles between 0x00000000 and 0x000000FF are forwarded onto a PCI root bridge. This bit is used to forward I/O cycles for ISA motherboard devices onto a PCI root bridge."
I think we need finer granularity for setting IO windows. We need only legacy DMA ctrl. ports to be forwarded to ITE but the rest, like legacy timer, etc. ports should still go to PCH legacy block. Only if you use FPGA to emulate all that legacy stuff you could completly cut off the whole IO range 0-FFh.

For setting a bit in PCI cfg reg I use my ROMOS option ROM (vga16bit decode enable) to do it before OS boot. But I don't know if current UEFI still support legacy boot ROMs.

RayeR wrote on 2025-04-28, 12:53:

Dartfrog, I see one potential problem with ISA IO bit. As stated: "If this bit is set, then the PCI I/O cycles between 0x0000000 […]
Show full quote

Dartfrog, I see one potential problem with ISA IO bit. As stated:
"If this bit is set, then the PCI I/O cycles between 0x00000000 and 0x000000FF are forwarded onto a PCI root bridge. This bit is used to forward I/O cycles for ISA motherboard devices onto a PCI root bridge."
I think we need finer granularity for setting IO windows. We need only legacy DMA ctrl. ports to be forwarded to ITE but the rest, like legacy timer, etc. ports should still go to PCH legacy block. Only if you use FPGA to emulate all that legacy stuff you could completly cut off the whole IO range 0-FFh.

For setting a bit in PCI cfg reg I use my ROMOS option ROM (vga16bit decode enable) to do it before OS boot. But I don't know if current UEFI still support legacy boot ROMs.

This is a great observation! This is the main reason outside of the previously noted DXE driver complexities, why a UEFI DXE Driver is the last resort option. The way I understand it is that if we went down that route then the card would need to handle everything forwarded to it. Since the Southbridge/PCH will no longer care about what it has forwarded. Unless I'm mistaken and unclaimed IO will get taken back up by the Southbridge/PCH if unclaimed, but I'm fairly certain this is not how it works.

I'm hoping that by using ACPI SSDT instead we can granularly set what we need. SSDT tables can add missing features to the existing ACPI. The problem with this approach is that we would need to generate a script that is able to autoconfigure a modular SSDT file for the system in question, since you'd need to know which PCI-PCI bridge the IT8888 is attached too (PCI address, for example 0:1C:3/0x001C0003) and also getting the PCI configuration space base address from the MCFG table data (for example 0xF8000000). Then compile that modified file with intel's iasl compiler to get the file needed. (There's also other problems, but likely mendable.) All that shouldn't be hard, however I'm trying to figure out how a Windows end user can easily modify their tables without a custom bootloader and without disabling secure boot (tough challenge). Mac and Linux users should be able to do it far easier.

It might come down to requiring a custom bootloader / disabling secure boot, but I'm unsold on that solution and I will try my absolute best to forego that.

~

I am currently messing with routing of the various power rails and looking for ISA cards that need a -5v rail. I only know of like 5-ish cards that do and I'd like to try and support them. I'll end up generating the -5v rail with a MAX660.

I'm not expert on ACPI but I doubt that ACPI SSDT resp. OS ACPI interpterer can do more than HW allows. I think that ACPI only works as some abstraction layer above the HW so OS need not to know what bit in what register to set but instead it execute some function/method (how it's called). The same for DXE. So if the HW allows only enable / disable forwarding the whole 0-FFh IO window then it would not be possible to narrow it to forward only e.g. 10-20h and left the rest...
In case you would use PIIX4 instead of IT8888 you could use legacy IRQ PIC, timers, RTC, etc from it but still you may need something from PCH in this legacy range, I don't know...

For negative supplies you can inspire by my version of LPC2ISA adapter. It's not intended for high current draw but it's far enough for soundcards that needs usually only -12V for opamps, not the -5V...
http://rayer.g6.cz/hardware/lpc2isa/schema.png

RayeR wrote on 2025-04-28, 15:57:

I'm not expert on ACPI but I doubt that ACPI SSDT resp. OS ACPI interpterer can do more than HW allows. I think that ACPI only w […]
Show full quote

I'm not expert on ACPI but I doubt that ACPI SSDT resp. OS ACPI interpterer can do more than HW allows. I think that ACPI only works as some abstraction layer above the HW so OS need not to know what bit in what register to set but instead it execute some function/method (how it's called). The same for DXE. So if the HW allows only enable / disable forwarding the whole 0-FFh IO window then it would not be possible to narrow it to forward only e.g. 10-20h and left the rest...
In case you would use PIIX4 instead of IT8888 you could use legacy IRQ PIC, timers, RTC, etc from it but still you may need something from PCH in this legacy range, I don't know...

For negative supplies you can inspire by my version of LPC2ISA adapter. It's not intended for high current draw but it's far enough for soundcards that needs usually only -12V for opamps, not the -5V...
http://rayer.g6.cz/hardware/lpc2isa/schema.png

No, you're right. I just got off the phone with the guy that gave me the ACPI information and boilerplate. There was miscommunication between us. Hardware would have to forward the entire window (hardware dependent, some might allow slices, almost all don't).

I also misspoke in my previous message, I said "Since the Southbridge/PCH will no longer care about what it has forwarded. Unless I'm mistaken and unclaimed IO will get taken back up by the Southbridge/PCH if unclaimed, but I'm fairly certain this is not how it works." Both are true. However we're not forwarding the PCH, but rather the PCI-PCI bridge. I am hoping that the PCH will handle all undesired I/O internally upstream from PCI-PCI bridge. If it does, then the PCI-PCI bridge forwarding the entire range would be fine since the undesired I/O is getting claimed upstream and the IT8888 positively decoding the desired I/O downstream won't cause collisions.

No idea though, I don't think anyone's actually tried this and if they have there's no mention of it online or in books that I can find. It's also entirely possible the PCH is internally handling the desired I/O too and forwarding on the PCI-PCI bridge will do nothing.