Bummer.

If you can confirm it's a 1:1 perfect a/b swap:

Wouldn't it be correct if the slot was on the back?
I'm not loving the chance of no other fallout.

https://upload.wikimedia.org/wikipedia/common … SA_Bus_pins.svg

It looks like the data/address lines on the gus would get the brunt of it, but who knows where it was trying to earth

myne wrote on 2025-07-24, 07:26:

Bummer. […]
Show full quote

Bummer.

If you can confirm it's a 1:1 perfect a/b swap:

Wouldn't it be correct if the slot was on the back?
I'm not loving the chance of no other fallout.

https://upload.wikimedia.org/wikipedia/common … SA_Bus_pins.svg

It looks like the data/address lines on the gus would get the brunt of it, but who knows where it was trying to earth

No biggie. We will get it soon. My wife is really pushing me now to finish it after seeing it being recognized in WinXP. Guess this is a full time project job now.

Yeah it's a perfect A/B swap, and you're right it would work on the back. Great idea! You saved me a bunch of soldering.
Well, there's only one way to find out, and we'll just keep fixing things until there's nothing left to fix!

For the GUS I believe the ISA8888 card sent -/+12v to U1 and earthed through the same chip. Or so I think based on tracing the traces on the GUS, might be wrong on that.

Lol good attitude at least

Ah yes, that ISA pin/sides numbering, It also seemed weird to me and I tend to swap it in the past but I double checked, measuring on a real card in hand, checking again... But on some other project I flipped pin numbering on display FFC cable (I temporaly solved it by manufacturing aux FFC cable that flipped it back choosing top/bottom contacts side, JLC can do cheap flexi PCBs now)... seems no one could avoid this kind of errors...

But in your case the fix would be very easy. Just remove the ISA slot by hot air and solder it on back side of the PCB. I see there are no components on back side that would collide, maybe that few elyts - you can solder some with a bit longer wires to move them along the slot. As you have the card on cable riser it mechanically doesn't matter on which side the ISA slot is... 😀 EDIT: heh, it was already told, just refresh the page...

LSS10999 wrote on 2025-07-14, 15:05:

- PicoGUS can't work in GUS mode behind LPC, citing no memory detected. I wonder if I need to configure something memory-related for the LPC controller. The card itself is actually fine, however.

Recently I found a tool called GUSTEST which has its source code included. Reading the code revealed something very important, that GUS actually makes use of 0x300 port range extensively, with several registers placed at least 0x100 away from the base address. The DRAM I/O register (base + 0x107) is among those. So if using 240h base range, I need to make sure ports 0x340-0x347 are all forwarded correctly.

LSS10999 wrote on 2025-07-14, 12:08:

Maybe the issue is elsewhere as replacing the regulators (as well as cleaning the contacts just in case) does improve the chance of the card being detected but some of the issues still persist like there's not enough power on the Wavetable header that WavetablePi would keep rebooting itself. For now I'm using something different that doesn't require as much power for MIDI.

I've managed to work this around, by connecting WavetablePi's Pi Zero 2W to an internal USB port using a micro-USB cable and a USB header-to-female converter. This allowed 5V from the motherboard's USB to feed the WavetablePi as well as the CT2290 itself so both can work reliably. The USB ports of P8B75-M doesn't appear to be powered when the system is powered off, so no risk of the board's 5V being backfed.

On the other hand, it seems CT2290 is not affected by the issue I had with other Creative cards (CT2950/CT4390) on NT 3.51. Everything works fine there with just the SNDBLST driver. However, it still doesn't work well with Wolf3D-based games just like other Sound Blasters, with sound still cutting off under certain occasions.

LSS10999 wrote on 2025-08-13, 11:15:

LSS10999 wrote on 2025-07-14, 15:05:

- PicoGUS can't work in GUS mode behind LPC, citing no memory detected. I wonder if I need to configure something memory-related for the LPC controller. The card itself is actually fine, however.

Recently I found a tool called GUSTEST which has its source code included. Reading the code revealed something very important, that GUS actually makes use of 0x300 port range extensively, with several registers placed at least 0x100 away from the base address. The DRAM I/O register (base + 0x107) is among those. So if using 240h base range, I need to make sure ports 0x340-0x347 are all forwarded correctly.

PicoGUS 2.2.0 behind v0.2 LPC2ISA Asrock Z87M-Pro4 - memory working (screenshot from Impulse Tracker attached). While Doom, FastDoom,DukeNukem3D - don't. Descent setup throws a lot of "error loading patch xxxx.PAT"

dartfrog wrote on 2025-07-24, 09:26:

No biggie. We will get it soon. My wife is really pushing me now to finish it after seeing it being recognized in WinXP. Guess t […]
Show full quote

myne wrote on 2025-07-24, 07:26:

Bummer. […]
Show full quote

Bummer.

If you can confirm it's a 1:1 perfect a/b swap:

Wouldn't it be correct if the slot was on the back?
I'm not loving the chance of no other fallout.

https://upload.wikimedia.org/wikipedia/common … SA_Bus_pins.svg

It looks like the data/address lines on the gus would get the brunt of it, but who knows where it was trying to earth

No biggie. We will get it soon. My wife is really pushing me now to finish it after seeing it being recognized in WinXP. Guess this is a full time project job now.

Yeah it's a perfect A/B swap, and you're right it would work on the back. Great idea! You saved me a bunch of soldering.
Well, there's only one way to find out, and we'll just keep fixing things until there's nothing left to fix!

For the GUS I believe the ISA8888 card sent -/+12v to U1 and earthed through the same chip. Or so I think based on tracing the traces on the GUS, might be wrong on that.

How's it going?

myne wrote on 2025-08-17, 02:16:

How's it going?

I've been a bit busy. BUT I just got done remaking a 2nd PCI to ISA card. First one was blown, and I think the chip was fried as it would work for a few boots but then not work for a few and continue like that. The second card works in windows xp just like the last card, and no issues so far. However I did kill that PicoGUS, even after replacing the blown chip, the PicoGUS isn't allowing the computer to boot. I haven't tried the (blown)PicoGUS in a DOS environment yet. But until I can get a new ISA card to test, all I can do is use windows xp's debug.exe to read and write like:

-o 300 55 ; Write 0x55 -i 300 ; Read it back -o 300 AA ; Write 0xAA -i 300 ; Read it back -o 300 […]
Show full quote

-o 300 55 ; Write 0x55
-i 300 ; Read it back
-o 300 AA ; Write 0xAA
-i 300 ; Read it back
-o 300 00 ; Write 0x00
-i 300 ; Read it back

Now these always returns FF because it's a floating bus, but debug.exe will hang or crash if there is no response from a read, and will crash from failed write. So it is communicating with the OS/debug.exe as far as I know. The fact that you can write to ISA addresses without crashes means the fundamental PCI to ISA bridge functionality is operational. Which is a massively good sign. However we are testing on a Nixsys motherboard right now so that might be giving us false results. I can test on another system soon.

I do have a "kind of working" floppy controller, I know this controller is not working properly or at least it doesn't like my floppy drives on my other actual ISA system. However, with that card plugged into the ISA8888 it does in fact respond to:

Further testing:

-i 3F0 ; Floppy Status Register A and reports back with 00 -i 3F1 ; Floppy Status Register B and reports ba […]
Show full quote

-i 3F0 ; Floppy Status Register A
and reports back with 00
-i 3F1 ; Floppy Status Register B
and reports back with 00
-i 3F2 ; Digital Output Register
and reports back with 00
-i 3F4 ; Main Status Register
and reports back with 00
-i 3F5 ; Data Register
and reports back with 00
-i 3F7 ; Digital Input Register
and reports back with 81

-i 378 ; Parallel port range
and reports back with AA
-i 3F8 ; Serial port range
and reports back with 00

0x81 at 3F7 (Digital Input Register) This is the most telling: 0x81 = 10000001 in binary, Bit 7 = 1: Disk change detected (normal when no drive connected or drive not ready), Bit 0 = 1: High density select enabled, This is a typical reading for a floppy controller without connected/ready drives, 0x00 at other registers. Normal for an uninitialized controller: Controller is in reset/idle state, Hasn't been configured by Windows XP yet, This is likely the expected behavior.

These tests confirms bidirectional communication through the PCI to ISA bridge! So the motherboard is not giving us false positives here!!! (Note: I have the onboard floppy stuff disabled in the BIOS)

DMA testing:

-i 04 ; DMA Ch2 Current Address (low) and reports back with 00 -i 05 ; DMA Ch2 Current Address (high) and reports back with 00 - […]
Show full quote

-i 04 ; DMA Ch2 Current Address (low)
and reports back with 00
-i 05 ; DMA Ch2 Current Address (high)
and reports back with 00
-i 06 ; DMA Ch2 Current Count (low)
and reports back with 00
-i 07 ; DMA Ch2 Current Count (high)
and reports back with 00
-i 81 ; DMA Page Register Ch2
and reports back with 00
-i 82 ; DMA Page Register Ch3
and reports back with 00
-i 08 ; DMA Status Register
and reports back with 00
-i 0A ; DMA Mask Register (should show channel masks)
and reports back with DD
-i 0B ; DMA Mode Register
and reports back with DD
-i 0C ; DMA Clear/Reset
and reports back with DD

This is a massive result and proves DMA controller is working. At least as far as simple address reads. (Manually testing DMA writes here would be a big no no from what I understand.) 0x00 from address/count registers! This means: DMA channels are in idle/reset state, No active transfers configured, which is exactly what you'd expect on an uninitialized system. 0xDD from control registers (0A, 0B, 0C) This is very significant: Getting consistent, specific values (not 0xFF floating bus), 0xDD = 11011101 binary shows the DMA controller is responding, Mask register (0A) = 0xDD: Shows channels 0,2,3 are masked (disabled), channel 1 unmasked, This is a realistic DMA controller state.

Guys we freaking did it. IT WORKS. The DMA reading of 0xDD from control registers is especially convincing since it shows the actual 8237 DMA controller is responding through the bridge. (There is no 8237 controller on this motherboard!) This is actually what I was hiding from you all with the prototype card results a while back, I didn't want to speak on it then. I had to make sure the actual PCB was working too and not just my prototype giving us false positives! I believe the programming of the configuration chip is correct as well, or at least as correct as it can be without further testing. Now I know this isn't the smoking gun proof most of you want like a PicoGUS blasting E1M1 through the bridge, but as far as I know there's nothing really that could go wrong now (knocks on wood). DMA reads is a pretty big smoking gun imo. However I will save up some spare cash and grab another PicoGUS so we can actually test it. (EDIT: Wife just bought one for me this morning.)

Also I will test it inside the other modern motherboards too. Oh and yeah! the PCIe bridge too! Give me a few days on both. Actually since the wife just bought a GUS, I will wait for the GUS for testing on all fronts!

Thx for report but I wouldn't say 'yeah' until done.
That I/O read/writes works is good but it doesn't proof that DMA transfer in memory would really perform as expected. What chipset has the MB you tested on? You say it doesn't have any own legacy DMA. Some pages back you mentioned that some 3xx chipset had some DMA leftover and responded to some adresses. But in this case it seems IO is properly forwarded to the ITE bridge instead onboard PCH so it's good (did you need configure this some way?)
Next there may be some IRQ routing problem. Maybe you could use your FDC to generate some IRQ and see if it pass...

Good to hear about the progress.
Fingers crossed

RayeR wrote on 2025-08-21, 12:09:

Thx for report but I wouldn't say 'yeah' until done.
That I/O read/writes works is good but it doesn't proof that DMA transfer in memory would really perform as expected. What chipset has the MB you tested on? You say it doesn't have any own legacy DMA. Some pages back you mentioned that some 3xx chipset had some DMA leftover and responded to some adresses. But in this case it seems IO is properly forwarded to the ITE bridge instead onboard PCH so it's good (did you need configure this some way?)
Next there may be some IRQ routing problem. Maybe you could use your FDC to generate some IRQ and see if it pass...

Oh of course, I just meant that It works in the sense we could talk to the card, as debug.exe would give nonsensical results/crash/hang without the PCI to ISA bridge card plugged in.

I don't remember the nixsys chipset offhand, I can't find any information on the nixsys board since it's a very old nixsys pc, I'll have to investigate further, i may have mentioned it in a previous post but i forgot what it was if I did. But since debug was giving nonsensical results/crash/hang, I'm assuming it's not there. Maybe I'm misguided here. Oh yeah that's a good point with the reference to the 3xx chipset stuff. No configuration of any kind was needed.

Ah that's an interesting test with the FDC. I think I can do that with debug.exe. (Leaving tests here to comeback to, so i don't forget)

Tests todo:

Monitor IRQ in XP by Device Manager->View->Resources by type->Interrupt request, then test below. […]
Show full quote

Monitor IRQ in XP by Device Manager->View->Resources by type->Interrupt request, then test below.

The reset sequence often generates an interrupt when the controller comes out of reset.
Reset FDC, Release Reset + enable DMA, Check main register status.

-o 3F2 00 ; Reset controller (clear bit 2)
-o 3F2 0C ; Release reset + enable DMA
-i 3F4 ; Check main status register

Motor enable changes can trigger interrupts even with no drive.
Enable motor for non-existent drive:

-o 3F2 1C ; Enable motor A + DMA + no reset
-o 3F2 2C ; Enable motor B + DMA + no reset

Issue FDC Commands
Send commands that will immediately fail/complete:

-o 3F5 08 ; "Sense Interrupt Status" command -i 3F5 ; Read result (might trigger interrupt) Or try: -o 3F5 0 […]
Show full quote

-o 3F5 08 ; "Sense Interrupt Status" command
-i 3F5 ; Read result (might trigger interrupt)
Or try:
-o 3F5 07 ; "Recalibrate" command
-o 3F5 00 ; Drive 0 parameter

Instead of manually triggering interrupts, try:

copy con: a:

~

The main things now that will have to be done is since I'm trying to target windows xp as a baseline, a WDM driver for the GUS will need to be developed. In addition, the WDM driver will need to do several things to accomplish the pci transaction stuff. I have source code for a WDM GUS driver (Gravis UltraSound WDM Driver Project: https://popelka.ms.mff.cuni.cz/~stoupa/gus/), I studied it for a bit and mapped out a pathway, but there's quite a bit that would have to be done still. Although the main parts of the WDM GUS driver, is kind of done, all I need to do is really slap in the bridge card stuff and it should theoretically work. Finally my PCI isolation card with dump switch will come in handy, haha!

• Address Alignment: Ensure ITE8888 I/O decode ranges exactly match PicoGUS requirements
• Timing: Configure appropriate ISA bus timing for reliable PicoGUS communication
• DMA Setup: Properly configure DDMA channels for audio streaming
• Error Handling: Implement proper fallback if bridge configuration fails
• Resource Conflicts: Ensure no conflicts with other ISA devices on the bridge (since the card's single slot could be expanded via ISA bus extender)

Full List of Driver Stuff

[…]
Show full quote

• Driver must find the ITE8888F bridge first
• Basic ITE8888 Bridge Config
• ISA Address Space Config
• Config ITE8888 I/O Decode Spaces
• Memory Space Config
• DMA and Interrupt Config
• Config DDMA Channels
• Config Serial IRQ
• ISA Bus Timing Config
• Enable Delayed Transactions
• Bridge Address Mapping Table
• Update Driver's Address Translation
• PicoGUS Detection/Validation
• Detect PicoGUS Specifics
• Register Resource Allocation
• Enable Bridge Operation

EDIT: Today I made some large headway on the WDM GUS driver modification. Not compiled yet, but the ITE8888 code is turning out to be a lot less code than I was anticipating.

I have been making all my additions detection based. If the driver detects the bridge card, it will use an ITE8888 PCI transactional pathway, if it doesn't it will use the driver's original ISA pathway. This way if I or anyone else who modifies it makes strides in adding missing features to the driver for GUS, It would support both bridged and non-bridged GUSes. Building it this way, in the future I or someone can strip out the GUS stuff, leaving the dual pathway driver shell so they can take that driver shell and build a desired driver on top of it. Anyways hope you're all doing well.

~

EDIT 2: It might actually be possible to "sandbox" already compiled drivers through like a I/O virtualization and redirection layer. I will research this as it would be WAY better to support already developed drivers. Instead of developing drivers from scratch. I can think of 5 ways this might be possible., there are probably more ways, but I can't think of any. Manual Filter Driver with I/O Interception (Difficult and Risky), System Call Hooking (Aggressive and Unstable), WDM Filter Driver (Cleanest and Recommended), Runtime Binary Patching (Dangerous and Fragile), Hypervisor-Level Interception (Complex and Overkill) I think the WDM Filter Driver is the most valid choice here. Existing as an upper filter driver for GUS I/O redirection, this would be the most likely to work with the least amount of friction. A properly implemented WDM filter driver gives us everything we need with minimal risk. Like I said I'll investigate this further.

Windows WDM filtering cannot intercept direct hardware access. RIP. However, I think this is even better because after messing around. I don't think there is a need a filter driver! I think all that's needed for more than just say GUS/sound cards is a Bridge Configuration Driver. (You don't actually need it since we are programming the configuration on the card itself via an EEPROM) Though with a configuration driver, we can configure the bridge anyway we'd like in OS land, so any existing WDM drivers could work transparently if the driver sets the bridge up correctly. For example a READ_PORT_UCHAR((PUCHAR)0x220) call will:

• Go to chipset as I/O port access
• Get routed to PCI bus
• Be claimed by IT8888F bridge
• Be converted to ISA transaction
• Reach the actual GUS card

Either way (bridge config / hand rolled driver) both still requires the chipset to forward I/O to PCI bus. This is the main point of lots of arguments of it not working. Might be dead for most modern systems, but who knows maybe the chipsec results from 3xx are more telling and they still do it... Need more time to test and validate.

~
Now none of this will help cards with only VxD drivers... Though i've been told there are existing VxD-to-WDM translation layers used in some places. I'm not sure how that works, or if it's even real (though the source of the claim can be trusted). I know Win98 supported both VxD and WDM both natively, but I was told this isn't what they were describing. They were specifically talking about a custom translation layer that encapsulates a VxD and makes it work as if it's a WDM. I'll have to interrogate the source and figure out more. I HIGHLY doubt this is actually true as there are several points of impossibility I can think of, if it does work it's probably a very very minimal VxD translation. As some things like DOS/BIOS calls, V86 mode, VMM service dependencies all in VxD land would be completely impossible in WDM only land.
I was right, it's an extremely minimal translation. Not applicable. RIP cards with no WDM driver.

Meant to post this, then I forgot about it and found the pictures again.

darfrog wrote:

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 BridgEdite. 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.

The card is detected on the Lenovo ThinkCentre M93p connected through that PCE1PCI-A01 PCI-E TO PCI CARD with the ASM1083 chip and is seen as a PCI standard ISA bridge. Windows 10, assigns it a driver automatically and there is no need to assign the device with the ITE8888F.inf driver.

Still can't test anything until I get the new GUS in the mail. (Even though the picture shows that the GUS is in the PCI/ISA Bridge card, it's been confirmed to be not working on an actual ISA motherboard. I added it in to see if the PC would boot with it in and it does!) I will edit this post with the hit and miss FDC and see if that gets recognized.

Edit1:It should be noted that the Q87 chipset doesn't even have Conventional PCI support, so PCI must run through a PCIE bridge. The fact both the PCIE/PCI and PCI/ISA bridges is working is very interesting.

Edit2: SUPER GOOD NEWS I checked it with HWINFO64, and yes bus mastering is configured and useable.

I'd thought that Microsoft had removed ISA bus support from Vista onwards.

Duffman wrote on 2025-08-25, 05:18:

I'd thought that Microsoft had removed ISA bus support from Vista onwards.

AFAIK ISA PnP still exists, but was disabled by default since Vista. It can be enabled manually if desired.

I haven't tested it, however, as the usefulness of ISA hardware on newer Windows versions, especially 64-bit ones, is limited.

dartfrog wrote on 2025-08-24, 23:40:

Edit1:It should be noted that the Q87 chipset doesn't even have Conventional PCI support, so PCI must run through a PCIE bridge. The fact both the PCIE/PCI and PCI/ISA bridges is working is very interesting.

Edit2: SUPER GOOD NEWS I checked it with HWINFO64, and yes bus mastering is configured and useable.

The bridge chip itself has autodetection resource ID, including capabilities of the bridge: this is why the bridge was listed in the Device Manager.
This appearance mean only "device detected and configurable".
The main concern is the decoding of DMA (and other required) I/O ranges, the handling of DMA itself, and IRQ pass-through, specifically how these resources are propagated between the CPU and the bridge.
As I saw with Asus Z87 boards PnP configuration registers address space cannot be decoded to the LPC bridge at all. And this happens in 2014 already.
BTW I would recommend some ESS 688/1688 boards with no(688) or little (1688) configuration. They're both SB Pro from boot A220 I7 D1 and great for testing purposes. The only thing on the 1688 is configurable is the MPU401 address+enable, which isn't required is you have no MPU devices to play.

I'm not sure if it's necessary to mess with windows drivers. I though the target is plain DOS so it's just needed to write small bridge config utility similar to saphisa.exe for dissapointment and with properly configuerd bridge (and maybe interrupt controller) DOS programs should work without any changes...

BTW my Gigabyte GA-P67-DS3-B3 also don't have native PCI support but use PCIe to PCI bridge IT8892E and no problem with it...
I think it doesn't differ much from intel's embedded PCIe2PCI in older chipsets. It supports subtractive decoding.

I think I understand, but just to be clear, we're effectively talking about something like a network route table, yes?

If x address, route to Y switch.

In some cases that is configurable. I believe this is what subtractive decode is referring to. The routing rule as it were.

In others, that router "port" is not configurable and it is therefore impossible for that to work. Possibly because the LPC bus has already taken those "ports" and it isn't possible to route to 2 endpoints.

Am I on the right track?

vsharun wrote on 2025-08-25, 17:30:

The bridge chip itself has autodetection resource ID, including capabilities of the bridge: this is why the bridge was listed in […]
Show full quote

The bridge chip itself has autodetection resource ID, including capabilities of the bridge: this is why the bridge was listed in the Device Manager.
This appearance mean only "device detected and configurable".
The main concern is the decoding of DMA (and other required) I/O ranges, the handling of DMA itself, and IRQ pass-through, specifically how these resources are propagated between the CPU and the bridge.
As I saw with Asus Z87 boards PnP configuration registers address space cannot be decoded to the LPC bridge at all. And this happens in 2014 already.
BTW I would recommend some ESS 688/1688 boards with no(688) or little (1688) configuration. They're both SB Pro from boot A220 I7 D1 and great for testing purposes. The only thing on the 1688 is configurable is the MPU401 address+enable, which isn't required is you have no MPU devices to play.

You're right about autodetection, I should be careful how i represent my tests. This bus mastering check in HWINFO64 was more of a secondary verification of the configuration programming on the EEPROM. Without EEPROM configuration it's in a defaulted state and requires configuration via PCI transactions. When there is no EEPROM, I was able to detect the IT8888 behind the PCIE bridge, but it was detected as a basic bridge on Win10. How I understand it, even though busmaster is enabled by default, the chip still needs configured address spaces (IO and memory regions) to be properly functional and detectable. So I was testing that if I seen "bus master enabled", the EEPROM configuration was working at a baseline level. I'll try to explicitly state my tests intentions from now on. That's my bad.

LSS10999 wrote on 2025-08-25, 05:53:

Duffman wrote on 2025-08-25, 05:18:

I'd thought that Microsoft had removed ISA bus support from Vista onwards.

AFAIK ISA PnP still exists, but was disabled by default since Vista. It can be enabled manually if desired.

I haven't tested it, however, as the usefulness of ISA hardware on newer Windows versions, especially 64-bit ones, is limited.

Yeah it's been removed by default. Either manual enabling it or ISA hardware existing will trigger it being enabled.

The newer windows / x64 tests are more of an "upper bounds" test. Basically seeing what's possible while I wait for the new GUS. There is no reason to use x64 or win10 with ISA. While I'd love for either to work, it's probably a fools errand since there are legitimately no drivers or software for any card I could find. I think Win10 x32 with a WDM driver would be the absolute limit or the "upper bound", since Win11 removed 32 bit.

I should state I have been contacted by a business to look into Win7/Win10 x32 to see what is possible, but this is completely wishful thinking and not an actual target. This is just me having fun with entertaining a company's request while I wait for the new GUS to arrive.

RayeR wrote on 2025-08-25, 18:04:

I'm not sure if it's necessary to mess with windows drivers. I though the target is plain DOS so it's just needed to write small bridge config utility similar to saphisa.exe for dissapointment and with properly configuerd bridge (and maybe interrupt controller) DOS programs should work without any changes...

BTW my Gigabyte GA-P67-DS3-B3 also don't have native PCI support but use PCIe to PCI bridge IT8892E and no problem with it...
I think it doesn't differ much from intel's embedded PCIe2PCI in older chipsets. It supports subtractive decoding.

Yes, you're correct, there would be no need for any driver manipulation. Plain DOS is the main target, and likely automagically support up to WinXP since it still has precompiled WDM drivers for some cards and still has some limited DOS compatibility (NTVDM - NT Virtual DOS Machine). It's very likely DOS would work out of the box with the proper bridge configuration.

• My support target is DOS to Win98 (VxD) with a full bridge configuration utility and EEPROM programmer.
• A secondary goal is WinXP (WDM) support.
• A third goal is DOSBOX potentially interacting with real ISA devices.

Though the two extra goals might be too much trouble for what they are worth. They would mainly be for internet points and bragging rights.

~

FWIW the EEPROM really only needs to be configured enough to enable detection on the software level on some hardware so that a configuration utility can see it. If your hardware and software can see it without the EEPROM config, then the EEPROM is unneeded. Though, a properly configured EEPROM will configure the card at boot, which might be needed for some kinds of hardware/software. So it seems important enough to complete that in the main target.

I'll reiterate what someone said, just because it works enough to be seen, doesn't mean it works enough to work.
Getting it to be seen is the "saddle"/middle of the mountain.
Getting it to work enough to work, is where the "summit"/top of the mountain is.

myne wrote on 2025-08-26, 03:12:

I think I understand, but just to be clear, we're effectively talking about something like a network route table, yes? […]
Show full quote

I think I understand, but just to be clear, we're effectively talking about something like a network route table, yes?

If x address, route to Y switch.

In some cases that is configurable. I believe this is what subtractive decode is referring to. The routing rule as it were.

In others, that router "port" is not configurable and it is therefore impossible for that to work. Possibly because the LPC bus has already taken those "ports" and it isn't possible to route to 2 endpoints.

Am I on the right track?

Yes. It's about routing and no, it is not something which is open to configuration.
Imagine this:
This code executed within the CPU:
out 226,al
Then somehow content of AL register get passed to the port 226 using routing, to reach it's intended listener. Is it in software (SMM/ME) ? Is it in hardware (motherboard traces)? In modern systems - mixed bag, both.
Under hardware I mean physical connection between CPU (socket) and (Intel) PCH, or, in case of AMD where LPC bus embedded into the CPU - directly to the LPC header in case where intended port routing configured 226 nexthop is the LPC.
It is configurable somehow both Intel and AMD and hidden under NDA or, worse - AGESA (AMD Generic Encapsulated Software Architecture)

AGESA is considered proprietary and falls under AMD’s corporate secrets and intellectual property.
Intel SMM code → proprietary reference, distributed under NDA to firmware vendors.
Intel ME firmware → pure corporate secret, only distributed as binary blobs, with no source access outside Intel.
^^^^ All the answers we need are here

I wouldn't mix SMM/ME to this (but yes, in some case it is possible IO port trapping in SMM to emulate some legacy stuff like port 64h of keyboard via USB HID).
For simplicity, there are various bridges on the path from CPU to ISA device (on modern system multiple ones), e.g. CPU2PCIE -> PCIE2PCI -> PCI2LPC/ISA. Every bridge can be configured to positive decode some IO windows (IO addres ranges) that are passed through to other side or not or can have subtractive decode that pass all IO address that are not claimed by some other devices on the bus. Problem is that generally bridges has limited number of configurable IO windows with some additional conditions like address alignment/granularity/minimum range... and there can be only one bridge with subtractive decode in the system (multiple ones would cause conflict as it couldn't be decided to which one pass the IO transaction). So this bridges routing capabilities may not be flexible enough for our purpose. As some legacy devices (timer, interrupt ctl, KBD...) are still in PCH and it's needed to pass IO transaction to them while we have our ISA bridge that needs to pass some other IO ranges (like for DMA controller, SB ports, PnP ports) so sometimes it may be impossible to split this 2 paths for onboard legacy devices and our ISA device. In a case where PCH wouldn't contain ANY legacy device it could then simple use one subtractive decode for all legacy ports to our device which would handle/emulate all that legacy devices (like times, interrupt ctl, etc...).