#DOSBOX WINDOWS 3.1 SB16 CODE#
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. DOSBox seems to have fixed their old mouse problems. Until it's properly fixed, it should be labeled as an experimental feature.Īnd 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. 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. 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. 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. 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). 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.
#DOSBOX WINDOWS 3.1 SB16 UPDATE#
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. The problem is that this remaining length never really seems to properly reset after the transfer has completed. 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. 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. 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.
#DOSBOX WINDOWS 3.1 SB16 INSTALL#
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. There doesn't seem to be a way to configure it either. I was also disappointed to find absolutely NO reference in the docs or online to the proper BLASTER environment variable settings for VBox. 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. 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.
0 kommentar(er)
