VOGONS


First post, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie

For a while I've kept the view that AMD motherboards have no legacy audio capabilities at all, as in most cases TSRs can load but programs still cannot detect Sound Blaster. But recently something new regarding the chipsets were discovered.

While discussing about PCIe-to-PCI, PCI-to-ISA related stuffs, Doomn00b discovered something very interesting to look at. Originally I posted some additional stuffs I've found regarding the chipsets there after some checking and testing, I decided to put up a new thread regarding the discoveries.

The AMD 700 series southbridge register reference guide mentioned some chipset registers that would enable to allow legacy audio I/O addresses (MIDI, Adlib, SB/GUS/WSS) to trigger SMI# (see page 171). The same, identical chipset registers are also present in the previous 600 series (page 147). A little further checking of the publicly released AMD tech docs found that the registers are also present in the SP5100 southbridge used on SR5670/SR5690 server motherboards (page 174).

The registers in question are only available up to 700 series. On 800 series the registers were removed (reserved, see page 147). It's likely the 900 series did the same, but the register reference guide for 900 series is yet to be publicly released.

This is just a possibility as I'm yet to understand how it's supposed to work... I don't think there'd be any examples as no known boards of those chipsets ever made use of those triggers (or have implemented the handlers) as far as I know. Given the privilege level of the system management mode, I think the handler might need to reside in a BIOS module.

It seems to enable the possibility to emulate legacy audio through system management mode handlers on those chipsets, similar to the VSA (or see here), using those specialized SMI# triggers. To which extent those registers' usefulness are for getting legacy audio on those chipsets are yet to be known.

Last edited by LSS10999 on 2020-04-30, 06:05. Edited 1 time in total.

Reply 2 of 4, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie

Native PCI I/O does work on those chipsets. Onboard AC97/HD audio or supported cards like Sound Blaster Live! can still be natively picked up by MPXPlay and audio worked. I currently have a test environment based on M5A78L/USB3 (this 760G/SB710 based board can support Vishera processors up to 8350).

I also have an ES1370-based AudioPCI card but it didn't work with either APINIT driver or MPXPlay (natively). The ES1370 is not AC97-complaint (only ES1371 and ES1373 are), so maybe a different version of the TSR might be needed. But still, according to HWiNFO the audio card was indeed present in the system.

I think I'll give PCI.EXE a try when I have time, as I'm still figuring out how to fiddle the PCI registers to see what would happen if I enable the bits that allow legacy audio I/O addresses to trigger SMI#.

And I'm not sure if the stuffs mentioned in your post (such as REMAPCMI) could be made usable for FreeDOS/JEMM386 as the proprietary "port-trapping" technology (that were used by stuffs like SoftMPU) never got out of MS(LIM) EMM386 (but MS EMM386 is not as compatible with very large amount of RAM). I'm now mainly using FreeDOS as I'm not confident about MS-DOS 7.10's compatibility with very large hard disks (up to 2TB, I actually mean the possibility of corruption when writing past the old barriers such as the 137GB ones), despite that programs crash less often when running on MS-DOS.

Reply 4 of 4, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie
Kamerat wrote:

I think HimemX works together with EMM386 and then you can use the /MAX=##### switch to limit available RAM before loading EMM386.

I think I can use any extended memory manager as long as it works. It's just whether or not other DOS kernels (especially FreeDOS) could correctly make use of MS EMM386 and its proprietary port trapping technologies. Some EMM386-dependent apps (such as AudioPCI/SBLive drivers, SoftMPU) seem to rely on that technology.