crazii
SB X-Fi support
I tried to get SBEMU working with X-Fi EMU20K1/CA20K1 PCI cards SB0730 and SB0460.
There are some old OSS drivers at http://www.4front-tech.com/developer/sources/stable/gpl/oss-v4.2-build2020-src-gpl.tar.bz2 Linked from https://qa.debian.org/cgi-bin/watch?pkg=oss4 They seem to be easier to understand compared to the current Linux drivers. For me, the SB0730 works in Linux but the SB0460 does not produce any sound.
Now I can load SBEMU, and the Duke Nukem 3D/Descent setup programs act like they are playing sounds, but no sound is produced. I don't know if DMA is being setup properly. If someone wants to have a look you can get the sources from my fork. The commit that enables X-Fi is here: https://github.com/jiyunomegami/SBEMU/commit/561422df59c0f5bbefd607b91c08e330b3fdc61f
@jiyunomegami Interesting. I've been trying to port OSS drivers to SBEMU as well. My reasoning was also that the OSS drivers would be easier to port than the ALSA drivers, since ALSA drivers are very specific to Linux, whereas OSS drivers support a fairly wide range of operating systems, including Haiku, which at its core isn't een a Unix-like/POSIX OS.
This effort had to do with the (since then alleviated) licensing concerns w.r.t. the sound driver code from the Mpxplay project. Establishing proper interfaces in the SBEMU code for porting OSS drivers would make it a lot easier to add support for additional sound devices, if they already have OSS drivers.
However, I have to say I got lost in the untangling of the device driver sources from the common OS APIs.
It would be nice if we could get this working in a modular way.
@jiyunomegami Interesting. I've been trying to port OSS drivers to SBEMU as well. My reasoning was also that the OSS drivers would be easier to port than the ALSA drivers, since ALSA drivers are very specific to Linux, whereas OSS drivers support a fairly wide range of operating systems, including Haiku, which at its core isn't een a Unix-like/POSIX OS.
This effort had to do with the (since then alleviated) licensing concerns w.r.t. the sound driver code from the Mpxplay project. Establishing proper interfaces in the SBEMU code for porting OSS drivers would make it a lot easier to add support for additional sound devices, if they already have OSS drivers.
However, I have to say I got lost in the untangling of the device driver sources from the common OS APIs.
It would be nice if we could get this working in a modular way.
I think it'll be a good addition for OSS drivers, you can continue porting the drivers if you like. Meanwhile I'll try to enabling SB X-Fi drivers from mpxplay but I don't have the card to debug with.
It's not unreasonable to set up crowdfunding so that people keen on seeing support for their favorite hardware added to SBEMU can fund the work needed to add such support, including the purchase of hardware to test and debug with. :wink:
I've checked the OSS drivers today, it seems more portable and clean, hmm, but still it's really a big load of work to port drivers to DOS.
I have a look the code, this is the original code:
pcmbufp=(uint32_t)card->pcmout_buffer;
pcmbufp<<=1;
for(pagecount = 0; pagecount < (card->pcmout_bufsize/EMU20KX_PAGESIZE); pagecount++){
card->virtualpagetable[pagecount] = pcmbufp | pagecount;
pcmbufp+=EMU20KX_PAGESIZE*2;
}
It seems you missed the pagecount bits as an index, the pcmbufp is aligned to 4K page boundary so (pcmbufp&0xFFF) should be zero, and the sound card take advantage of it and put more info into the lower 12 bits.
And EMU20KX_PAGESIZE*2 means a PCM16(short, 2bytes per sample) which actually uses 2 page, but I think it's OK to use 1 page with half of the original sample count, but the reset of the code might needs adjustment too.
BTW I've enable the SBXFi driver yesterday and pushed it up just now, it probably won't work, and not complete as your fork (it seems you add more support to you card, but I only copied the interrupt part from OSS), but you can check it as reference I guess. BTW you may try cmdline option /VOL9 to make sure there's no volume problem.
I checked OSS code, it seems OSS driver doesn't do it that way, probably need cross reference from multiple sources. I'll pick another time to see your code, but not sure I can actually help.
I think you should try it to see if it will work, support has been added. See the link @jiyunomegami .
@4nd3r50ncr I tried uncommenting the volume setup and AC97 stuff, but still no sound.
Tested [UserBuild_2024.01.15_08-08] on a MB which is working with AC97 SMEMU CARD: XFI PCI SB0460 tested Quake1 and Doom
initialization all looked good but no sound output from any port on the card
EDIT 2: Removed PCI card and tried onboard ac97 with X-FI build, UserBuild_2024.01.15_08-08 still works with ac97
EDIT 3: UserBuild_2024.01.24_20-23 same as before noticed on the mic/digital io port you do get beep and quiet buzzing on and after initialization ... maybe pumping out via digital connection
I managed to get a SB0460 to output some noises with SBEMU, but they are the wrong noises (static, clicks, etc). The Linux driver is working now with the SB0460, so I am now trying to port the Linux driver. More work, but higher probability of success.
@PCEmporium The SB0460 works! Try the sbemu.exe in this zip file: sbemu-ctxfi.zip
P.S. If you get random crashes, try unplugging the LAN cable...worked for me. The NIC on my machine uses the same IRQ as the sound card, and I guess the packet driver doesn't like that.
Nice, will test and edit this post if it works or not
YES, sbemu-ctxfi.zip Works for me
CARD: XFI PCI SB0460 tested Quake1 and Doom
thanks jiyunomegami
@volkertb Hopefully one can use the header files in drivers/include to compile the Linux drivers with minimal changes. https://github.com/jiyunomegami/SBEMU/tree/main/drivers/include
Next I will try to port some driver for another card with hardware FM. Maybe Trident 4DWave.
@crazii Is it OK to merge this stuff? There are a lot of files, mostly taken from Linux with minor changes.
Trident 4DWave, strangely also have so happy to test. Edit with the sbemu-ctxfi.zi no crashing for me seems stable the board i was using had no NIC will test it on a few other machines later and also test sbemu-emu20k2.zip.
*EDIT So could not test the EMU20k2, I could not find my PCI-e X-fi card if i find it i will test it out. Did test sbemu-ctxfi.zip with same card(SB0460) on a 2nd PC: Pentium 4 with onboard NIC and it is working.
@crazii Is it OK to merge this stuff? There are a lot of files, mostly taken from Linux with minor changes.
Yes, I will check the ymf and this one today, sorry for the waiting.
@crazii Is it OK to merge this stuff? There are a lot of files, mostly taken from Linux with minor changes.
OK, I saw a lot of files indeed. Is it possible to strip the dependencies using some defines (empty defines that we don't actually need)?
I believe some functions/structs in the files are not need, keeping the files is Okay. but I just want to make sure if any of them can be removed without modify them?
The biggest header is pci_ids.h. I suppose you could remove anything not related to sound cards, but I don't see the benefit. Some functions/structs/defines may not be needed now, but some other drivers may need them. I had to add more kernel headers for trident and emu10k1x. emu10k1x is the Dell OEM SB0200. It only supports 48KHz and there are no official DOS drivers AFAIK. I fixed the /K option so it accepts base 10 arguments, and added a way to force the sample rate to 48KHz for such cards.
Some functions/structs/defines may not be needed now, but some other drivers may need them.
Some are not used for sure, i.e. mutex.h, I can see that you already defines it empty, and it'll be more clean if it is removed.
I also see that there's modification in kernel.h, but I don't know the exact change you made, unless I compare it to the original linux source. It'll be much more convenient that the full change history for all files are kept. i.e. original files from linux can be committed first and then modified to current version in one commit, so that all changes done to the linux source are kept in commit history. Thanks.
I fixed the /K option so it accepts base 10 arguments, and added a way to force the sample rate to 48KHz for such cards.
Does SBEMU work for the 48KHz card without modifying /K option? It should work or these was some bugs.
Most cards support variable rates, and even if some rare cards doesn't support the specified frequency(22050/44100), the aui.freq_card should be set to 48K and SBEMU will adjust source frequency from SB to 48K, by calling the function mixer_speed_lq.
So there's little need to change /K option. although by AC97 standards only 48K is mandatory, but the sound blaster emulation source frequency is far lower than that.
There's an example in sc_ich.c, line 519:
if(!card->vra){
aui->freq_card=48000;
}else{
if(aui->freq_card<8000)
aui->freq_card=8000;
else
if(aui->freq_card>48000)
aui->freq_card=48000;
}
I thought I tried to set freq_card and it didn't work, but I was setting the rate in adetect, not setrate. I will see if it works later. In any case I don't like the way OPT_RATE is used, where hexidecimal 0x22050 is used. int samplerate = (MAIN_Options[OPT_RATE].value == 0x22050) ? 22050 : 44100; I changed it so you can specificy 22050,44100,or 48000 in base 10.
BTW kernel.h and mutex.h were made from scratch. I just pasted in or wrote whatever was necessary in order to build the linux drivers. You can tell the difference by looking at the leading #ifndef symbol: This was made from scratch: #ifndef SBEMU_LINUX_PCI_H This is straight from Linux: #ifndef _LINUX_BITOPS_H
I don't want to add the architecture specific files (asm/*.h) so those includes are commented out. Sometimes I copied the contents of an asm-generic header file into a file in the linux directory. Since Linux is so big and the differences are so many, I don't think it is meaningful to track the changes. I was looking at different versions of Linux (4.x, 5.x, and 6.x) which further complicates things.
So your changes might based on multiple Linux versions? I doubt the necessity but if it's really needed then there's no easy way to track all the changes. Still the original commit can be based on one version specific. I strongly recommend it when it's possible, it will help you reviewing your code for bugs maybe months/years later, when you forget what changes you've made exactly. Anyways it's a suggestion only and you can skip if you want to do it.😄
EDIT: if everything you've changed is guarded by a ifdef/ndef (i.e. SBEMU_LINUX_PCI_H) then it might works without commit history because you know it's a change from you.
Yes the 0x22050 is a simple and ugly hack that I didn't bother to do any conversions. There was only one case so I cheated, was planning to use base 10 if there're more cases.
@PCEmporium You can try this with your Trident 4DWave. What version do you have? DX or NX? I only have a DX. There is actually no hardware OPL3, so this uses the usual SBEMU OPL3 emulation. The official drivers use "VirtualFM" which is emulation by wavetable. There are a few examples on youtube. Also, the MPU-401 does not get detected by Duke Nukem 3D. Doom and Monkey Island work OK. sbemu-trident.zip This should work with the Dell SB0200 as well, but don't go out of your way to get one.
The official drivers use "VirtualFM" which is emulation by wavetable. There are a few examples on youtube.
I have a Toshiba dynabook SS2000 (Japanese edition of Portege 2000) laptop with CyberAladdin-T (Ali-M1535) board which has a Trident DX equivalent sound chip, and there's a win9x driver with OPL but it is OPL2 only with wave table emulation, the music is all messed up when using OPL3.
Maybe I can test it with my laptop too. I'll try to find it tomorrow.
@PCEmporium I forgot to mention that you might need to use himemx /MAX=32768 or you will just get loud noises from the trident.
Tested the Trident sbemu,
Trident 4dwave -DX chip(A CDD02 M9A62 9914/39040731)
Tried first without the himemx /MAX=32768 and it is working fine, maybe be because test system has only 64mb ram.
https://youtu.be/s6D90HxrGxA Video