VIA 8237

[mbodomi]

Confirmed as not working

[msantos2007]

Working fine on VIA VT8237A.

More details:

• SBEMU 1.0 Beta 3 (Vogons)
• Biostar P4M900 M7 Motherboard *
• MS DOS 6.22
• EMM386 NOEMS
• Doom
• jemmex/jload not used, but also work

*Also worked on Biostar P4M890 M7 and Intel DG41RQ/DG41TY motherboards

[Torinde]

The VSBHDA fork has some VT82xx improvements and mentions in its readme VT8233/35/37.

[Torinde]

The website focused on Win3.1 drivers has VIA VT8233 AC'97 Sound Driver (version 0.7)

I think there is source code in that - potentially useful to improve the DOS implementation? But I may be mistaken.

[crazii]

The VSBHDA fork has some VT82xx improvements and mentions in its readme VT8233/35/37.

I've checked the code, VSBHDA has the same way fixing for VT8237, and the VT8237 in VSBHDA is inspired from SBEMU, since the beta3 with VT8237 of SBEMU comes first.

[Torinde]

OK, so SBEMU already supports VT8233/35/37? Or only VT8233 and VT8237?

Are there other improvements from VSBHDA that can be merged back into SBEMU (besides the compatibility with latest upstream HX)?

Also, VSBHDA mentions that it emulates Sound Blaster Pro2, while SBEMU doesn't mention that? I assume it's just an omission and Pro2 is emulated by SBEMU?

[crazii]

OK, so SBEMU already supports VT8233/35/37? Or only VT8233 and VT8237?

Are there other improvements from VSBHDA that can be merged back into SBEMU (besides the compatibility with latest upstream HX)?

Also, VSBHDA mentions that it emulates Sound Blaster Pro2, while SBEMU doesn't mention that? I assume it's just an omission and Pro2 is emulated by SBEMU?

VT8233/35/37 all supported, they're using the same driver, but I only tested 8027. There might be improvements for HDA in VSBHDA, but I haven't checked.

I didn't explicitly state sbpro2. pro2 is no difference from pro, except for opl3. And pro2 is also a pro card, I remember Miles Sound have "sbpro (old version)" "sbpro (new version)" for music, but not for digital sound. Anyways it would be nice to add sbpro2 to avoid misunderstanding.

[Torinde]

There might be improvements for HDA in VSBHDA, but I haven't checked.

Reading the commit labels of VSBHDA it seems there are some improvements besides the HX API compatibility, but I'm not sure how to port those back to SBEMU - or even if it makes sense to do that before the HX compatibility. Some of them are re-arrangements of folders and adding explanations, but others touch the actual code:

• initial (I assume that's mostly the HX port trapping, but not sure)
• update to SB16 emulation
• SB16 support
• sblive support
• huge clean-up
• port trapping part simplified
• Delete VER directory
• changed go32 real-mode callback to plain assembly code
• adjusted readme
• added sbemu.txt
• remove sblive.mak
• using new hdpmi API "trap CLI/STI"; IF enabled on entry ISR
• update sbemu.txt
• source tree rearranged
• triggerIRQ now also handled by rmcb
• /SAFE cmdline option added
• fixed: wrong speed for mono out on SB16
• move 16-bit code in qemm.c to rmwrap.asm
• source code rearranged
• AU_Init simplified; string.c removed
• further cleanup
• split main.c into main.c and sndisr.c
• software mixer simplified
• support 16-bit unsigned format
• removed the "funcbit" stuff
• renamed project to vsbhda
• adpcm: fixed missing breaks in switch statement
• /F cmdline option added
• some cosmetic changes
• via8233 fixed
• fixed VIA VT82xx "low volume" issue
• cleanup AC97
• vsbhda.txt: added hint for JemmEx's NOVCPI option

@volkertb, is this something you can help with?

[crazii]

Yes not to do that in a easy way. I might be wrong but it seems that he's willingly to share his HX and code, but not willingly to use/help with others' code, based on the fact that he ignored my PR suggestion on port trapping, and that he totally reformed sbemu into another different shape and no PRs back. Now sbemu has more clean code in using mpxplay, but he just wouldn't wait. I'm glad if someone would create PRs based on his changes, but I'm not gonna do that myself, it's just - weird. It's not how open source work, at least not to me.

[Torinde]

People forget/delay replying for various reasons, a mundane explanation could be lack of time

Of course I'm willing to help adapt SBEMU to the API implemented in hdpmi; however, currently I'm unable to spend much time for programming...

So, taking this positive view - I suggest the following:

• @crazii reworks SBEMU to work with HX's HDPMIAPI.TXT
• @volkertb makes a PR in HX enabling Github actions (only for builds; releases to be triggered manually)
• @crazii makes a PR in HX for MDK's keyboard / "Get Interrupt Context" function - if needed?
• asking Baron-von-Riedesel what improvements he implemented in VSBHDA and if he can make PRs for those at SBEMU (which then will be already compatible with HX)

[crazii]

Yes thanks for the reminding. I think it's doable, but as you said I need little more time too. Currently I'm debugging usbddos and try to make it work on @volkertb 's PCs. But it seems difficult because I cannot debug, I have to check/review the code and find what the problem is. Maybe to buy a 2nd handed Mac Mini 2011 should be the right solution. Still there's some bugs I've encountered, and I'm debugging it now. Fortunately I'm not back to working yet, there'll be 1 or 2 months for me, otherwise the time would be more of a problem.