What a random thing to worry about

dartfrog wrote on 2025-09-16, 06:20:

Windows, specifically XP.

XP (and NT in general) blocks majority of IO port accesses, you need something like a program called Userport to unlock access to ports you want to deal with, without having to write a kernel mode thing to get that access.

I believe I figured out the problem! It's the Nixsys board. Well not exactly, more like LPC, but here is what I proved via systematic testing.

Basically there are two separate ISA paths if a system has LPC, in my case:
Path 1: Intel 82801EB LPC Controller (24D0) -> Native ISA/LPC -> ISAPNP Read Data Port
Path 2: Intel 82801 PCI Bridge (244E) -> ITE8888 -> Addon ISA slots

Hardware Expectation:
The hardware and XP is expecting ALL ISA devices to be enumerated through the LPC controller's ISAPNP mechanism. It looks for ISA Plug and Play devices via the standard ISAPNP Read Data Port (0x279/0xA79). This port is controlled by the LPC interface (24D0), not the PCI bridge path (244E). These two ISA domains don't communicate. I'm not sure it's even possible to force them via manipulation either, though I would love to be proven wrong on that.

Debug port probing works because it's direct communication, which implies that DOS/Win98 will work. Will test DOS asap. (have to modify and recompile the southbridge configuration code for DOS). This Nixsys board (presumably all boards with similar modern legacy configuration (LPC) will likely have similar results) and will probably only work with PC/PCI PPDMA LPC via PPDGNT and PPDREQ. If it works at all. I'll have to test that, though this is highly unlikely that will solve the XP enumeration problem. (I'll have to look for PPDGNT and PPDREQ on this board, there isn't a TPM header.) The issue isn't DMA routing but rather the expectation that ISA devices appear in the system's device tree through the LPC controller. Now it would be possible to develop drivers specifically for this setup, but that means a card by card setup and is undesirable. Again, I'd love to be proven wrong that you could manipulate the LPC controller to talk to the PCI Bridge.

All this means, it might not be possible to have a plug and play ISA BUS addon card for OS like XP if your system has a LPC/PCI BUS that have different device IDs. I'm unsure if this is true for all LPC, like are there chipsets with PCI bridges on/behind the 82801EB LPC interface controller? I think some of you even commented on that, but I had to try everything I could. I had to do a systematic investigation to reveal a genuine architectural limitation rather than it being a configuration issue. There was a method to the madness, even though i was largely throwing crap at a wall.

I will also do more testing on the modern non LPC system I have (Lenovo) with that extra PCIe bridge while I wait for the Dell to arrive. (The Dell will probably be similar to Nixsys board since ICH10 has LPC also). The PCIe now has more promise because there is no LPC in the way. Though I will probably need to make a PCIe configuration tool to ensure it's setup correctly.

I could be wrong on this post, but I have tested the kitchen sink of things and could only make communication via direct access, leading credence to DOS/Win98 working.

~

rasteri wrote on 2025-09-16, 06:56:

You could set up DOS networking and compile on another PC. Even a modern one.

I toyed with the idea, but I couldn't remember how to do that, I haven't done DOS networking in many many moons. I just need to host an FTP locally and connect/download the files right? What I would do for a simple git client on dos 🤣.

RayeR wrote on 2025-09-16, 20:08:

So you are saying that you tested all involved SB port IO addresses via POST card (with configurable address decoder) and it pas […]
Show full quote

So you are saying that you tested all involved SB port IO addresses via POST card (with configurable address decoder) and it passed data do display but SB detection tools fails? I think for basic detection IRQ/DMA is not needed, just an IO transactions, strange... are you testing still with PicoGUS or with some real old soundcard? Maybe some old nonPNP SB16 or so would be the best...

Also I would recommend to do tests under pure DOS to avoid some interference with windows multitasking environment...
As it was told before, you can compile in DOS env. both by DJGPP or Watcom, no need waste time with reboots or even swapping HDDs...
For basic IO programming even some old Borland C compiler with textmode IDE would do the job...

No, just that the ISA slot is working by showing valid POST codes and showing basic IO working via debug with -0 80, not SB stuff. I think I misspoke here, sorry. But yeah SB detection fails. I believe the cause is above. I've been using a PNP Sound Blaster 16 Vibra16XV, 16bit isa (CT4170), I know this card isn't the best as it's PNP and it's even a hassle on normal hardware. I have a PicoGUS on the ready, I just stopped using it because I could replace the SB for half the price if I exploded it in a blaze of glory like the previous PicoGUS. I've been trying to find a non-PNP ISA SoundBlaster, or really any non-PNP ISA sound card to test with that have drivers but they are kind of rare for some reason? Maybe I suck at searching for them.

I'm setting up DOS to compile the code. I just hate not having a decent text editor. I mean most of my tools so far have been around 1K+ lines and working in DOS to write code / change stuff at that scale is honestly well left to history imo. It's something I never wanted to go back to. But I will do it.

myne wrote on 2025-09-17, 04:25:

Wouldn't it be easier to test in the halfway house that is windows 98?

Full, uncompromised dos, 100% driver support, and presumably a compiler/ide like visual studio 2005 that isn't too far behind feature wise or so unfamiliar that it is a learning curve just to get comfortable.

Maybe. Yeah, it's a solid idea. If writing/changing the code in DOS pains me too much, I have a 98SE HD with dev tools already setup.

Tiido wrote on 2025-09-17, 14:59:

XP (and NT in general) blocks majority of IO port accesses, you need something like a program called Userport to unlock access to ports you want to deal with, without having to write a kernel mode thing to get that access.

Hmm, UserPort makes the SB DSP signal communication fail. That's weird. I wonder if UserPort causes timing issues. The DSP reset and DSP read is pretty intolerant from what I understand.

dartfrog wrote on 2025-09-17, 23:22:

I believe I figured out the problem! It's the Nixsys board. Well not exactly, more like LPC, but here is what I proved via syste […]
Show full quote

I believe I figured out the problem! It's the Nixsys board. Well not exactly, more like LPC, but here is what I proved via systematic testing.

Basically there are two separate ISA paths if a system has LPC, in my case:
Path 1: Intel 82801EB LPC Controller (24D0) -> Native ISA/LPC -> ISAPNP Read Data Port
Path 2: Intel 82801 PCI Bridge (244E) -> ITE8888 -> Addon ISA slots

Hardware Expectation:
The hardware and XP is expecting ALL ISA devices to be enumerated through the LPC controller's ISAPNP mechanism. It looks for ISA Plug and Play devices via the standard ISAPNP Read Data Port (0x279/0xA79). This port is controlled by the LPC interface (24D0), not the PCI bridge path (244E). These two ISA domains don't communicate. I'm not sure it's even possible to force them via manipulation either, though I would love to be proven wrong on that.

Debug port probing works because it's direct communication, which implies that DOS/Win98 will work. Will test DOS asap. (have to modify and recompile the southbridge configuration code for DOS). This Nixsys board (presumably all boards with similar modern legacy configuration (LPC) will likely have similar results) and will probably only work with PC/PCI PPDMA LPC via PPDGNT and PPDREQ. If it works at all. I'll have to test that, though this is highly unlikely that will solve the XP enumeration problem. (I'll have to look for PPDGNT and PPDREQ on this board, there isn't a TPM header.) The issue isn't DMA routing but rather the expectation that ISA devices appear in the system's device tree through the LPC controller. Now it would be possible to develop drivers specifically for this setup, but that means a card by card setup and is undesirable. Again, I'd love to be proven wrong that you could manipulate the LPC controller to talk to the PCI Bridge.

All this means, it might not be possible to have a plug and play ISA BUS addon card for OS like XP if your system has a LPC/PCI BUS that have different device IDs. I'm unsure if this is true for all LPC, like are there chipsets with PCI bridges on/behind the 82801EB LPC interface controller? I think some of you even commented on that, but I had to try everything I could. I had to do a systematic investigation to reveal a genuine architectural limitation rather than it being a configuration issue. There was a method to the madness, even though i was largely throwing crap at a wall.

I will also do more testing on the modern non LPC system I have (Lenovo) with that extra PCIe bridge while I wait for the Dell to arrive. (The Dell will probably be similar to Nixsys board since ICH10 has LPC also). The PCIe now has more promise because there is no LPC in the way. Though I will probably need to make a PCIe configuration tool to ensure it's setup correctly.

I could be wrong on this post, but I have tested the kitchen sink of things and could only make communication via direct access, leading credence to DOS/Win98 working.

So the Nixsys board is ICH5 (82801EB). There are several industrial boards based on ICH5 with fully functional ISA slots via PCI-ISA and can probably be referred to.

On my ANOVO AIMB-865 I currently have a CMI8330 and PicoGUS 1.2 installed. Both are fully operational, taking up a total of four IRQs and DMA channels as well as several I/O ranges. CMI8330 is responsible for SB16, WSS and MIDI whereas PicoGUS handles GUS exclusively.

A caveat for that board, however, is that I need to manually fiddle the register 90h-91h of the LPC controller (D31:F0) to route the DMAs used by the sound card to PC/PCI, because its BIOS doesn't do it and routed everything to LPC by default.

Maybe you can refer to the ICH5 datasheet for some more info. The LPC controller in ICH5 and before differs a lot from the one in ICH6 and onwards (including PCH), as it contained stuffs relevant for PCI-ISA bridges, that were removed since ICH6.

IIRC the register D0h-D3h of the LPC controller has a bit to hide the ISA bridge so normally the system won't be able to interact with the actual bridge directly (be it ITE or Winbond). The use of this bit requires special wiring on the motherboard (ICH5's PCI AD22 to the PCI-ISA bridge's IDSEL), so it may not be relevant to your experiment.

You may be able to disable dma, and other things on the lpc.
You may even be able to disable the bridge in device manager in xp. Afik the bios access is transparent and doesn't need a driver.
This is effectively all your using it for.

That may reset the routing expectations as it were.

LSS10999 wrote on 2025-09-18, 01:51:

So the Nixsys board is ICH5 (82801EB). There are several industrial boards based on ICH5 with fully functional ISA slots via PCI […]
Show full quote

So the Nixsys board is ICH5 (82801EB). There are several industrial boards based on ICH5 with fully functional ISA slots via PCI-ISA and can probably be referred to.

On my ANOVO AIMB-865 I currently have a CMI8330 and PicoGUS 1.2 installed. Both are fully operational, taking up a total of four IRQs and DMA channels as well as several I/O ranges. CMI8330 is responsible for SB16, WSS and MIDI whereas PicoGUS handles GUS exclusively.

A caveat for that board, however, is that I need to manually fiddle the register 90h-91h of the LPC controller (D31:F0) to route the DMAs used by the sound card to PC/PCI, because its BIOS doesn't do it and routed everything to LPC by default.

Maybe you can refer to the ICH5 datasheet for some more info. The LPC controller in ICH5 and before differs a lot from the one in ICH6 and onwards (including PCH), as it contained stuffs relevant for PCI-ISA bridges, that were removed since ICH6.

IIRC the register D0h-D3h of the LPC controller has a bit to hide the ISA bridge so normally the system won't be able to interact with the actual bridge directly (be it ITE or Winbond). The use of this bit requires special wiring on the motherboard (ICH5's PCI AD22 to the PCI-ISA bridge's IDSEL), so it may not be relevant to your experiment.

As a last ditch effort, I did make a config tool to do this and I seen no difference. It was a good idea, but I think it's not working in my case, as your bridge being connected on the motherboard itself and to the lpc interface controller and not the PCI bridge. I wonder if I found the ICH5's PCI AD22 and connected that to the PCI-ISA bridge's IDSEL if it would do anything. After re-reviewing some of the links in the thread like that "PCI104: a Case Study" which talked about AD22->IDSEL, this makes much more sense on how the bridge is working. I did find https://web.archive.org/web/20240220220126/ht … 8PCI-to-ISA.pdf which that PDF is telling. The ITE8888 really was designed to be driverless and as a motherboard chip only, makes a lot of sense why no one ever thought about taking this chip and throwing it on a PCI add on card.

myne wrote on 2025-09-18, 03:36:

You may be able to disable dma, and other things on the lpc. You may even be able to disable the bridge in device manager in xp. […]
Show full quote

You may be able to disable dma, and other things on the lpc.
You may even be able to disable the bridge in device manager in xp. Afik the bios access is transparent and doesn't need a driver.
This is effectively all your using it for.

That may reset the routing expectations as it were.

I've tried that, but unfortunately I couldn't get anything to change.

~

I'll be moving all my attention to DOS/98 for now. I really feel as if I have exhausted all my options on NT based OS like XP with PnP on a system with LPC. I do have some hope that it might be possible to manipulate the LPC device in some way through hackery/filter drivers/kernel drivers to allow the 2nd ISA bus to enumerate PnP devices or get drivers to see the cards at all. Also to get XP with PnP to work on a system without LPC, but I think my energy for now is better spent on DOS through 98. If I can verify it works in DOS, then I can worry about the other OSes + tryout the PCIe bridge too. I probably should have started on DOS first, but I guess I was so excited about the idea of XP PnP ISA, that I boneheadedly charged through a ton of pain for no real reason.

~

FWIW, If anyone reading this now or in the future thinks they can get it to work, the repo in my signature has largely always had a bus factor of basically zero (if I got hit by a bus, there would be nothing needed from me to continue the project). All the code, information, schematic, pcb, combined with this thread, allows anyone to reproduce my setup. just figured I'd throw that out there.

dartfrog wrote on 2025-09-19, 07:47:

FWIW, If anyone reading this now or in the future thinks they can get it to work, the repo in my signature has largely always had a bus factor of basically zero (if I got hit by a bus, there would be nothing needed from me to continue the project). All the code, information, schematic, pcb, combined with this thread, allows anyone to reproduce my setup. just figured I'd throw that out there.

I just bought a couple of Socket 478 motherboards. One has an SB-Link port, the other has six PCI slots so logically one of them should have PPDGNT/PPDREQ wired to them.

Is the IT8888 python config tool stiill used in the same way you described here? : Re: dISAppointment - LPC to ISA adapter - ISA on modern motherboards

rasteri wrote on 2025-09-19, 10:41:

I just bought a couple of Socket 478 motherboards. One has an SB-Link port, the other has six PCI slots so logically one of them should have PPDGNT/PPDREQ wired to them.

Is the IT8888 python config tool stiill used in the same way you described here? : Re: dISAppointment - LPC to ISA adapter - ISA on modern motherboards

Yeah, should be. IIRC I added another tool (Binary to C Header Converter - bin2header) about a month ago to forgo the need to use a hexediting tool It will convert the bin to a C file to compile on the Pico. That is if you're going that route. If not you can just use the bin with a programmer.

dartfrog wrote on 2025-09-20, 00:19:

Yeah, should be. IIRC I added another tool (Binary to C Header Converter - bin2header) about a month ago to forgo the need to use a hexediting tool It will convert the bin to a C file to compile on the Pico. That is if you're going that route. If not you can just use the bin with a programmer.

Yeah I programmed a padded version of the file to a 24C04 I had lying around, seems to work!

I'm getting POST codes and I can poke port 80 to get arbitrary values.

Can't get any soundcards to detect, but I just left all the values default in the EEPROM. Maybe doing positive decoding would work better.

Also this motherboard is the one without the SB-LINK port so I might have more luck with the other one.

EDIT : Does the it8888_dos stuff work? That would make testing easier than reprogramming the eeprom each time....

As I mentioned before, there may be conflicts between onboard legacy devices (like timers, IRQ ctrl, RTC... and seems also PnP port) via LPC bridge and ISA devices via ITE bridge. Proper IO decoding settings needed (if possible).

Maybe the whole LPC bridge can be disabled or some parts of it (but then legacy peripherals would be needed handled over ITE bridge).
Maybe better to try with some really new MB/chipset that doesn't contain LPC bridge anymore (replaced by eSPI).
I also suggested to use some postcard with configurable IO decoder (or some ISA bus analyzer) to be able to check all needed IO ranges, not just port 80h...

rasteri wrote on 2025-09-24, 11:56:

EDIT : Does the it8888_dos stuff work? That would make testing easier than reprogramming the eeprom each time....

To answer my own question - no, it just reboots the PC immediately.

I have a watcom environment set up in DOS so I'll have a fiddle

RayeR wrote on 2025-09-24, 14:10:

Maybe the whole LPC bridge can be disabled or some parts of it (but then legacy peripherals would be needed handled over ITE bridge).

The RubyISA/SapphISA/LPCEXP code sets the necessary registers, I believe.

Failing that I have an industrial motherboard with an ICH4 and IT8888 (PCA-6186) that works great with ISA ( www.youtube.com/watch?v=ERMr1Rosq0s ), I bet examining its registers would give some clues

rasteri wrote on 2025-09-24, 15:31:

RayeR wrote on 2025-09-24, 14:10:

Maybe the whole LPC bridge can be disabled or some parts of it (but then legacy peripherals would be needed handled over ITE bridge).

The RubyISA/SapphISA/LPCEXP code sets the necessary registers, I believe.

Failing that I have an industrial motherboard with an ICH4 and IT8888 (PCA-6186) that works great with ISA ( www.youtube.com/watch?v=ERMr1Rosq0s ), I bet examining its registers would give some clues

I had similar problems porting BIOS to a motherboard, which is also ICH4 + it8888.
Just copying ICH4 and it8888 register settings did not work for me, something else's involved.

You may need to "unhide" isa bridge first on PCA-6186, it is a setting on 8086:24cc (LPC bridge), which hides IT8888 from device list and PCI configuration requests.

I think there's one difference, MBs that have ICH5 and older use on chip (ICH's) legacy DMA controller instead of that one in IT8888...
But at least it should be possible to configure it properly for IO routing to get ISA devices working...

rasteri wrote on 2025-09-24, 14:18:

rasteri wrote on 2025-09-24, 11:56:

EDIT : Does the it8888_dos stuff work? That would make testing easier than reprogramming the eeprom each time....

To answer my own question - no, it just reboots the PC immediately.
I have a watcom environment set up in DOS so I'll have a fiddle

Correct, it's broken code. I've done a bit investigating. I'm rereading some of my old DOS programming books and working on it atm. Low level DOS programming is something I did a very long time ago and I'm trying to refigure it out. I'm far more comfortable in the low level 95/98/XP era, so I've been getting confused about 16/32 bit differences.

Should be noted: That it8888_dos code needs a PMODE/W or DOS/4G or DOS32 extension to work because it's using 32bit instructions for configuration. Which is why it reboots on 16 bit DOS. IIRC I think the problem with that uploaded code is mixing 16-bit DOS API calls with 32-bit operations. [int86(0x1A, &regs, &regs);] which should be [int386(0x1A, &regs, &regs);]

I was most recently working in the "PCIe-PCI-ISA/ISA8888_Programs/ite8888" code that has a combined core of DOS/WIN stuff and two separate main files one for DOS and one for WIN, which actually has that fix above in the DOS code, but it's still rebooting. (Could be that I have a problem with my 32bit DOS extension and it works but I have yet to investigate) (If someone is compiling in XP/2003, you'll likely need to change the bat compiling this ite8888 (not ite8888_dos) for watcom to get it to see files, just added another bat file for that DOS_Compile_2003.bat)

I think a pure 16-bit version using only PCI BIOS services would be the best as you can remove the need of a 32bit extender. This is what I'm looking at right now by looking through and rereading DOS books for (PCI BIOS INT 1Ah services). Can't find anything yet, but I might just have another go at programming this anyway as I think I remember enough how to do this. (To avoid confusion, PCI BIOS services and BIOS options are not the same things)

~~~

Basically DOS is 16 bit and PCI configuration cycles are 32bit, and I don't think pci cycles can be broken up into 2 sperate 16 bit cycles. If anyone knows more about PCI configuration cycles and can show they don't need to be a single instruction that would be major, but I think they have to be 32bit. I think you'd have to do a single 32 bit instruction and with PMODE/W or DOS/4G or DOS32 extension OR the pure 16bit with PCI BIOS services because :

PCI Configuration Cycles atomic 32bit operations. So PCI configuration cycles cannot be safely broken into separate 16-bit operations:

• Hardware atomicity requirement - The PCI controller expects complete 32bit transactions to ports 0xCF8/0xCFC
• Bus arbitration issues - Other bus masters could interfere between a split operation
• Configuration address/data relationship - The address register (0xCF8) and data register (0xCFC) must be accessed as a complete transaction

I know f all about this, but I do recall bioses used 32bit instructions for IDE access.

There are old leaks of award bios code from ~y2k that may inspire you - albeit it's all assembly.

dartfrog wrote on 2025-09-29, 01:20:

Basically DOS is 16 bit and PCI configuration cycles are 32bit, and I don't think pci cycles can be broken up into 2 sperate 16 bit cycles. If anyone knows more about PCI configuration cycles and can show they don't need to be a single instruction that would be major, but I think they have to be 32bit. I think you'd have to do a single 32 bit instruction and with PMODE/W or DOS/4G or DOS32 extension OR the pure 16bit with PCI BIOS services because :

PCI configuration cycles are indeed atomic and cannot be split into separate 16-bit cycles. However, it's possible to do 32-bit in/out operations in 16-bit code (real-mode DOS), just that you'll have to write your own routine in assembly for those. I'm using these for my LPCEXP tools.

You can use ".386" directive inside "_asm" blocks with Open Watcom to access 32-bit registers such as EAX in 16-bit.

PS: Before actually knowing about the ".386" directive I used raw opcodes (via "db") to handle operations that would involve EAX. That should work with even older DOS-based compilers which may not have support for such enabling directives. Raw opcodes worked at least with Borland C/C++ 3.1.

LSS10999 wrote on 2025-09-29, 03:19:

PCI configuration cycles are indeed atomic and cannot be split into separate 16-bit cycles. However, it's possible to do 32-bit […]
Show full quote

dartfrog wrote on 2025-09-29, 01:20:

Basically DOS is 16 bit and PCI configuration cycles are 32bit, and I don't think pci cycles can be broken up into 2 sperate 16 bit cycles. If anyone knows more about PCI configuration cycles and can show they don't need to be a single instruction that would be major, but I think they have to be 32bit. I think you'd have to do a single 32 bit instruction and with PMODE/W or DOS/4G or DOS32 extension OR the pure 16bit with PCI BIOS services because :

PCI configuration cycles are indeed atomic and cannot be split into separate 16-bit cycles. However, it's possible to do 32-bit in/out operations in 16-bit code (real-mode DOS), just that you'll have to write your own routine in assembly for those. I'm using these for my LPCEXP tools.

You can use ".386" directive inside "_asm" blocks with Open Watcom to access 32-bit registers such as EAX in 16-bit.

PS: Before actually knowing about the ".386" directive I used raw opcodes (via "db") to handle operations that would involve EAX. That should work with even older DOS-based compilers which may not have support for such enabling directives. Raw opcodes worked at least with Borland C/C++ 3.1.

OH RIGHT! Thank you so much for showing this. Using that .386 directive I can rawdog the assembly without PCI BIOS Services. Perfect! That's great news. Exactly what I was hoping for.

I thought about db and raw opcodes, but I had wrongly assumed it wouldn't work. Thanks for also confirming it would have!

~~~

edit: I've just changed the code in "PCIe-PCI-ISA/ISA8888_Programs/ite8888_dos" and added a compiled exe "ITE8888.EXE" in there, should support the cfgs in the other folder "PCIe-PCI-ISA/ISA8888_Programs/Configs/"
Haven't tested it yet, I will do so in the morning.

Yeah these atomic 32bit port writes are the reason I normally use DJGPP for this stuff, it has an "outportl" function

Few more adapters. Now with SATA power and -12V converter.