UPDATE: I've found a solution using GRUB4DOS and FreeDOS, so now I have my Sound Blaster 16 working with Windows NT 3.51 as an example.

Simply put, make a GRUB4DOS configuration file (menu.lst) for chainloading the OSes you want, and then create a FreeDOS boot entry in FDCONFIG.SYS that runs RUBYISA, the sound card's configration utility (if necessary), and then GRUB4DOS with the configuration file you just created, to boot to the OS you want, and the sound card will be usable there.

NOTE: To avoid issues, the FreeDOS boot entry for GRUB4DOS should not contain other operations.
NOTE 2: So far I only managed to boot FreeDOS kernel and NTLDR directly with GRUB4DOS. I could not get other DOS kernels (such as MS-DOS) to boot and this is on GRUB4DOS 0.4.6a (2022-09-15).
NOTE 3: Existing I/O port range limitations will still apply so no WSS and Sound Blaster AWE32/64 support.

Hi, My friend help me re-write Tiido's rubyisa program in C, and I embedded it into syslinux bootloader to get dma io-ports forwarded on every boot-up.

Attached is source code, I think it's possible to jam this code into grub or some other bootloarders if you would like to do.

ackmangogo wrote on 2022-12-26, 04:15:

Hi, My friend help me re-write Tiido's rubyisa program in C, and I embedded it into syslinux bootloader to get dma io-ports forwarded on every boot-up.

Attached is source code, I think it's possible to jam this code into grub or some other bootloarders if you would like to do.

Nice job. Given you already managed to get it embedded into syslinux, I think it should theoretically be possible to build this into any bootloader so you get accesses to these I/O ports as early as possible.

A long time ago I did manage to replicate the RUBYISA functionality using Borland C++ 3.1 as it does have support for inline assembly and basic I/O. However, BC had no native support for 32-bit assembly operations so I had to manually write down the corresponding opcodes with "db" and put them into a dedicated function. The program will then execute the opcodes as a whole without issues, and everything worked as intended.

It was done mainly to simplify experiment with different I/O ranges as I was trying to use an AWE64 Gold on that board. Eventually I scrapped the idea as the chipset limitations means there's simply no way to use FM with that card. You need the following four ranges configured to let EMU8000 initialized: 0x200-0x2FF, 0x600-0x6FF, 0xA00-0xAFF, 0xE00-0xEFF. Given you can only configure four sets of address ranges, there's no way to configure 0x300-0x3FF ranges after these.

With the default address ranges, the card is detected as a SB16, but FM will not work as it needs EMU8000 initialized. With the correct address ranges for EMU8000, it will be initialized correctly, and all functionalities (including FM) passes in DIAGNOSE, but there's no way to let games access FM as games expect it be at 0x388. I think DIAGNOSE actually accessed the FM via SB I/O ranges (0x220) so internally it worked.

Aside from a SBPro/16 compatible sound card (preferably with a MIDI daughterboard), I think a GUS should also work on this board as from what I know it's still within Sound Blaster's I/O ranges. Unfortunately I never owned a real GUS to test it myself...

Thanks for sharing your experience about awe64 card.

Btw, is there any clue to get rid of wss port limitation on Windows Xp as my original post?

You mentioned four ranges could be configured , if possible to configure 0x200-0x2FF, 0x300-0x3FF, 0x500-0x5FF, 0xA00-0xAFF, that make wss sound card works?

Would it be possible to repurpose one/all of the other Decoder Mask / Decoder Address registers , the ones for KBC RTC MC IOH ?

Aside from having a specific name in the datasheet, I do not immediately see anything that would prohibit their use for other address ranges.
That would add four more ranges that could be assigned to an ISA card.

ackmangogo wrote on 2022-12-26, 08:23:

Thanks for sharing your experience about awe64 card.

Btw, is there any clue to get rid of wss port limitation on Windows Xp as my original post?

You mentioned four ranges could be configured , if possible to configure 0x200-0x2FF, 0x300-0x3FF, 0x500-0x5FF, 0xA00-0xAFF, that make wss sound card works?

You can't just assign the whole 0x300-0x3FF range as there are something critical in between that would stop working if configured this way. Namely parallel and serial ports, even VGA-related stuffs.

The 0xA00-0xAFF range was said to be used for PnP-related stuffs, but if your card is not PnP and do not really interact with that address range, you may try excluding it. I'm not an expert in this, though.

As for your original post... Maybe you need to change the driver (as well as the game side) to somehow accept an arbitrary address range for WSS other than the standard ones, similar to how SETYMF permitted WSS to be set at 0xA20.

EDIT: You can simply repurpose the 0x300-0x33F range for WSS (0x500-0x5FF or 0x600-0x6FF) if you don't have a MIDI daughterboard, as without a MIDI daughterboard (or an external device), it's useless keeping that port forwarded, as you wouldn't get any MIDI output at all, not to mention there are many better alternatives on Windows.

weedeewee wrote on 2022-12-26, 08:42:

Would it be possible to repurpose one/all of the other Decoder Mask / Decoder Address registers , the ones for KBC RTC MC IOH ?

Aside from having a specific name in the datasheet, I do not immediately see anything that would prohibit their use for other address ranges.
That would add four more ranges that could be assigned to an ISA card.

Interesting find. From the Fintek side these registers do appear general-purpose, but the ICH7 side doesn't appear to make them that way. From the ICH7 datasheet decoding of these parts (such as KBC, MC) were controlled by respective bits in LPC_EN register (the address ranges are hardcoded), and there's a specific section for RTC-related registers. I couldn't find any mention about IOH on the ICH7 side, though.