I am no expert at this (far from it), but my understanding with onboard audio of the era is that you typically have 2 possible scenarios :
a) the motherboard's south bridge contains the audio controller whose features (SB compatibility, AC97 or HDAUDIO interoperability, etc). It will be interfaced to a CODEC chip (which contains DAC and ADC) via either an AC-Link (AC97 codec) or HDAUDIO (HDAUDIO codec)
b) a discrete (separate chip) audio controller whose features (SB compatibility, AC97 or HDAUDIO interoperability, etc). It will be interfaced to a CODEC chip (which contains DAC and ADC) via either an AC-Link (AC97 codec) or HDAUDIO (HDAUDIO codec) is on the motherboard

In scenario b), the southbridge used may contain audio controller functionality, but it will not be used (or be usable) because it will not be logically enabled and, more importantly, it will not connected to an audio CODEC (which makes audio output impossible) .

As for your question regarding PCISet, I will leave that to someone more experienced with manipulating PCI register . But I will guess that you will likely need to calculate the effective address to write to based on the on PCI base address used by the device and the offset mentioned. The default value of that register (assuming it is the same as on the VT712) should be 807Fh (in hexadecimal) or 1000000001111111 in binary, so starting on the right you have bit 0 and on the left you have bit 15, so the value in that register would need to be changed to 0000000001111111 or 007Fh if you just want to set bit 15 to 0 .

EDIT : I may be wrong, but 3059 1106 looks like the PCI device ID of the audio controller on the south bridge, not the one of the VT1720 , which would probably be more like 1724 1412

Hey thanks for the reply. I'm not sure which category I fall into. The block diagram makes it look as though there are separate chips but the EnvyPT24 goes back to the south bridge.

geiger9 wrote on 2021-06-04, 19:12:

Hey thanks for the reply. I'm not sure which category I fall into. The block diagram makes it look as though there are separate chips but the EnvyPT24 goes back to the south bridge.

Spoiler

While I can't find a VIA VT8237R Plus datasheet to confirm, I was under the impression that the VT1720 was always a separate chip (it was used on boards from several manufacturers). That said, I could be wrong and maybe VIA integrated the VT1720's functionality into at least some of the their southbridges .

Would it be possible for you to boot into a Linux live distro, run sudo lspci and post output of the command here ?

Also, as an alternative to PCIset (and possibly lspci under Linux), you may want to have a look at this http://rweverything.com/ (WARNING , site is not https , so may need to copy and paste address into a new browser tab or window rather than click on the link) .

EDIT : Based on this http://static.highspeedbackbone.net/pdf/MachS … M9MP_Manual.pdf , the VT8237R Plus contains a VT1616B controller . Then again, maybe there are VT8237R Plus variants with different audio controllers .

[EDIT] the 1st post totally mislead me - there is no 1720 (Envy24PT) on the "Neoware CA19" thin-client motherboard as far as I can tell from the pictures I found online. So, all I wrote below is valid, but for 1720 (Envy24PT), which I see no where inside "Neoware CA19" - in fact it makes no sense at all to include 1720 (Envy24PT) in a thin-client.
===========================================================

Hi there, 1720 (Envy24PT) completely lacks any DOS support and in fact it's very different than 1712(Envy24) - like 80% of the features of 1712 were removed in 1720, let me just name several of the features that were removed:

1) "36-bit wide digital mixer"
2)"16 streams DirectSound acceleration"
3)"HW SoundBlaster Pro legacy" support - if you wonder what that "Hardware" (HW) in this case means - 1712 supports DDMA (Distributed DMA), that's why its DOS support is not just some software emulation
4) "FM synthesis for DOS legacy" : 1712 has hardware OPL clone, I'm going to comments a little bit about this in the post below
5) supported number of channels were reduced from 20 to 2....
and so on and so on

So, really, those two audio controllers are totally different and in case of 1720 you cannot get DOS support, because it means you need full-blown driver that provides software-emulation for DOS support, which simply doesn't exist and you need to develop it.

Even in case of 1712 utilizing its DOS support is not trivial task at all - you can use PCISET to enable its DDMA (Distributed DMA), i.e. Hardware SB Pro legacy support, but there are a lot of prerequisites you need to have:

A. 1712-based card with AC97 codec on the output channels (those are very rare), because 1712 supports DDMA only with AC97
B. Motherboard with chipset that supports DDMA
C. you still need small software tool that initialized the AC97 codec itself, which is not existing and you need to make it
D. optionally to increase DOS compatibility software tool to change the IRQs, etc.

So, it's already too much information, but in short to make 1720 work in DOS is simply not feasible, unless you're willing to spend the time and develop full-blown driver with software-emulation for DOS support, which will have bad compatibility with DOS software anyway, no matter what you do (as all existing software-emulations for DOS for other cards that has no hardware support). One more time - even to get 1712 working in DOS requires to develop some software, i.e. point C above.

I was thinking (few months ago) to do the necessary software work for 1712, because feature 4) I mentioned above is kind of interesting, as the retro-community (at least to my knowledge) has never heard how OPL-clone of 1712 sounds, i.e. how good or bad it is. I still can do it some day, as I have the skills and knowledge to do it, but still I guess I lack motivation to spend the time doing that.

BTW, you can forget about VIA VT8237 chipset as well, if there is 1720 in the picture, because then AC97 codec is connected to 1720 and not to the motherboard chipset.

Heyy mattw, thank you for that indepth post. This will save me a lot of time and frustration. Looks like I'm going to stick to getting Windows 98 on this thing.