One question: does this include the OPL3 synth emulation, or does it require VIAFMTSR?

I want to get rid of VIAFMTSR, as it is prone to crashes in some games 🤔

I do plan on implementing my own version of the TSR at some point using some open source OPL emulator core, but for now if you want OPL3 synth you still require it

Oerg866 wrote on 2025-02-27, 09:48:

I do plan on implementing my own version of the TSR at some point using some open source OPL emulator core, but for now if you want OPL3 synth you still require it

That would be great because the standard TSR was a memory hog... 😀

I just realized that VIASBCFG basically does what my tool does. Oh well, the more the merrier!

Out of curiosity...
I managed to get audio playing on the same dedicated native DMA mechanism that the VIA OPL3 TSR uses, but I don't know enough about the AC-Link architecture to know if it can be configured in any way; it seems to be hard-coded to 24KHz and the mono/stereo and 8/16 bit configuration bits are "reserved".

It also only makes sound if you unmute FM audio in the Sound Blaster Pro mixer, which I find curious.

The datasheet is not exactly helpful.

It is hard locked at half the codec sample rate, but I don't have a board with VSR codec set up currently to see if that affects it. I suspect it would break some other things though 😁

Anyway, today I managed to get Nuked OPL3 core to make sound on that audio channel, using SB provided NMI interrupts to catch the OPL register writes and generating wave data from the PCI interrupt after each DMA block....

But the caveat is - being the poor inexperienced DOS programmer that I am (:D) I have no idea how to write TSRs so getting to a proper VIAFMTSR replacement is still going to be a ton of work...

I'm not sure exactly how much buffer is needed for smooth playback, but hopefully with the help of experienced engineers I can make it possible to reliably load it high. Or use UMBs directly somehow. As I said, I don't know much about low level DOS programming so this is all learning by doing - so far I've been lucky with getting good results but that luck may change 😀

Nuked-OPL3 compiled under WATCOM with a real-mode DOS target more or less out of the box, but I had to fix one unsafe bitshift and adapt it to accept a far pointer to generate samples into. It's quite comfortable to get working, so I applaud the creator for making life just a tiny bit easier 😁

I can't add mp4 files to posts to prove it, but I got a TSR going with the Nuked OPL3 core but when I translated some of the 32-bit math into some hackey intrinsics with 32 bit opcodes to avoid expensive 16-to-32 bit wrapper library calls I probably screwed up some of the decay curve stuff, but it does make sound...

Hoping to have a proper VIAFMTSR replacement ready by the weekend

Total memory usage should be around 25-30 KB when I have everything optimized... Sorry it's probably going to be a memory hog until i'm more comfortable with the low level memory management stuff 😁

And then I can try to squeeze knowledge out of people on what I have to do to make it able to be loaded high.

EDIT: Maybe this link works, never know with discord CDN... as I said it sounds pretty crappy right now 😅
https://cdn.discordapp.com/attachments/784081 … 07f758981d679fb&

I've optimized the hell out of the Nuked OPL core but I think it's just too heavy. Some software copes well with high CPU usage such as Doom, but Tyrian for example slows down quite badly...

https://www.youtube.com/watch?v=50o0Exi8K-k

https://www.youtube.com/watch?v=CJT7F5pUaus

Nukedyt told me checking older versions of the core's envelope generator which may be faster, which i will try next.

Hello,

I have ported the DOSBox OPL core to C, it is faster than Nuked by a factor of 10 or more, plus an extra boost after inlining a lot of stuff that's only called once or twice. In fact, I was able to run it on a Celeron 300A.

I have also extensively modified DBOPL to be able to disable any kind of runtime table generation, as the math library in Microsoft C is very big and messes up the linkage + for some reason (fpu emulator?) it hooks NMI also which we kind of need here... So there is a precalculated set of tables for the fixed 24KHz frequency this SGD runs at.

Also, there's an odd compiler bug regarding bitwise complement on signed 32-bit integers in C 8.0 (aka. Visual C++ 1.52c), which cost me quite some time in getting this to work.

Anyway -

Here is a first test version of the VIAFMTSR replacement TSR. Please note this is very experimental and may crash. I've successfully tested it with DOOM, HSCPLAY and Adlib Tracker 2 so far.

Do also note that the VIA SB emulation must be set to Port 220 because I was too lazy to add detection for the port into the TSR just yet...

Load like this:

1via_ac97 (to init and unmute the codec)
2via_ac97 /fm:1 (if OPL is disabled in the BIOS)
3v97tsr r

Since I am still too stupid to understand how memory management works, it takes a fixed 64KB of conventional memory - it doesn't use that much, it's more like 35KB, but as I said I still don't understand how to calculate it properly because 4 DOS system programming books say 9 different things so... if anyone knows, please let me know 😁

I will clean it up and push it to github.

Thank you Oerg866, i have one old socket a motherborad with via 686b where i can try your tool. 😀

Oerg866 wrote on 2025-03-16, 21:34:

In fact, I was able to run it on a Celeron 300A.

Would it work on slowed down Via C3 with cache disabled?

Bruno128 wrote on 2025-03-16, 21:53:

Oerg866 wrote on 2025-03-16, 21:34:

In fact, I was able to run it on a Celeron 300A.

Would it work on slowed down Via C3 with cache disabled?

Hmmm not a clue, I would assume it's on the edge, if it does then applications themselves may slow down. Only one way to find out 😁

So far my compatibility list is:

* DOOM (Works nicely)
* DOOM II (Works nicely)
* Duke Nukem 3D (Works but sound lags like CRAZY and at some point music spazzes out like crazy)
* Tyrian (Occasional lags but works nicely otherwise)
* Commander Keen 4 (Works nicely if you have the conventional memory for it 🤣)
* Adlib Tracker 2 (Works nicely, occasional lags)
* HSC Player / Tracker (Works but the init routine spams too many register writes for the write queue, need to figure out a solution for that)
* Descent (sound test works but game doesn't launch, don't think that's an issue with the TSR)
* Stunts / 4D Sports Driving (Works pretty much flawlessly)

It's definitely very finnicky. Unfortunately I lack the skills to debug this properly so fixing all the problems may take a while.

I also tried LOADHIGHing the driver, and while it does load and not crash anything, and according to my debug print gets very high segment adresses for the buffers and ISRs, none of the ISRs ever seem to get hit. And the DMA engine in the chip gets very confused, presumably because the address calculated from that points to some garbage. That's where my latin ends, as we say in German 😀

Seems there is not much interest here, what a shame.

In any case, here is a new version of the TSR: https://github.com/oerg866/via_ac97.866/releases/tag/v0.5

I managed to figure out how Virtual DMA Services work so now you can LOADHIGH the driver (takes around 48K because I *still* can't figure out how to calculate properly...)

- Tyrian works properly now
- Buffers are smaller, better Timer IRQ performance so less lags in Tyrian and adtrack2
- Can now LOADHIGH the TSR (experimental)

Cfg/Mixer app:
- Fix missing line output in register order
- Add support for Line output 2
- Add support for Variable Sample Rate Codecs (experimental)

Oerg866 wrote on 2025-03-20, 20:55:

Seems there is not much interest here, what a shame.

I'm very interested and I follow this topic. Still I'm not sure if it's compatible with my hardware as I didn't try it on my PC yet.

https://github.com/user-attachments/files/193 … _vt8231test.zip

Here is a small test version that adds experimental support for VT8231 to the TSR (The FM SGD channel I/O ports are different compared to the 686A/B).

I can't test it because I don't own a board with that chipset.

I have been hoping for this for a long time but I simply don't have time to test right now...

https://github.com/oerg866/via_ac97.866/releases/tag/v0.6

New test version:

1TSR: Add support for VT8231 chip (EXPERIMENTAL, I don't own any boards with it)
2TSR: Lots of code deduplication & optimization in DBOPL
3TSR: Eliminate MS C-Library functions
4TSR: 32-bit arithmetic wrappers replaced by custom implementations (slight OPL3 core speedup)
5TSR: size massively reduced (EXE went from 38 to 26KB)
6TSR: Resident size now calculated "correctly" (doesn't take 64KB anymore!)
7TSR: Fix handling of "broken" / debugger VDS DMA support (they return NULL pointers)
8TSR: Fix es not being saved in ISR (fixes potential crashes)
9TSR: Fix memset crashing in ISR due to undefined direction flag
10TSR: Reworked OPL register write queue handling (uses ~1K more memory but fixes spammy applications like HSCPLAY)

Oerg866 wrote on 2025-03-22, 20:57:

https://github.com/oerg866/via_ac97.866/releases/tag/v0.6 […]
Show full quote

https://github.com/oerg866/via_ac97.866/releases/tag/v0.6

New test version:

Copy code to clipboard

1TSR: Add support for VT8231 chip (EXPERIMENTAL, I don't own any boards with it)
2TSR: Lots of code deduplication & optimization in DBOPL
3TSR: Eliminate MS C-Library functions
4TSR: 32-bit arithmetic wrappers replaced by custom implementations (slight OPL3 core speedup)
5TSR: size massively reduced (EXE went from 38 to 26KB)
6TSR: Resident size now calculated "correctly" (doesn't take 64KB anymore!)
7TSR: Fix handling of "broken" / debugger VDS DMA support (they return NULL pointers)
8TSR: Fix es not being saved in ISR (fixes potential crashes)
9TSR: Fix memset crashing in ISR due to undefined direction flag
10TSR: Reworked OPL register write queue handling (uses ~1K more memory but fixes spammy applications like HSCPLAY)

Many thanks, i have t5300 and it has VT8231, i would like to see duke3d and other game and sound improvements for via 686A/B/8231.
https://theretroweb.com/motherboards/s/hp-t5300

I am thankful and intrested for your init/mixer tools, thank you!

My pleasure!

I will work on the ability to unload the driver next. I have no clue how to do this yet :\