SBEMU
SBEMU copied to clipboard
crazii
Trying support for PC-Speaker, Covox, and Gravis UltraSound
What do you think about us evolving this business into gravis ultrasound “GUS”, and Covox, and PC-Speaker? Oh, I was forgetting, we didn't need to port the highlight from sbemu-x so that when the connection is successful, the letters turn green, otherwise they turn red.
Yes, that would be good! #42
AWE32/64 would also be interesting - maybe reusing code from PCem/86Box/VMusic or SoundFX (related: dosbox-staging/dosbox-staging/issues/1682) or ALSA/Linux drivers.
Although probably first should come the switch to the HX port-trapping API (maybe requiring also to upstream Get Interrupt Context) https://github.com/crazii/SBEMU/issues/40 sbemu-x/sbemu-x/issues/12
Yeah people in VOGONS mentioned those, and MIDI too. I don't refuse those at all. I think all of those will be done eventually. Are you planning to start (one of them) right now? I think it'll helps a lot if you do. For myself, I would pick pc speaker or MIDI first because they looks more needed (probably, for most users. not really sure), but you can pick any one that you're interested in, if you're planning to.
@crazii Wouldn't it be better to go for a modular emulation core that would focus on the key functionality, namely the I/O port trapping and ISA DMA emulation part, with support in both real mode and protected mode games? And then provide an API for loadable modules that people could work on in separate projects that would focus on accurate emulation of specific sound devices?
Something I described here.
That way, 100% focus could be given on getting the port trapping stuff to work and work well, with various other projects focusing on developing the best possible modular backends, both complete software emulation cores for specific hardware (Sound Blaster Pro, GUS, etc) and simple "redirection" drivers in the vein of ADLiPT and SoftMPU. Heck, both those projects could then piggyback on this one.
Yes that's another way to get the midi (at least SoftMPU) to work. I bet the QPI emu is the breach: we just add HDPMI32i dependency to QPIEMU so that it adds the same pot trapping for PM mode, and everything is done. The dependency doesn't hurt because it's a plugin, not jemm itself. BUT I'm not sure if it's doable. and it also has more RM-PM mode transitions.
@crazii you forgot to add me as one of the collaborators in the project, I was already preparing myself with my time to help create new functions, I need you to give me your compilation instructions with RHIDE directly through DOS, creating a grp file of the instructions and the conversion with gpr2mak, in a complete way, so that I can do it more directly, then these instructions will be passed to the Linux compilation makefile. I need your instructions or your pre-configured zipped compilation package, it may be right here for me.
I don't know how to add collaborators. Let me check.
I've added a makefile for dos makefile.dos you can perform build & run on the fly under dos now. make -f makefile.dos make -f makefile.dos clean Let me know if the grp & grp2mak are still needed.
I added @thp @volkertb @4nd3r50ncr as collaborators, but I don't know the difference, Doesn't creating PR work for you?
Do you mean you need a zip pack for DJGPP tools? you can download it from here https://www.delorie.com/djgpp/zip-picker.html you need multiple zips and extract them into a same location.
I updated dos djgpp setup steps in readme https://github.com/crazii/SBEMU?tab=readme-ov-file#installing-djgpp-on-dos
No I didn't remove you, as I can see you in the settings. I'm totally inaccessible to any google sites (including youtube) from my country/region. You may ask others for help:)
The website focused on Win3.1 drivers has some MIDI/Speaker items, among others:
I think there is source code in that - potentially useful to improve the DOS implementation? But I may be mistaken.
@4nd3r50ncr, do you still plan to create some of the functionalities you mentioned above? Are the latest compilation instructions for DOS sufficient?
I planned to, but I'm not part of the group of developers, I was even programming myself for this, and organizing the compilation environment to stay focused, I was doing tests and everything, checking bugs. I had sent the invitation but then they removed it from the development participation team. It gave me discouragement.
@4nd3r50ncr Is there a way we could rekindle your encouragement? Because with an ambitious project like this, the more people that contribute, the better. @crazii has been doing all the heavy lifting w.r.t. work on the actual source code, with some help from @thp. So far, all I have been able to contribute is CI/CD automation stuff. (I've been trying to get involved in the source code side of things, but it hasn't been easy, since I'm not a very experienced C/C++ developer.) So having more people actually contribute actual improvements and additions in functionality is much welcomed.
You've made me curious about your work. Could you maybe create a Pull Request and have us review your code?
That's basically all that's needed for you to effectively become a contributor, as far as I know.
@4nd3r50ncr As you can see, committing code effectively makes you a "contributor".
So just open a PR. You can start with a "draft" PR, if you think it needs more work before it's ready. It's always good to have others give feedback, even as you work on it. :slightly_smiling_face:
What do you think about us evolving this business into gravis ultrasound “GUS”, and Covox, and PC-Speaker? Oh, I was forgetting, we didn't need to port the highlight from sbemu-x so that when the connection is successful, the letters turn green, otherwise they turn red.
Right, as far as I know, dosbox has these features, so it would be easier to port them than to create them from scratch. I'm going to take the day today to analyze the dosbox code to look for these features. And we continue as much as possible, and depending on time, I work every day in the early hours of the morning, so if there is time for me during the day I will continue. Now we just need to be patient 😅.
Great to hear that @4nd3r50ncr! From the DOSbox variants I suggest using code from X or Staging (whichever of the two is more convenient), because they added various improvements and fixes over the years.
These are the three files responsible for the hardware. So come on, Covox is Disney, then GUS (Gravis UltraSound), and PC-Speaker. These are the codes responsible for the hardware. Right @crazii ?
These are the three files responsible for the hardware. So come on, Covox is Disney, then GUS (Gravis UltraSound), and PC-Speaker. These are the codes responsible for the hardware. Right @crazii ?
Yes, they are. And here's some programming guides I found: https://wiki.preterhuman.net/Programmer%27s_Guide_to_the_Disney_Sound_Source https://wiki.osdev.org/PC_Speaker https://archive.gamedev.net/archive/reference/articles/article448.html
I wonder if they actually help but maybe use them as references for better understanding DOSBox codes.
For the Realtek HDA interface, would enabling the PC Beep hidden register suffice gor PC Speaker support? (https://docs.kernel.org/sound/hd-audio/realtek-pc-beep.html)
Current behaviour on Realtek HDA: C:> echo ^G Beeps SBEMU C:> echo ^G Silent
For the Realtek HDA interface, would enabling the PC Beep hidden register suffice gor PC Speaker support? (https://docs.kernel.org/sound/hd-audio/realtek-pc-beep.html)
Current behaviour on Realtek HDA: C:> echo ^G Beeps SBEMU C:> echo ^G Silent
It works for realtek, but may not work with other card, and may conflict with SBEMU's pc speaker emulation, if implemented. I think emulating pc speaker uniformly with no special case/code path will be better.
If I may share my opinion:
I think we should first focus on improving the stability and compatibility of the current Sound Blaster (Pro and 16), OPL3 and MPU-401 emulation support. Those are, after all, the most important DOS-era sound devices in terms of game support. And getting that to work is hard enough as it is.
The Covox Speech Thing and Disney Sound Source are interesting as actual physical devices to play with (especially on modern PCs), but adding support for emulating those two devices in software has very limited added value, since practically every game that supports those devices also support Sound Blaster.
PC Speaker emulation support would perhaps be a useful one to add, assuming that modern systems no longer support it natively, which I don't believe is the case, at least for motherboards and laptops that still have a CSM for legacy BIOS support.
But even then, it would be better to split that off into a separate issue.
And as for Gravis Ultrasound support, I have to say, even though I had a GUS myself in my teenage computing years, and was extremely loyal to that standard, the only real advantage of supporting it as an emulated sound card in SBEMU would be for sound support in demos. In terms of game support, there are very few games that offer an improved sound experience on the GUS compared to Sound Blaster 16 combined with General MIDI or MT-32 over MPU-401. So it would be cool to add it at some point, but I wouldn't prioritize it.
Ultimately, as requests for additional devices (both hardware backends and emulated devices) increase, I think it may be prudent to consider evolving SBEMU into a modular sound card emulation framework, with separate loadable modules (perhaps DLLs) for different emulators and hardware backends.
@crazii Curious about your thoughts on this. (I completely understand that the "fun" factor takes precedence over any of my above "priority" considerations, of course. After all, fun is the best motivator and productivity boost. :wink:)
Introducing loadable modules will increase the complexity of the code, first DOS DLLs are rare and not essential and merely no advantages (DLLs are shared among processes/exes to save memory/disk space, it also forces modularizing the source code in a way but still not necessary), second, you need to resolve conflicts/dependencies among different modules, i.e. module A want trapping an io port which is already trapped by module B, which is likely to happen with current MIDI through UART by @jiyunomegami and pure soft MPU in the future - Yes they will conflict without modules anyways but can be solved straight forward / hard coded.
I do agree that we need make it stable first, but if someone want to add more features without refactoring current code which will make it more unstable. I think it's OK.
EDIT: but I also recommend people who are particularly interested in SBEMU source to help improve its compatibility first if possible. (if they are boards/cards that SBEMU not works on).