VOGONS


First post, by SaxxonPike

User metadata
Rank Member
Rank
Member

In doing some research on the VT82* south bridges, it looks like FM NMI is a feature that can be enabled so that you can hook into something like INT 2h to process messages sent to an FM synthesizer. I suspect that VIAFMTSR sends its own emulated audio to the AC97 interface (I haven't reverse engineered anything to confirm this.) But what if we used a better core? Something based off what there is in Dosbox or NukeYKT's OPL core? SB support built into the VIA southbridge is actually not too bad and I think this will be a very useful way to accomplish the same task with better quality output, while also working in a realmode only environment when needed.

I have a guess as to how I might have to write the TSR, but has anyone else tried this technique before, and what other gotchas have you found? I'm tempted to dig into VIAFMTSR itself, but I don't know how appropriate of a template that would be. The challenge of doing it fresh is better, anyhow.

Sound device guides:
Sound Blaster
Aztech
OPL3-SA

Reply 1 of 3, by mkarcher

User metadata
Rank l33t
Rank
l33t
SaxxonPike wrote on 2023-08-20, 16:55:

In doing some research on the VT82* south bridges, it looks like FM NMI is a feature that can be enabled so that you can hook into something like INT 2h to process messages sent to an FM synthesizer. I suspect that VIAFMTSR sends its own emulated audio to the AC97 interface (I haven't reverse engineered anything to confirm this.)

I did reverse that thing. The VT82* south bridge has multiple digital audio channels and mixes them in hardware. In legacy emulation mode, one of the audio channels is used by the SB Pro engine, and a different channel is used for FM playback.

The FM emulation in fact uses the NMI (int 02). It is enabled using bit 0 in PCI config space register 48h. In the NMI handler, you can read back the data written to the OPL data port (that caused the NMI). The read back in the NMI is performed on the second I/O range declared in the PCI config space. The first port indicates whether the write was to 389 or 38b; the second port in that range indicates the current index and the third port indicates the data just written. All the relevant registers are documented in the VIA data sheets (for example in the VT82C686B data sheet).

SaxxonPike wrote on 2023-08-20, 16:55:

I'm tempted to dig into VIAFMTSR itself, but I don't know how appropriate of a template that would be. The challenge of doing it fresh is better, anyhow.

Take a look at the TSR if you need inspiration. The OPL emulator core isn't that great, but digging into that TSR might help you getting the stuff around the emulator core running.

Reply 2 of 3, by ishadow

User metadata
Rank Newbie
Rank
Newbie

OPL emulation isn't ideal, but it isn't the worst. The biggest issue for me is that VIAFMTSR takes too much conventional memory and I wasn't able to load it high.
However it is possible to load only DAC support for games that don't use FM and require a lot of conventional memory like SilverBall. By using DAC + FM, DAC only or SBEMU we're getting higher compatibility and higher FM quality with games that work using SBEMU.

Better VIAFM that don't use a lot of conventional memory and has better OPL3 emulator would be really great, especially with near 100% compatibility this solution has.

I wonder if it is possible to do General MIDI this way also.

Reply 3 of 3, by mkarcher

User metadata
Rank l33t
Rank
l33t
ishadow wrote on 2023-08-22, 11:07:

The biggest issue for me is that VIAFMTSR takes too much conventional memory and I wasn't able to load it high.

That's interesting. The version of VIAFMTSR I have at hand (38.417 bytes) is supposed to use VDS ("Virtual-mode DMA Specification") if present, which should allow loading it high. I can try troubleshooting next time I have a VIAFMTSR-compatible system at hand, but that will be some weeks from now. Just to ensure a common baseline: Are you using Windows 95 or Windows 98 EMM386.EXE to provide UMBs?