Re: sound support (Re: XMS problem with Aladdin demo)

Re: sound support (Re: XMS problem with Aladdin demo)

[Stas Sergeev]

Hello.

Julius Schwartzenberg wrote:
> Any idea why it is only 'half' working?
I can think of 2 things: either it is
a conflict with the linux driver, or
with dosemu. You can isolate the both
possibilities.
1. Disable sound in dosemu config.
Then dosemu will not even try to grab
an OPL ports. Yes, SB won't work, but
Wolf might still be able to see Adlib,
and you'll be able to tell if it works
any better.
2. Disable all the sound drivers in
linux and reboot the machine just in
case. Make sure they are still not
loaded after reboot. Maybe they configure
your card somehow that the DOS prog
starts having problems.

Re: sound support (Re: XMS problem with Aladdin demo)

[Julius Schwartzenberg]

Stas Sergeev schreef:
> Hello.
> 
> Julius Schwartzenberg wrote:
> 
>> Any idea why it is only 'half' working?
> 
> I can think of 2 things: either it is
> a conflict with the linux driver, or
> with dosemu. You can isolate the both
> possibilities.
> 1. Disable sound in dosemu config.
> Then dosemu will not even try to grab
> an OPL ports. Yes, SB won't work, but
> Wolf might still be able to see Adlib,
> and you'll be able to tell if it works
> any better.
I already tried this, but it doesn't seem to make any difference. 
Everything works exactly as when it is enabled, just without digital sound.

> 2. Disable all the sound drivers in
> linux and reboot the machine just in
> case. Make sure they are still not
> loaded after reboot. Maybe they configure
> your card somehow that the DOS prog
> starts having problems.
I just tried it. Wolfenstein 3-D now is able to detect the OPL3 chip, 
but I can't hear anything (probably because the mixer isn't set).
In Wacky Wheels, I also can't hear anything.

When I set up the OPL3 chip in Linux, I specified it should use port 
0x388 and not another port. I'm able to change this port to something 
else through the module settings. Would it be a good idea to change this 
value?

Thanks,
Julius

Re: sound support (Re: XMS problem with Aladdin demo)

[Ryan Underwood]

On Wed, Mar 09, 2005 at 08:02:37PM +0100, Julius Schwartzenberg wrote:
> 
> When I set up the OPL3 chip in Linux, I specified it should use port 
> 0x388 and not another port. I'm able to change this port to something 
> else through the module settings. Would it be a good idea to change this 
> value?

Most programs that want an Adlib or OPL3 chip expect the port to be
0x388.  Only programs which used the dual-OPL2 of SBPro usually use
0x220, and these are very rare.  Only program I know of that uses 0x228
is sb-sound.com.  So 0x388 is the best setting for now.  I can't explain
your other problems until I test this myself.

-- 
Ryan Underwood, <nemesis@icequake.net>

Re: sound support (Re: XMS problem with Aladdin demo)

[Ryan Underwood]

On Wed, Mar 09, 2005 at 01:48:08PM -0600, Ryan Underwood wrote:
> On Wed, Mar 09, 2005 at 08:02:37PM +0100, Julius Schwartzenberg wrote:
> > 
> > When I set up the OPL3 chip in Linux, I specified it should use port 
> > 0x388 and not another port. I'm able to change this port to something 
> > else through the module settings. Would it be a good idea to change this 
> > value?
> 
> Most programs that want an Adlib or OPL3 chip expect the port to be
> 0x388.  Only programs which used the dual-OPL2 of SBPro usually use
> 0x220, and these are very rare.  Only program I know of that uses 0x228
> is sb-sound.com.  So 0x388 is the best setting for now.  I can't explain
> your other problems until I test this myself.

I checked this myself.  Something strange is definitely happening.  If I
enable tracing, I can see the adlib traffic, but no sound is coming out.
I also tried without tracing and with 'fast' and nothing happens there
either.  The volume is OK because I've written a program on Linux side
that sets up a random adlib instrument to play, and I can hear the
sound there.

I wonder when this was broken, I know it worked perfectly only a few
months ago...

-- 
Ryan Underwood, <nemesis@icequake.net>

Re: sound support (Re: XMS problem with Aladdin demo)

[Julius Schwartzenberg]

Ryan Underwood schreef:
> I checked this myself.  Something strange is definitely happening.  If I
> enable tracing, I can see the adlib traffic, but no sound is coming out.
> I also tried without tracing and with 'fast' and nothing happens there
> either.  The volume is OK because I've written a program on Linux side
> that sets up a random adlib instrument to play, and I can hear the
> sound there.
> 
> I wonder when this was broken, I know it worked perfectly only a few
> months ago...
It also didn't work for me with the CVS version from 26-12-2004. (Same 
results as with the current version.)
I think I'll install version 1.2 and see what that one does.

Thanks,
Julius

Re: sound support (Re: XMS problem with Aladdin demo)

[Stas Sergeev]

Hello.

Julius Schwartzenberg wrote:
> I already tried this, but it
> doesn't seem to make any difference.
But dosemu stops complaining about the
port conflicts, right?

> I just tried it. Wolfenstein 3-D now is able to detect the OPL3 chip, 
> but I can't hear anything (probably because the mixer isn't set).
> In Wacky Wheels, I also can't hear anything.
Hmm, would it be possible then to boot
into DOS, set the mixer volumes, then
reboot back to linux (but with the "hot"
reboot, not with the reset button), and
then, if you don't load any ALSA module,
I think the volume will stick.
Another thing to try is to open also all
the SB ports to the DOS prog. Then you'll
probably be able to use mixer, and it
is also possible to use the SB ports
for the OPL access.

Re: sound support (Re: XMS problem with Aladdin demo)

[Julius Schwartzenberg]

Stas Sergeev schreef:
> Hello.
> 
> Julius Schwartzenberg wrote:
> 
>> I already tried this, but it
>> doesn't seem to make any difference.
> 
> But dosemu stops complaining about the
> port conflicts, right?
Yes, that complaint is gone then.

>> I just tried it. Wolfenstein 3-D now is able to detect the OPL3 chip, 
>> but I can't hear anything (probably because the mixer isn't set).
>> In Wacky Wheels, I also can't hear anything.
> 
> Hmm, would it be possible then to boot
> into DOS, set the mixer volumes, then
> reboot back to linux (but with the "hot"
> reboot, not with the reset button), and
> then, if you don't load any ALSA module,
> I think the volume will stick.
I do not have a DOS installation on the laptop at the moment (and my 
floppy drive doesn't seem to work very well), so I can't try that at the 
moment.

> Another thing to try is to open also all
> the SB ports to the DOS prog. Then you'll
> probably be able to use mixer, and it
> is also possible to use the SB ports
> for the OPL access.
I'm wondering if opening all SB ports will work, since the chip probably 
needs a DOS program before it's Sound Blaster compatible mode can be 
used. Also /proc/ioports doesn't list anything at those other ports.
I tried running the DOS programs from Yamaha in Dosemu. One of the 
programs quits with an error it can't run in a MS Windows Dosbox, 
another complains about the lack of EMM386 and VCPI support. I tried 
loading EMM386, but it says there are already protected mode 
applications running.

Julius

Re: sound support (Re: XMS problem with Aladdin demo)

[Julius Schwartzenberg]

Julius Schwartzenberg schreef:
> Stas Sergeev schreef:
> 
>> Hello.
>>
>> Julius Schwartzenberg wrote:
>>
>>> I already tried this, but it
>>> doesn't seem to make any difference.
>>
>>
>> But dosemu stops complaining about the
>> port conflicts, right?
> 
> Yes, that complaint is gone then.
> 
>>> I just tried it. Wolfenstein 3-D now is able to detect the OPL3 chip, 
>>> but I can't hear anything (probably because the mixer isn't set).
>>> In Wacky Wheels, I also can't hear anything.
>>
>>
>> Hmm, would it be possible then to boot
>> into DOS, set the mixer volumes, then
>> reboot back to linux (but with the "hot"
>> reboot, not with the reset button), and
>> then, if you don't load any ALSA module,
>> I think the volume will stick.
> 
> I do not have a DOS installation on the laptop at the moment (and my 
> floppy drive doesn't seem to work very well), so I can't try that at the 
> moment.
> 
>> Another thing to try is to open also all
>> the SB ports to the DOS prog. Then you'll
>> probably be able to use mixer, and it
>> is also possible to use the SB ports
>> for the OPL access.
> 
> I'm wondering if opening all SB ports will work, since the chip probably 
> needs a DOS program before it's Sound Blaster compatible mode can be 
> used. Also /proc/ioports doesn't list anything at those other ports.
> I tried running the DOS programs from Yamaha in Dosemu. One of the 
> programs quits with an error it can't run in a MS Windows Dosbox, 
> another complains about the lack of EMM386 and VCPI support. I tried 
> loading EMM386, but it says there are already protected mode 
> applications running.

I just found out some more. When I run pmidi with a midi file while 
Wacky Wheels is running, I can hear both the midi file I am playing and 
Wacky Wheels, but now I can also hear more of the music from Wacky 
Wheels than I can hear when I do not play the midi file at the same 
time. It doesn't matter whether I start pmidi first or Wacky Wheels first.
It seems they are indeed messing with each other.

Thanks,
Julius

Re: sound support (Re: XMS problem with Aladdin demo)

[Stas Sergeev]

Hello.

Bernhard Bialas wrote:
> However, a liitle bit more -compared
> to now-"marketing" would be very usefull.
Comparing with what? It is probably
only dosbox that is close enough
with the goals to dosemu, but the
fair comparison between these two
is very unlikely. It will heavily
depend of who's comparing:) I think
it is better to not, or there can
be some flame. I've seen the dosbox
vs dosemu wars on a dosbox forums
sometimes, it is better to not have
the like things also on that side;)

> As such "marketing" I would see
> a list of applications which has been 
> tested and works and also show
> these one which are problematic.
Yes, that list would be very usefull
to have. I was trying to do something
like that in EMUfailures.txt, but of
course the real database will be much,
much better.

> If I remember right, Ryan has a
> plan to realize such list.
Yes, for many years now:)
Setting the wiki page might be very
interesting. Will probably help to
update the docs a little and gather
all those writings about dosemu,
like "dosemu for dummies" and others.

Re: sound support (Re: XMS problem with Aladdin demo)

[Ryan Underwood]

On Tue, Mar 08, 2005 at 10:45:04PM +0300, Stas Sergeev wrote:
> Hello.
> 
> Bernhard Bialas wrote:
> >However, a liitle bit more -compared
> >to now-"marketing" would be very usefull.
> Comparing with what? It is probably
> only dosbox that is close enough
> with the goals to dosemu, but the
> fair comparison between these two
> is very unlikely. It will heavily
> depend of who's comparing:) I think
> it is better to not, or there can
> be some flame. I've seen the dosbox
> vs dosemu wars on a dosbox forums
> sometimes, it is better to not have
> the like things also on that side;)

Dosbox isn't the same project as dosemu anyway.  Dosbox includes a clone
DOS implementation which dosemu does not (FreeDOS is a separate
project).

> >If I remember right, Ryan has a
> >plan to realize such list.
> Yes, for many years now:)

Only one :P

> Setting the wiki page might be very
> interesting. Will probably help to
> update the docs a little and gather
> all those writings about dosemu,
> like "dosemu for dummies" and others.

Let me know what we can put up on sourceforge for scripting...


-- 
Ryan Underwood, <nemesis@icequake.net>

Re: sound support (Re: XMS problem with Aladdin demo)

[Stas Sergeev]

Hello.

Julius Schwartzenberg wrote:
>> http://www.geocities.com/SiliconValley/Circuit/5426/dosemu.html
>> something we don't want to have.
> This patch seems pretty neat.
Please note: this patch includes the
linux kernel module, not only the
dosemu modifications. This is needed
to drive the DMA controller directly.
You won't get it included into an
official kernel - people from XFree
tried that many times, this fails.
Linus doesn't want to provide the
DMA control to userspace I think,
or maybe there wasn't a good
implementation.
But people never give up:
http://www.ussg.iu.edu/hypermail/linux/kernel/0311.2/0107.html
http://www.bennee.com/~alex/software/kernel/index.php
The DMA access might be usefull for
dosemu, but not for sound. It is
good for driving some legacy hardware.

> Is there any chance that at least OPL3
> support could be added in such a way to Dosemu?
OPL3 doesn't need DMA. It doesn't actually
even need an interrupts. I see no reasons
why the one can't simply open an access
to the OPL3 ports for dosemu and it wont
work. Have you tried?

Re: sound support (Re: XMS problem with Aladdin demo)

[Ryan Underwood]

On Tue, Mar 08, 2005 at 10:24:08PM +0300, Stas Sergeev wrote:
> 
> >Is there any chance that at least OPL3
> >support could be added in such a way to Dosemu?
> OPL3 doesn't need DMA. It doesn't actually
> even need an interrupts. I see no reasons
> why the one can't simply open an access
> to the OPL3 ports for dosemu and it wont
> work. Have you tried?

If you have the hardware, this works fine.  However, dosemu must be
started as root.

-- 
Ryan Underwood, <nemesis@icequake.net>

Re: sound support (Re: XMS problem with Aladdin demo)

[Julius Schwartzenberg]

Ryan Underwood schreef:
> On Tue, Mar 08, 2005 at 10:24:08PM +0300, Stas Sergeev wrote:
> 
>>>Is there any chance that at least OPL3
>>>support could be added in such a way to Dosemu?
>>
>>OPL3 doesn't need DMA. It doesn't actually
>>even need an interrupts. I see no reasons
>>why the one can't simply open an access
>>to the OPL3 ports for dosemu and it wont
>>work. Have you tried?
> 
> 
> If you have the hardware, this works fine.  However, dosemu must be
> started as root.
> 

Cool, I've just got this to work!
It doesn't seem to work fully though.
I've added this to my dosemu.conf:
$_ports=" device /dev/snd/seq range 0x388 0x38b"
I'm using a YMFPCI chip which seems to contains an OPL3.
Wacky Wheels seems to be able to play 'some' stuff, but only if I run it 
after letting pmidi play a midi file. Wolfenstein 3-D doesn't seem to 
work though and after running Wolfenstein, I need to run pmidi first to 
be able to get Wacky Wheels to do something again.
In Wacky Wheels, I only seem to hear the some instruments (sound like 
the same ones pmidi used to play the file).
There is also an error printed about the adlib emulation conflicting 
with the ports setting, (but it seems that I can ignore that).
Any idea why it is only 'half' working?

Thanks,
Julius

Re: sound support (Re: XMS problem with Aladdin demo)

[Ryan Underwood]

On Tue, Mar 08, 2005 at 11:03:23PM +0100, Julius Schwartzenberg wrote:
> 
> Cool, I've just got this to work!
> It doesn't seem to work fully though.
> I've added this to my dosemu.conf:
> $_ports=" device /dev/snd/seq range 0x388 0x38b"
> I'm using a YMFPCI chip which seems to contains an OPL3.
> Wacky Wheels seems to be able to play 'some' stuff, but only if I run it 
> after letting pmidi play a midi file. Wolfenstein 3-D doesn't seem to 
> work though and after running Wolfenstein, I need to run pmidi first to 
> be able to get Wacky Wheels to do something again.
> In Wacky Wheels, I only seem to hear the some instruments (sound like 
> the same ones pmidi used to play the file).
> There is also an error printed about the adlib emulation conflicting 
> with the ports setting, (but it seems that I can ignore that).
> Any idea why it is only 'half' working?

No.  The only thing I can think of is that you need the range
0x220-0x223 or 0x228-0x229 as well.

-- 
Ryan Underwood, <nemesis@icequake.net>

Re: sound support (Re: XMS problem with Aladdin demo)

[Ryan Underwood]

More reply:

On Tue, Mar 08, 2005 at 11:03:23PM +0100, Julius Schwartzenberg wrote:
> >
> >If you have the hardware, this works fine.  However, dosemu must be
> >started as root.

PS. Or sudo.

> Cool, I've just got this to work!
> It doesn't seem to work fully though.
> I've added this to my dosemu.conf:
> $_ports=" device /dev/snd/seq range 0x388 0x38b"
> I'm using a YMFPCI chip which seems to contains an OPL3.

Yes, these chips do have a real OPL3, but must be enabled by the PCI
configuration.  Since you are using this for MIDI seq, it is likely the
case.  But the ALSA OPL3 driver may be using MMIO access and not PIO.
Check your /proc/ioports to see where ALSA claims the OPL3 ports
actually exists.

You can also enable IO-tracing for all of the mentioned ranges
(0x220-0x223, 0x228-0x229, 0x388-0x38b) to see where the app tries to
write OPL commands to.  If it is writing to the wrong range relative to
the real hardware, it's possible to redirect that access.  Redirected
access would be slower but with OPL this doesn't make much difference
since there is so little I/O traffic.

-- 
Ryan Underwood, <nemesis@icequake.net>

Re: sound support (Re: XMS problem with Aladdin demo)

[Julius Schwartzenberg]

Ryan Underwood schreef:
> More reply:
> 
> On Tue, Mar 08, 2005 at 11:03:23PM +0100, Julius Schwartzenberg wrote:
> 
>>>If you have the hardware, this works fine.  However, dosemu must be
>>>started as root.
> 
> 
> PS. Or sudo.
My Dosemu owned by root already has u+s. I thought that was about the 
same as running as root, but that indeed doesn't do.

>>Cool, I've just got this to work!
>>It doesn't seem to work fully though.
>>I've added this to my dosemu.conf:
>>$_ports=" device /dev/snd/seq range 0x388 0x38b"
>>I'm using a YMFPCI chip which seems to contains an OPL3.
> 
> 
> Yes, these chips do have a real OPL3, but must be enabled by the PCI
> configuration.  Since you are using this for MIDI seq, it is likely the
> case.  But the ALSA OPL3 driver may be using MMIO access and not PIO.
> Check your /proc/ioports to see where ALSA claims the OPL3 ports
> actually exists.
> 
> You can also enable IO-tracing for all of the mentioned ranges
> (0x220-0x223, 0x228-0x229, 0x388-0x38b) to see where the app tries to
> write OPL commands to.  If it is writing to the wrong range relative to
> the real hardware, it's possible to redirect that access.  Redirected
> access would be slower but with OPL this doesn't make much difference
> since there is so little I/O traffic.
In /proc/ioports the OPL3 is only listed at 0388-038b, which is why I 
set up that port range in Dosemu. The other ranges you mention to seem 
not to be used. Here is the full output of catting /proc/ioports:
http://haar.student.utwente.nl/~julius/ioports-laptop
I believe Wacky Wheels and Wolfenstein 3-D worked without problems when 
I ran them without Linux/Dosemu in DOS, so the hardware seems to be capable.

Thanks,
Julius

Re: sound support (Re: XMS problem with Aladdin demo)

[Ryan Underwood]

On Wed, Mar 09, 2005 at 10:27:16AM +0100, Julius Schwartzenberg wrote:
> >
> >PS. Or sudo.
> My Dosemu owned by root already has u+s. I thought that was about the 
> same as running as root, but that indeed doesn't do.

It should be similar.  With sudo, dosemu can tell that euid!=uid and
when it doesn't need root anymore, drops the privileges.

> In /proc/ioports the OPL3 is only listed at 0388-038b, which is why I 
> set up that port range in Dosemu. The other ranges you mention to seem 
> not to be used. Here is the full output of catting /proc/ioports:
> http://haar.student.utwente.nl/~julius/ioports-laptop
> I believe Wacky Wheels and Wolfenstein 3-D worked without problems when 
> I ran them without Linux/Dosemu in DOS, so the hardware seems to be capable.

I just have this nagging suspicion that Wolf3D uses 0x220-0x223, but I
could be wrong.  IIRC, Wolf3D also uses the strange SBPro mixer setting
for stereo digital audio.  I'll try this myself later on (my laptop has
a OPL3).

-- 
Ryan Underwood, <nemesis@icequake.net>

Re: sound support (Re: XMS problem with Aladdin demo)

[Ryan Underwood]

On Wed, Mar 09, 2005 at 09:21:57AM -0600, Ryan Underwood wrote:
> 
> I just have this nagging suspicion that Wolf3D uses 0x220-0x223, but I
> could be wrong.

Yep, I'm wrong, according to the Wolf sources:
#define alFMStatus 0x388 // R
#define alFMAddr 0x388 // W
#define alFMData 0x389 // W

-- 
Ryan Underwood, <nemesis@icequake.net>

Re: sound support (Re: XMS problem with Aladdin demo)

[Stas Sergeev]

Stas Sergeev wrote:
>> Problem right now is that JACK only supports ALSA as a
> That depends on how much we beleive
> into it. The faq says:
No, completely wrong quote, sorry.
Here's the proper one:
---
Currently jack only has support for alsa
as a sound driver. In the future there may
be more driver options although it is not
very likely.
---
But I don't know if it is a problem
or not. ALSA will be around probably
much longer than dosemu will:)
Have anyone looked into NAS btw?

sound support (Re: XMS problem with Aladdin demo)

[Stas Sergeev]

Hello.

Ryan Underwood wrote:
> Problem right now is that JACK only supports ALSA as a
That depends on how much we beleive
into it. The faq says:
---
a JACK backend to PortAudio
is under construction that would allow PortAudio apps to connect to JACK
ports.
---
Can we trust that? No idea.

> What about
> PortAudio?  It uses the callback based model like JACK but with many
> more back-ends besides ALSA.
From a quick glance to the PortAudio
docs (which are in a chaos, as far as
I can tell), it is not an abstraction
layer, but rather an I/O library that
provides an access to the different
sound systems, and that access is not
unified. This is probably not the level
we have to use directly. JACK can get
use of it instead.
Also, a callback-based model, I hate to
say that, but looks like not the best
choise for us:( That may be fine for
Adlib, but for DMA sound this is a
problem. As I said already, we have to
do the smooth DMA transfers. Callback
API is chunk-oriented by design, which
is not good. We can accumulate the data
on an SB side and feed it to the callback
routine, but even then we won't have
enough info to control the DMA speed.
I.e. how do we know when the next
callback is to happen, and is the
current speed enough to supply the
necessary amount of data when the
callback happens? VDMSound uses the
on-fly DMA speed adjusting, which is
what we probably have to do as well,
and that doesn't work with the callback
model as far as I can tell. This is a
big problem.

> There is the problem still of cards
> which do not support hardware mixing.
That must be the headache for the mixing
layer, not ours.

> First, dmix
> will be a default plughw device configuration, so users will not have
> problems with this.
That's not directly related to our
problems, but dmix is capable to mix
only two streams of the same rate.
It just sums the values of the streams.
I don't know how good it mixes more than
2 streams. It doesn't support 8bit
streams. If you want to use it with the
streams of a different rate, you'll likely
to have to route them via "plug" first,
but then there is no way to mmap the
card's buffer, and there are latencies
too. And you can't connect dmix to something
else than the "hw". etc etc. Well, the
way dmix is implemented, its use is very
limited. Well, not our problems at all.

> Also, ALSA semantics should be changed to return
> -EBUSY instead of blocking when a sound device is opened
Isn't it what's the O_NONBLOCK for?

> problem I don't know enough about is
> what control over the audio stream
> we get when dmix is in use.
Unless we use ALSA directly, not our
problem at all.

> Additional problem of using JACK is that it doesn't work with dmix, so
> it would block the card on a device which only supports one stream.
Do you mean it opens the "hw" instead
of the "default" output? That may be
for reason - if JACK does any mixing
itself (does it?), it might be doing
it better than dmix. Just a wild guess.

>> is full. Some DOS progs controls the
>> DMA registers during the sound output,
>> and that's why we have to guarantee the
>> smooth transfer and the accurate timing
>> ourself.
> Does this imply we must mmap the sound buffer?
No, that means exactly the opposite.
mmapping the buffer is a dead end.
We will then have to do the mixing
and resampling ourselves, and we'll
not allow the other apps to use the
card with us, unless there is a hw
mixing I guess, and you can't mmap
unless you use the ALSA/OSS directly,
and even then you don't know what
you have mmapped, as the DMA organisation
can be different on the different cards.
And when the things like plug/dmix are
in use, I don't know what you'll mmap
in fact. No, we aint gonna mmap the
cards buffers. That was used by the
direct-SB patch:
http://www.geocities.com/SiliconValley/Circuit/5426/dosemu.html
something we don't want to have.

>> code waits for the OSS buffer to became
>> empty, resets the sound card, sets the
>> new parameters, and resumes the transfer.
> Yes, this is completely stupid.
thanks... :)

> Well, this may have been sufficient
> at the time, since we had not even
Yes, exactly. That was quite sufficint
because it was a vast improvement over
the existing code, but it turned out
to be not future-proof. That's why the
new startups are achieving most of the
dosemu functionality within a *much*
smaller time-frame - they are not bound
to the ancient code and they do not
have to re-evaluate all those ancient
ideas behind that code etc.

> idea that e.g. VESA, DPMI, WfW support
> would become so good.
No-no, VGA/VESA emulation state internally
is not much better than the one of the sound.
Even the Windows VESA drivers that Japheth
wrote for us, are still not adopted.
DPMI state is now rather good indeed, but
that took years of (very slow) work.
WfW support is also not bad - that's because
finally we have the Windows expert who made
this possible. But there are still no
Windows experts on a FreeDOS side, so
FreeDOS is still not good for running
windows, which is bad also for dosemu.

> SB support is the worst part about trying
> play any games with dosemu.
But I thought it pretty much works.

> Well, it would help if we had more than two developers...
There are also people who help in a
specific areas, like windows support.

> dosemu has a marketing problem at the
> moment comparing to dosbox and qemu :)
I don't think so. dosbox have the Windows,
Mac and BSD users, as well as the x86_64
users. dosemu can be ported to Windows by
using coLinux, its a low-hanging fruit
actually, but noone of the dosemu developers
seem to be using Windows... Help in that
are is much appreciated. x86_64 port is
probably more difficult, but can and must
be done. The problem is that the qemu
author seem like have abandonned the
qemu-user development, and qemu-user no
longer runs dosemu (while it used to do
that very well in the past). I have
actually almost completed the qemu
integration when that happened:(
As for qemu itself - besides being portable,
it also runs any OS, not only the realmode
ones, so it doesn't need any additional
marketing promotions:)
As soon as dosemu is ported to windows
(can be done immediately by any coLinux
user), as soon as it ported to x86_64,
and as soon as the x86_64's new virtualization
technology is adopted (with which it will
probably able to also run any OS), there
will be no marketing problem at all.

> I think there is the illusion that it is
> only good for running business
> programs. Until 1.2, that was somewhat true.
Until 1.2 the project was dead.
This was almost official,
http://www.dosemu.org/alberto
---
since the development of dosemu stopped...
---
That was the time when it was abandonned
by users, distributors and developers.
So all the marketing problems are well
deserved. Now some respect to the project
was re-gained, but to really move forward
it must be much more work than just a
marketing.

> Also, there are many
> FreeDOS bugs that get blamed on dosemu
Fortunately dosemu can be used without
FreeDOS. FreeDOS is not even capable of
running Windows.

> DOSEMU has so many features that nobody even realizes.
Surely - who cares about DOS these days? :)
The real things can be done if we get
use of the new Intel's or AMD's
virtualization technologies, but till
that time all the features you listed,
are only for DOS. But what's the use
to compete with vmware anyway:) And
who knows when the legacy support will
be completely dropped from the CPUs.

> I can use
> external hardware with no slowdown,
> even interrupt driven!
It would be nice if you re-test that
ability with the current CVS code and
make sure it was not broken by some
recent draconian changes.

> This problem of perception is why I
> would like to start a wiki like we
You are welcome to do so - documentation
is really a weakest part of dosemu now.

> It would at the same time be a support area and
> a marketing area, because other people would be
> able to see all the apps that work no problem
> and realize that dosemu is actually useful.
Yes, marketing is important, but with
such a limited development power the
project have now, it may make no sense.
I.e. I think the current "marketing state"
is adequate with the power we have.
Doing more of a promoting also raises
the expectations. The inability to
satisfy these expectation will only
make the things worse.

Re: sound support (Re: XMS problem with Aladdin demo)

[Julius Schwartzenberg]

Stas Sergeev schreef:
> And when the things like plug/dmix are
> in use, I don't know what you'll mmap
> in fact. No, we aint gonna mmap the
> cards buffers. That was used by the
> direct-SB patch:
> http://www.geocities.com/SiliconValley/Circuit/5426/dosemu.html
> something we don't want to have.
> 
This patch seems pretty neat. Is there any chance that at least OPL3 
support could be added in such a way to Dosemu?
I think people that do not have an OPL3 chip would want to have the 
emulation of it outside Dosemu anyway since there are also several other 
programs that could use an OPL3 chip.
For people with OPL3 hardware, their hardware would automaticly used; 
for others the OPL3 would be emulated so that for Dosemu, FreeSCI, 
ScummVM, Linux Doom, etc. it would be the same as having a real OPL3 chip.

Thanks,
Julius

Re: sound support (Re: XMS problem with Aladdin demo)

[Ryan Underwood]

On Tue, Mar 08, 2005 at 07:28:51PM +0100, Julius Schwartzenberg wrote:
> This patch seems pretty neat. Is there any chance that at least OPL3 
> support could be added in such a way to Dosemu?

Yes, in fact I had a tree where I was working on this but it died when
my laptop hd crashed.  It involves a thin layer libopl that uses
hardware when it is available, and invokes the LGPL-licensed emulator
from AdPlug when not available.  libopl was intended to be used in all
these other projects also which are currently using OPL emulator.

I have rewritten libopl, but it requires a patch to OSS/Free and ALSA's
DMFM interface to work without superuser privilege.  I have to
reintegrate it with dosemu, then I'll send the whole patch.
Unfortunately, OSS commercial people will be out of luck for this, since
they will not change their API at request of users.

A change which was made recently is that dosemu became compatible with
pthreads.  Now I can make the libopl emulator mode threaded so it can
run concurrently with dosemu.  This should greatly improve the emulation
quality from Stas's original patch, instead of having to wait for the
sound system to be run from dosemu's main loops.

> I think people that do not have an OPL3 chip would want to have the 
> emulation of it outside Dosemu anyway since there are also several other 
> programs that could use an OPL3 chip.
> For people with OPL3 hardware, their hardware would automaticly used; 
> for others the OPL3 would be emulated so that for Dosemu, FreeSCI, 
> ScummVM, Linux Doom, etc. it would be the same as having a real OPL3 chip.

I thought about this for a long time already and have already begun with
a SDL-based synthesizer daemon.  For example, this could be connected to
alsaseq in the same way that timidity's ALSA daemon mode, to play MIDI
files where only OPL hardware exists.  Furthermore, for those machines
without OPL or hardware MIDI, OPL is far cheaper to emulate.  However,
for the short term (read: the time I have), libopl approach is good
enough.

-- 
Ryan Underwood, <nemesis@icequake.net>

Re: sound support (Re: XMS problem with Aladdin demo)

[Ryan Underwood]

On Tue, Mar 08, 2005 at 01:31:30PM -0600, Ryan Underwood wrote:
> 
> A change which was made recently is that dosemu became compatible with
> pthreads.  Now I can make the libopl emulator mode threaded so it can
> run concurrently with dosemu.  This should greatly improve the emulation
> quality from Stas's original patch, instead of having to wait for the
> sound system to be run from dosemu's main loops.

Stas, along these lines I had a question.  What would be the best way to
do the mixing of the adlib thread with the main SB output with the
current code?

-- 
Ryan Underwood, <nemesis@icequake.net>

Re: sound support (Re: XMS problem with Aladdin demo)

[Bernhard Bialas]

Hello,

> > It would at the same time be a support area and
> > a marketing area, because other people would be
> > able to see all the apps that work no problem
> > and realize that dosemu is actually useful.
>
> Yes, marketing is important, but with
> such a limited development power the
> project have now, it may make no sense.
> I.e. I think the current "marketing state"
> is adequate with the power we have.
> Doing more of a promoting also raises
> the expectations. The inability to
> satisfy these expectation will only
> make the things worse.

You are right. 
However, a liitle bit more -compared to now-"marketing" would be very usefull.
As such "marketing" I would see a list of applications which has been tested 
and works and also show these one which are problematic.
If I remember right, Ryan has a plan to realize such list.
It would bring new attention to the dosemu project.

Best regards
Bernhard Bialas

Re: sound support (Re: XMS problem with Aladdin demo)

[Ryan Underwood]

On Tue, Mar 08, 2005 at 04:01:49PM +0300, Stas Sergeev wrote:
> Hello.
> 
> Ryan Underwood wrote:
> >Problem right now is that JACK only supports ALSA as a
> That depends on how much we beleive
> into it. The faq says:
> ---
> a JACK backend to PortAudio
> is under construction that would allow PortAudio apps to connect to JACK
> ports.
> ---
> Can we trust that? No idea.

That's the wrong thing.  That means PortAudio can output to JACK.  That
still has JACK needing ALSA to the backend - meaning the users without a
2.4+ALSA or a 2.6 kernel are out.

Now, we could develop a new SB layer concurrent to the old one.  The new
one could use JACK or PortAudio or whatever.  The old one would still
always exist but be disabled by default when the new one is better.

> callback happens? VDMSound uses the
> on-fly DMA speed adjusting, which is
> what we probably have to do as well,
> and that doesn't work with the callback
> model as far as I can tell. This is a
> big problem.

Yeah, that is a big problem because everyone is using a callback model
these days - JACK, PortAudio, even ALSA has an optional callback model.

> >First, dmix
> >will be a default plughw device configuration, so users will not have
> >problems with this.
> That's not directly related to our
> problems, but dmix is capable to mix
> only two streams of the same rate.
> It just sums the values of the streams.
> I don't know how good it mixes more than
> 2 streams.

I know this is false because I have played i.e. 5 streams mixed with
dmix.  However, I don't know what mixing rates it supports on input.  I
know it requires 48KHz output to the soundcard.  That is a problem for
older cards.

> It doesn't support 8bit
> streams. If you want to use it with the
> streams of a different rate, you'll likely
> to have to route them via "plug" first,
> but then there is no way to mmap the
> card's buffer, and there are latencies
> too. And you can't connect dmix to something
> else than the "hw". etc etc. Well, the
> way dmix is implemented, its use is very
> limited. Well, not our problems at all.

It might be a good question for the ALSA list.

> >Also, ALSA semantics should be changed to return
> >-EBUSY instead of blocking when a sound device is opened
> Isn't it what's the O_NONBLOCK for?

Here is Takashis' reply to a Linus rant:
http://sourceforge.net/mailarchive/message.php?msg_id=10012702

There is disagreement, but most kernel developers who responded thought
that O_NONBLOCK to avoid hanging the app was silly.  If the app wanted
to wait for the sound device to become available, it makes more sense to
loop until not errno==EBUSY.

> >Additional problem of using JACK is that it doesn't work with dmix, so
> >it would block the card on a device which only supports one stream.
> Do you mean it opens the "hw" instead
> of the "default" output? That may be
> for reason - if JACK does any mixing
> itself (does it?), it might be doing
> it better than dmix. Just a wild guess.

Yes.  Progs which use 'hw' directly can't be supported by dmix, and even
worse, prevent any other dmix-supporting progs from using it.

> >>is full. Some DOS progs controls the
> >>DMA registers during the sound output,
> >>and that's why we have to guarantee the
> >>smooth transfer and the accurate timing
> >>ourself.
> >Does this imply we must mmap the sound buffer?
> No, that means exactly the opposite.
> mmapping the buffer is a dead end.

Ok, so what you mean is that we must have precise, low latency control
over what is written to the buffer.  I guess that also means the buffers
should be as small as possible without causing problems.

> and even then you don't know what
> you have mmapped, as the DMA organisation
> can be different on the different cards.

Right.  For example, quake3 has this problems.

> >idea that e.g. VESA, DPMI, WfW support
> >would become so good.
> No-no, VGA/VESA emulation state internally
> is not much better than the one of the sound.

vgaemu may not be very fast, but the VESA support seems to work very
well for me.
BTW, would OpenGL support be better for vgaemu?  It seems that on the
SDL mailing list, OpenGL is suggested in all cases for 2D operations for
performance reasons.

> FreeDOS is still not good for running
> windows, which is bad also for dosemu.

It's true.  I've been preparing a ready-to-run DR-DOS image based on the
Caldera hdimages of 7.03, but I'm not sure if it is okay to redistribute
it with the SCO problems.

> >SB support is the worst part about trying
> >play any games with dosemu.
> But I thought it pretty much works.

It does, but with pops and clicks depending on the soundcard.  The
problem might be related to my cards though.  (Vortex, CS4232's SBPro)
In any case, it's not too fast and sometimes acts strange.

> >dosemu has a marketing problem at the
> >moment comparing to dosbox and qemu :)
> I don't think so. dosbox have the Windows,
> Mac and BSD users, as well as the x86_64
> users.

Isn't it possible for a BSD port too?  Anyway, I see a lot of people
trying to run DOS games under Linux with e.g. dosbox and qemu and
complaining about the speed => Linux sucks, etc.  This is the marketing
problem I'm talking about.

> are is much appreciated. x86_64 port is
> probably more difficult, but can and must
> be done.

By this you mean using a CPU emulator, in which case it would also be
useful on any other Linux arch too.  In this case we are losing the
speed of native CPU, native IO, VESA console (vs vgaemu).  I'm not sure
how it would turn out.

> The problem is that the qemu
> author seem like have abandonned the
> qemu-user development, and qemu-user no
> longer runs dosemu (while it used to do
> that very well in the past). I have
> actually almost completed the qemu
> integration when that happened:(

Have you mailed him with that problem?

> As for qemu itself - besides being portable,
> it also runs any OS, not only the realmode
> ones, so it doesn't need any additional
> marketing promotions:)

Well, we are running protected mode OS too, as long as there is a DPMI
interface and we can find it.  The LDT emulation was the only other
problem, wasn't it?

> As soon as dosemu is ported to windows
> (can be done immediately by any coLinux
> user),

I think this is a great idea and didn't even realize it was possible
without resorting to emulation.

> and as soon as the x86_64's new virtualization
> technology is adopted (with which it will
> probably able to also run any OS),

Do you have information on this?  I didn't know there was any special
virtualization capability of x86-64.  Is it available in 32-bit mode on
those chips?

> That was the time when it was abandonned
> by users, distributors and developers.
> So all the marketing problems are well
> deserved. Now some respect to the project
> was re-gained, but to really move forward
> it must be much more work than just a
> marketing.

Fortunately you have been around for the meantime.  I try to fix bugs
and add little features here and there but I have no capability to make
architectural decisions.

> >Also, there are many
> >FreeDOS bugs that get blamed on dosemu
> Fortunately dosemu can be used without
> FreeDOS. FreeDOS is not even capable of
> running Windows.

Yes, see above comment re: DR-DOS.  If this can be redistributed, then
users can be expected to test the prog there before submitting a bug
report.

> >DOSEMU has so many features that nobody even realizes.
> Surely - who cares about DOS these days? :)
> The real things can be done if we get
> use of the new Intel's or AMD's
> virtualization technologies, but till
> that time all the features you listed,
> are only for DOS.

Of course.  But that happens to be the entire legacy of PC development
that predates WINE.  DOS is very important to close this gap.

> But what's the use to compete with vmware anyway:)

Have you bought VMWare?  I haven't.  It costs money.  And we are very
close to its functionality for free, for DOS/Win3.11 purposes.  In fact,
we are just short of Win4Lin's previous versions.  That's a really good
accomplishment for a project which was left for dead a few years ago.

> And who knows when the legacy support will be completely dropped from
> the CPUs.

It already has, at least in 64-bit mode.  Good thing most people won't
bother with 64-bit mode on desktop machines for a while.  They can't do
that until nobody is running Win9X anymore anyway.

> >I can use
> >external hardware with no slowdown,
> >even interrupt driven!
> It would be nice if you re-test that
> ability with the current CVS code and
> make sure it was not broken by some
> recent draconian changes.

Sure.

> >This problem of perception is why I
> >would like to start a wiki like we
> You are welcome to do so - documentation
> is really a weakest part of dosemu now.

Yes, I agree.  But can it be placed on the sourceforge site?

> Doing more of a promoting also raises
> the expectations. The inability to
> satisfy these expectation will only
> make the things worse.

But without users, we can't even know what works and what doesn't work,
and what people are trying to do, i.e. where to place requirements for
the next version.  So there is an argument for both.

-- 
Ryan Underwood, <nemesis@icequake.net>

Re: sound support (Re: XMS problem with Aladdin demo)

[Bart Oldeman]

On Tue, 8 Mar 2005, Ryan Underwood wrote:

> BTW, would OpenGL support be better for vgaemu?  It seems that on the
> SDL mailing list, OpenGL is suggested in all cases for 2D operations for
> performance reasons.

I looked at OpenGL some time ago, trying to figure out how dosbox uses it.
dosbox only uses it for scaling and from what I gather it only really
helps on NVidea cards but not ATI for instance.

If there's no scaling necessary, for instance if you run dosemu fullscreen
in X and the resolution matches 1:1, OpenGL won't help at all.

In general, where OpenGL really helps is if you can send objects
(textures) to VRAM and manipulate them there. The uploading of the
textures is the slow part.

And this is what dosemu does all the time... suppose MITSHM is active and
we're on a local box there are three buffers:
1. emulated video memory (e.g. 320x200 2bpp)
2. X pixmap (e.g 640x400, say at 32bpp)
3. real VRAM. Same format (mostly) as 2.

Now most of the X rendering business is to transform 1. to 2. Even if
you'd use opengl you'd still need a 1 to 2 step, but one could skip the
scaling -- bpp still needs to be transformed.

2. to 3. can be very fast using DMA sometimes even, it depends on a lot on
the X server and the graphics card.

So personally I see OpenGL as quite a bit of work for very little gain ...
and it doesn't help I use an ATI card myself.

> It's true.  I've been preparing a ready-to-run DR-DOS image based on the
> Caldera hdimages of 7.03, but I'm not sure if it is okay to redistribute
> it with the SCO problems.

There have been mirrors of it... But in general it won't work. It's
non-commercial use only, binary only, SF would never allow it.

A long time ago (James MacLean era) DOSEMU tried to work out something
with the then owners of DRDOS but it really didn't work out (long story).

The only way to work around FreeDOS issues is to fix them. So this is
is what I did for quite some time.

> Isn't it possible for a BSD port too?  Anyway, I see a lot of people
> trying to run DOS games under Linux with e.g. dosbox and qemu and
> complaining about the speed => Linux sucks, etc.  This is the marketing
> problem I'm talking about.

You just need a developer interested in a BSD port. There hasn't been one
for the last 8 years or so.

> Fortunately you have been around for the meantime.  I try to fix bugs
> and add little features here and there but I have no capability to make
> architectural decisions.

All I can say at this point is that by this point dosemu (even 1.2.2)
works well enough for me, as compared to what I wanted to contribute when
I started participating (just after 1.0.0 was released). In a way that's
good, in another way it's bad (for you! not me). Since it removes much of
the motivation to work on it.

DOSEMU became more and more of a pet project, and I've slowly realized
that I should let it go. Imagine what I can do with all the new time, say
- socialize with local people
- do more about sports, be a healthier person
- if I'm programming do so on projects more relevant to my job
- no more arguments with Stas! Yay! ;-)

Bart