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 Yesterday, 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 Yesterday, 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.
