RayeR wrote on 2025-08-26, 16:01:

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

I would. SMM can easily trap port for no obvious reason.
BTW I heard that CHIPSEC has functionality of SMM traps dump via BIOS dump, or may check which ports within given range are trapped using performance counters: trapped port will generate SMI which a) leaves traces in SMI counter and b) has different (significantly higher) execution time.

Ok, yes, do we have some evidence that SMI handler traps some IOs that are required for ISA functionality? Even if yes it would be hard to do something with it coz SMI handler is usually protected against modding after boot. Yo'd have to patch bios image offline and flash it...

I just finished the outlines for a ite8888 config tool for NT/2k/XP and 95/98/ME. It has 2 compatibility layers and checks what version of Windows. The NT/2k/XP layer uses WinIO, where the 95/98/ME layer uses direct hardware access. It uses dynamic WinIo function process to avoid compiling/linking with WinIo as that can be problematic sometimes. I have only tested it on XP compiled with VisualStudio2010 as of the moment, I just bought some more 256 GB SSDs to install other OSes on so I can just swap the HD to test it on various OS.

• The configuration tool correctly detects OS and finds the ITE8888 bridge.
• It's able to scan and display the current configuration.
• It's able to accept a manual configuration via CLI (command line interface).
• It can set the ITE8888 configuration via preconfigured (hardcoded configurations in source code).
• It can load configurations from a CFG file and apply it to the bridge.
• Reset the bridge to it's default state.
• Created GUS.cfg, SoundBlaster.cfg, FDC.cfg, NE2000.cfg, SCSI.cfg, Serial.cfg

(The picture shows the tool + some example usage, initial load, showing system info, and displaying current configuration.)

I still have yet to detect the new PicoGUS behind the bridge, but atm I'm subtractive decoding, not positively decoding. So that might be one problem.

I also wrote some separate DOS code for the DOS tool, but i need to setup a DOS C compiler/editor and that's a whole can of worms in itself. I might be able to compile the DOS tool on XP with OpenWatcom so I don't need to mess with DOS compilation as I'd rather not relearn it haha, my brain has largely forgot everything needed in DOS for C compiling 🤣. In any case I'm trucking along at a steady pace!

Anyways, hope you're all doing well.

dartfrog wrote on 2025-08-29, 09:42:

i need to setup a DOS C compiler/editor and that's a whole can of worms in itself.

Under Windows 11 WSL2/Ubuntu is the perfect tool to install and compile DOS apps with both OW and DJGPP.

I usually compile my DOS tools with DJGPP running under WinXP (NTVDM DOS window) or under plain DOS if necessary.
There are also DJGPP crosscompilers for various host OSes: https://github.com/andrewwutw/build-djgpp/releases

Thanks both of you. I went with OpenWatcom on XP for DOS compiling (as I'm already compiling here so why not) and im more familiar with it than DJGPP. But i will have to checkout DJGPP sometime, it looks interesting, and thanks I didn't know of this! I did manage to get the DOS version compiled. I'm just waiting for the new SSDs to arrive today so I can do some dedicated testing on the various apps.

Over the night, I wrote a ISA card detection utility for 95/98/ME/NT/2K/XP, so you can verify your non-PnP ISA card exists behind the bridge. It does require you to configure the bridge chip with positive decode/io forwarding before detecting. I need to add positive decode / io forwarding to the configs as it's all setup for subtractive decoding atm. (was simpler to just leave positive / io forwarding out for the time being till I got the config tool mostly working. now I can go back and add them in). I did detect the flaky FDC card though, so that's interesting!

Interestingly, the detection tool is causing the PicoGUS to turn off when detected and it's causing the PicoGUS to not be found. Sometimes the PicoGUS will reboot itself, other times it will just stay off. If it stays off, you have to do a hard reboot before the card turns back on. I did figure out it's not the bridge getting messed up causing the PicoGUS to turn off, it's the PicoGUS itself. I'll have to go read the PicoGUS code to checkout how they are detecting/configuring the card.

FWIW, I would have assumed XP could detect ISA GUS/PicoGUS automatically as I could have sworn I remember back in the day that happening, but maybe I'm misremembering and it was an ISA SoundBlaster getting detected automatically on XP not a GUS. (My brother had a GUS and I had a SB). Anyways I'll get it sorted soon.

@dartfrog

There are definitely XP drivers for Soundblaster 16/AWE32 but I don't think there ever were XP drivers for GUS as Gravis were gone by the time XP was released.

dartfrog wrote on 2025-08-30, 10:03:

Over the night, I wrote a ISA card detection utility for 95/98/ME/NT/2K/XP, so you can verify your non-PnP ISA card exists behind the bridge.

If you have DOS configuration utility for the bridge(s) then you'll free to go with the DOS's debug.
With non PnP cards like the ess688/1688 or PicoGUS in SB mode there's simple commands to check I/O pass-through like reset SB's DSP and check the result via simple OUT/IN two step only sequence.

Can't the picogus emulate sb16 and other devices?

myne wrote on Yesterday, 01:59:

Can't the picogus emulate sb16 and other devices?

SB16 not, only SB 2.0.

Ok. Well it should be testable with that config.
Potentially all the other pi options too - like lan which presumably uses dma.