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