Sound Blaster 16 Emulation Failure

Discussions about using non Windows and Linux guests such as FreeBSD, DOS, OS/2, OpenBSD, etc.

Sound Blaster 16 Emulation Failure

Postby over_clox » 20. Dec 2008, 16:41

Although I'm quite pleased to see more recent versions of VirtualBox include support for legacy Sound Blaster 16 emulation, I have yet to see this feature even come close to working reliably. Attempts to use SB16 sound have left me very disappointed when I heard badly jumping/skipping/repeating sounds, when the same programs work absolutely fine under DOSBox, despite its inherently slower nature.

I was also disappointed to find absolutely NO reference in the docs or online to the proper BLASTER environment variable settings for VBox. There doesn't seem to be a way to configure it either. All I could find was to install the unnecessary drivers and let guest programs automatically detect the card's settings, when the official Sound Blaster specs highly recommend that programmers read the BLASTER variable to perform automatic detection, yet VBox so conveniently neglects to specify this critical information anywhere in their docs. My testing found the proper settings to be "BLASTER=A220 I5 D1 H5", although this serves little purpose if it can't even play sound right.

I already have experience programming this card (and previous models), and the problem seems to be related to detecting whether DMA transfers have completed or not. By specifications, to detect this, two bytes are read from the DMA channel's length port to form a word, and when the value of this word resets to 0xFFFF, or 65535, then the DMA transfer has completed and another one can be started. The problem is that this remaining length never really seems to properly reset after the transfer has completed. The DMA remaining length value also doesn't seem to update properly during playback for the small chunks of sound I have managed to get to play through VBox's SB/SB16. All this value seems to do is attempt to change _occasionally_ and finally settle on some random values that usually coincide with some odd multiple of my sound buffer size, or are just plain random. Since this never seems to want to reset to 0xFFFF, at least at the right time anyway, then programs have no idea when to send the next chunk of sound for playback and things start to sound crazy, if anything is heard at all or worse, sometimes freeze VBox (although I think I may have been responsible for the couple of VBox freezes testing all this crap).

I've read that VBox uses the same SB16 emulation code that DOSBox uses, but there must be something different for the same programs to break under VBox. I'm surprised that problems with this feature seem to have gone neglected for so long since the option was originally made available in version 1.6.x. If nothing is going to be done to fix these problems, then it was a waste of time for the developers to put the feature in there, a headache for end users, and it may as well be removed since it doesn't seem to serve any useful purpose besides internal debugging in it's current state. Until it's properly fixed, it should be labeled as an experimental feature.

And while I'm at it, I'd also like to ask on behalf of all affected users (including myself) that something be done with the Win311 mouse lockup problem that's also apparently been present for far too long. DOSBox seems to have fixed their old mouse problems . . . doesn't seem too complicated to me, if only I was more familiar with languages other than BASIC then I'd investigate the source code repository myself. It's just a damn mouse, 2 axes, 2 or more buttons, PS/2 mouse standards have been around forever, most everyone has one, what is there to screw up?!?!?! They can make a 32 bit CPU run 64 bit instructions and operating systems, but don't even care to make a standard mouse work reliably . . . I just don't get it. I'm not asking for full blown guest additions for legacy systems, just a couple of bugfixes for very standard hardware emulation. I wouldn't be surprised if both problems have a related cause.

For anyone interested, much of my sound testing was done with a fairly small and robust program I personally wrote in QuickBASIC 4.5 as a foundation to experiment with custom audio compression/decompression algorithms - SB16WAVE.BAS. I've reviewed many other sources along with the formal SB/Pro/16 specs while writing this program, and it works 99.9% flawlessly in DOSBox, whether compiled, interpreted, or even interpreted with QB's little brother QBasic. I'll be happy to provide anyone in need with the source and executable, as long as I'm not held responsible for anything that may happen with it (not very likely). I also tested VBox sound in the game Redneck Rampage, which had a huge echo/stuttering problem and ran much slower than I expected it would.

Host: XP Pro SP2 - 2.53GHz P4
Guest: DOS 6.22 / Windows 3.11 (Sound tests were DOS only)
over_clox
Volunteer
 
Posts: 167
Joined: 5. Apr 2008, 22:43
Primary OS: MS Windows 7
VBox Version: PUEL
Guest OSses: Windows XP, Ubuntu 10.04, Legacy Testing

Postby stephanecharette » 20. Dec 2008, 22:12

I can feel the frustration in your post... :)

Note that I tried just 2 nights ago to get SB support working on a Windows XP guest cause my wife has this game she wanted to play. And the sound stuttered and skipped along so bad, she couldn't play it. So you're not alone in seeing this issue.

However, I had no way of knowing if the game ("Nancy Drew") was at fault, or if VB was at fault, so I didn't enter a bug ticket. From your post, you've done the programming and it seems you can pinpoint the problem. If you have not done so already, please enter a new bug ticket.

Same thing with the mouse issue -- if you haven't done so, please enter a new bug ticket.

Let us know the bug ticket #. You'll need to create yourself a new username/password for tickets; the web site is http://www.virtualbox.org/wiki/Bugtracker

Stéphane
stephanecharette
Volunteer
 
Posts: 283
Joined: 10. Nov 2007, 22:03
Location: Kelowna, British Columbia, Canada
Primary OS: Ubuntu other
VBox Version: PUEL
Guest OSses: Ubuntu-64bit, Windows

Postby over_clox » 21. Dec 2008, 06:02

On second thought . . .

I was quite surprised to find that VBox was about 5 times SLOWER at drawing gouraud shaded triangles than DOSBox in 320x200 8-Bit mode with an integer-only algorithm. Kinda odd that an emulator would be so much faster than a virtualizer in any situation. I guess some things will never make sense.

One more note . . . the extended keyboard keys didn't seem to map right either with DOS running on VBox. Overall, input is crap and output is crap with DOS in VBox. I guess that settles it . . . keep DOS in its box. It's not worth the headache.
over_clox
Volunteer
 
Posts: 167
Joined: 5. Apr 2008, 22:43
Primary OS: MS Windows 7
VBox Version: PUEL
Guest OSses: Windows XP, Ubuntu 10.04, Legacy Testing

Postby gzunk » 23. Dec 2008, 01:22

I seem to recall that any virtualization products that use the hardware virtualization supplied with the newer Intel / AMD processors have real problems with 16 bit operating systems - I don't think they're supported which means that the virtualizer has to emulate the 16 bit instructions. DosBox must just better at it - more practice I suppose.

I've installed Win98 on VBox and it runs like an absolute dog, not only that I believe that it pegs the host CPU to 100%. Not so bad if you're running a quad core, but a bit of a pain if your only on a dual - or heaven forbid a single core.
gzunk
 
Posts: 3
Joined: 23. Dec 2008, 01:17

Postby over_clox » 23. Dec 2008, 13:53

As far as the Win98 installation goes, you might want to download and install Rain so your CPU can run idle when not being used while running Win98.

Download Rain 2.0: http://www.majorgeeks.com/download430.html
over_clox
Volunteer
 
Posts: 167
Joined: 5. Apr 2008, 22:43
Primary OS: MS Windows 7
VBox Version: PUEL
Guest OSses: Windows XP, Ubuntu 10.04, Legacy Testing

Re: Sound Blaster 16 Emulation Failure

Postby Rockstar78 » 16. May 2009, 15:01

Hi all!
It's my first post here. I hope I'm posting at the right place... I'm posting here because I have a problem with the SB16 emulation in VirtualBox with a MS-DOS 6.22 guest. I successfully installed MS-DOS, the mouse and the CD-ROM drivers too, but I can't install the sound card. :(
I downloaded and tried 2 different DOS/Windows 3.1 driver packs I found on the Creative web page: ctcmbbs (containing ctcm.exe) and sbbasic (containing csp.sys) but none of them seem to work.
In my autoexec.bat the install.exe of sbbasic wrote:
SET BLASTER=A220 I5 D1 H5 P330 T6
I'm not sure if I'm using the right driver or not. Can someone help me? Which sound driver should I use? What should I write/load in config.sys and autoexec.bat?

By the way, my host system is Windows XP and I'm using the latest version of VirtualBox.

Thank you! :)
Rockstar78
 
Posts: 4
Joined: 16. May 2009, 14:18
Primary OS: MS Windows XP
VBox Version: OSE other
Guest OSses: DOS 6.22, Windows 2000, Mandriva 2008

Re: Sound Blaster 16 Emulation Failure

Postby cunha17 » 20. Mar 2010, 17:31

WORKING!

Actually, I got it to work by changing that BLASTER line to SET BLASTER=A220 I5 D1 T6 H7 P330.
I got Super Street Fight 2 Turbo (GAMETEK) running on MSDOS 6.22, but only the special effects(voices, lightning, etc.). When I activate the music the game freezes.
cunha17
 
Posts: 1
Joined: 20. Mar 2010, 17:28
Primary OS: MS Windows Vista
VBox Version: OSE other
Guest OSses: DOS,WINDOWS

Re: Sound Blaster 16 Emulation Failure

Postby ghr » 29. Mar 2010, 14:24

I filed a ticket for the (Win 3.x) mouse issue quite a while ago... Lost track of it.
ghr
Volunteer
 
Posts: 311
Joined: 25. May 2007, 22:46
Primary OS: MS Windows 7
VBox Version: PUEL
Guest OSses: DOS, Win3x, Win95, WinXP, Ubuntu, OS/2

Re: Sound Blaster 16 Emulation Failure

Postby TimeHorse » 18. Apr 2012, 18:10

over_clox wrote:I already have experience programming this card (and previous models), and the problem seems to be related to detecting whether DMA transfers have completed or not. By specifications, to detect this, two bytes are read from the DMA channel's length port to form a word, and when the value of this word resets to 0xFFFF, or 65535, then the DMA transfer has completed and another one can be started. The problem is that this remaining length never really seems to properly reset after the transfer has completed. The DMA remaining length value also doesn't seem to update properly during playback for the small chunks of sound I have managed to get to play through VBox's SB/SB16. All this value seems to do is attempt to change _occasionally_ and finally settle on some random values that usually coincide with some odd multiple of my sound buffer size, or are just plain random. Since this never seems to want to reset to 0xFFFF, at least at the right time anyway, then programs have no idea when to send the next chunk of sound for playback and things start to sound crazy, if anything is heard at all or worse, sometimes freeze VBox (although I think I may have been responsible for the couple of VBox freezes testing all this crap).


Okay, this is insane. This was written almost 4 years ago and the suggestion would be very simple to implement. Yet has it been? The poster stated later that a ticket for the mouse issue was posted but not if the DMA write -1 to length on complete transfer was. It seems to me if I knew which source file implemented the DMA I could do this myself. Not trivial, I'm sure, but let's not just twiddle our thumbs when clearly he's right about how DMA works and to fail to do so would be a violation of the standard. I mean I have 4.1.12r77125 running on Win7 and a similar install for MacOS X Lion and although I've not tried it on the 7 box, I do know that I run DOS and try to execute the USOUND.exe program for configuring the soundcard for Ultima Underworld and it can't detect the card and this would be a perfect explanation why. A search of the Bug Tracker for "DMA Sound" doesn't turn up anything. So I created a new ticket which we can track. As I just joined I can't link to that ticket but the Ticket # is 10463.

edit: If over_cbox's assertion is correct it should be in the file /vbox/trunk/src/VBox/Devices/PC/DevDMA.cpp so I suppose I'll focus on that but it's been changed so much over the last 4 years I'm again dubious of this being the sound issue. And for that matter, which bytes specifically should become -1? DMAControl::au8Page & DMAControl::au8PageHi? DMAChannel::u16BaseCount? DMAChannel::u16CurCount?
Last edited by TimeHorse on 18. Apr 2012, 19:18, edited 1 time in total.
TimeHorse
 
Posts: 3
Joined: 18. Apr 2012, 17:14

Re: Sound Blaster 16 Emulation Failure

Postby michaln » 18. Apr 2012, 18:31

TimeHorse wrote:It seems to me if I knew which source file implemented the DMA I could do this myself.


Here, have at it:

https://www.virtualbox.org/browser/vbox ... evSB16.cpp
https://www.virtualbox.org/browser/vbox ... DevDMA.cpp

And in case it's not obvious (after 4 years, it should be!), the attention devoted to SB16 emulation is directly proportional to how much importance it has to paying customers (i.e. none whatsoever).

There's a reason why people use DOSBox to run 20 year old games, and there's a reason why people don't use DOSBox to virtualize Windows 7.
michaln
Oracle Corporation
 
Posts: 2841
Joined: 19. Dec 2007, 15:45
Primary OS: MS Windows 7
VBox Version: PUEL
Guest OSses: Any and all

Re: Sound Blaster 16 Emulation Failure

Postby TimeHorse » 18. Apr 2012, 19:44

michaln wrote:There's a reason why people use DOSBox to run 20 year old games, and there's a reason why people don't use DOSBox to virtualize Windows 7.


And there's a reason why VBox is OpenSource because maybe no-one did look at it all these years and then by 1 June I have a patch submitted and the 3 folks still trying to get it to work in VBox will be happy. Or not. I may know ISO C++ like the back of my hand but not DMA or SB programming. So it's a crap shoot but I'll through some Intellectual Capital at it and see what sticks.

For the record even though DOSBOX runs on OS X it's a pain to get my installation from off the virtual drive onto my Mac Journaled HFS+partition and I still have the issue of Ultima 7 and it's persnickety memory requirements. :)
TimeHorse
 
Posts: 3
Joined: 18. Apr 2012, 17:14

Re: Sound Blaster 16 Emulation Failure

Postby michaln » 18. Apr 2012, 22:18

Well, getting Ultima 7 to run was almost as much fun as playing the game :) Especially Serpent Isle. A most remarkable game, in many ways.
michaln
Oracle Corporation
 
Posts: 2841
Joined: 19. Dec 2007, 15:45
Primary OS: MS Windows 7
VBox Version: PUEL
Guest OSses: Any and all

Re: Sound Blaster 16 Emulation Failure

Postby TimeHorse » 5. May 2012, 04:23

Okay, DOSBOX for OS X 10, Codename Lion sucks. Full Screen causes the program to crash. I need to be able to middle click and can't (pressing the left and right mouse buttons at the same time is what's really required and that's equivalent of middle click for most programs) and I have to press my track pad instead of just tapping it like I do for every other application. So essentially DOSBOS is unplayable so it's back to hacking Virtual Box as the only hope. Anyone else in?
TimeHorse
 
Posts: 3
Joined: 18. Apr 2012, 17:14

Re: Sound Blaster 16 Emulation Failure

Postby kveroneau » 19. Jan 2014, 23:56

TimeHorse wrote:
michaln wrote:There's a reason why people use DOSBox to run 20 year old games, and there's a reason why people don't use DOSBox to virtualize Windows 7.


And there's a reason why VBox is OpenSource because maybe no-one did look at it all these years and then by 1 June I have a patch submitted and the 3 folks still trying to get it to work in VBox will be happy. Or not. I may know ISO C++ like the back of my hand but not DMA or SB programming. So it's a crap shoot but I'll through some Intellectual Capital at it and see what sticks.

For the record even though DOSBOX runs on OS X it's a pain to get my installation from off the virtual drive onto my Mac Journaled HFS+partition and I still have the issue of Ultima 7 and it's persnickety memory requirements. :)


If your still looking for a way to Ultima VII on modern hardware, check out the Exult project, which has been around for many years. I have been using Exult to play U7 since I used to use Windows XP. Exult is available on all 3 major platforms, Linux, Mac OS X, and Windows. There are even ports for other platforms like Android.
kveroneau
 
Posts: 12
Joined: 19. Jan 2014, 00:01

Re: Sound Blaster 16 Emulation Failure

Postby vbguyny » 30. Aug 2015, 05:26

I hate to bring up an old topic but I am experiencing these issues in VirtualBox 5.0 under my hobby OS. The audio has zero issues under DOSBox and Bochs. However VirtualBox is having the same issues that over_clox described in the first post in this topic.

Does anyone know if a bug ticket was submitted to Oracle?
vbguyny
 
Posts: 6
Joined: 10. Apr 2012, 05:43

Next

Return to Other Guests

Who is online

Users browsing this forum: No registered users and 2 guests