Re: App database, libsynth

Re: App database, libsynth

[Stas Sergeev]

Hello.

Ryan Underwood wrote:
>> Is there a planned solution for that? Or is there
>> something in ALSA that can help with the real-time
>> mixing even under that hostile conditions? dmix?
>  Yes, the dmix
Will this require an ALSA support plugin for
dosemu, or it is somehow possible to use dmix
via an OSS emulation layer?

> any soundcard that is modern enough to not have a OPL* cell on it 
> should support multiple opens.
I think there are many cheap PCI boards without
either. Btw, AFAIK WinXP decided against using
the HW mixing (I may be wrong), in which case it
(HW mixing, not XP) will not survive for too long:)

> If you think the mixing should be done inside
> the application
Actually I don't think so. But otherwise we have
to write another output plugin (you can't do too
much with OSS) and we may still need an internal
resampling anyway, because the program may alter
the sampling rate on the fly (without interrupting
the transferr) and I don't know if any of the
existing software can handle that properly.
Internal resampling will also help the current
OSS output a lot. So it is a matter of writing
another output plugin and internal resampling.
This is a good thing to do, but as noone has time...

> I tried to keep the application
> interface very simple and do most of the device management internal to
> the library, so the application programmer has to do no more than create
> a synth device, check if it was successful, and then write data to the
> device.
So does it interact with ALSA, or you decided to
do it a standalone?

> I can create a threaded interface to the library instead that operates
> within the process context, and returns a buffer to be mixed by the
> programmer of the application.
[]
> It also
> requires the program to have different behavior whether there is real 
> or emulated hardware.
OK, that makes sense of course. It is good that
your lib can use the real hardware and no point
to drop that only because noone wants to write
another sound plugin (and resampling!) for dosemu:)

> It didn't seem like as flexible a solution.
Yes, it is just cheap (I think) and is more
feasible under the current circumstances etc,
but after all it is rather poor.

> By the way, has anyone looked at using QEMU in dosemu?
Yes. Fabrice asked me to remove the coopthreads
from dosemu to make it qemu-compatible. The
replacement for coopthreads is already in CVS,
but the complete removal of coopthreads will
require also removing comcom.com, so the
coopthreads is still there.
OTOH I asked Fabrice to add some dos4gw support
to qemu.
He did that and dos4gw now runs, but not that
I was able to really get some of the prot. mode
apps running. Before qemu to support at least
the minimal amount of DPMI apps, I think it is
useless for dosemu (also even far not all the realmode
apps are working). After all qemu is officially
in an Alpha stage (the last time I checked),
so it may be too early for the integration
(but a good long-term ToDo if someone have enough
time and motivation).

Re: App database, libsynth

[Ryan Underwood]

Hi Stas,

On Fri, Jul 11, 2003 at 11:02:07PM +0400, Stas Sergeev wrote:
> Hello.
> 
> Ryan Underwood wrote:
> >>Is there a planned solution for that? Or is there
> >>something in ALSA that can help with the real-time
> >>mixing even under that hostile conditions? dmix?
> > Yes, the dmix
> Will this require an ALSA support plugin for
> dosemu, or it is somehow possible to use dmix
> via an OSS emulation layer?

The synth server's output would be completely separate from the
application using it, so the synth could use ALSA where dosemu could
still use the OSS emulation.  Unfortunately OSS emulation blocks when
ALSA is in use, so one would have to use a wrapper like aoss to redirect
the dosemu OSS output to ALSA.  ( see below (1) )

IMO, it would be a good idea to start to use ALSA in dosemu.  I can't
volunteer to code it at the moment though, too much else going on :(

> >any soundcard that is modern enough to not have a OPL* cell on it 
> >should support multiple opens.
> I think there are many cheap PCI boards without
> either. Btw, AFAIK WinXP decided against using
> the HW mixing (I may be wrong), in which case it
> (HW mixing, not XP) will not survive for too long:)

In that case, it is a good idea dmix is around.  Unfortunately, software
mixing is CPU intensive and dosemu is already emulating lots of things
in the X version (svga, blaster, etc).

I would be curious to find out if XP really got rid of hardware streams
mixing or not.

You may be right that people are stuck with OSS drivers that only
support 1 stream and have no FM device.  I don't see a way to deal with
this at the moment.  Though you would be hard pressed to find a
soundcard that didn't have an ALSA driver these days.  And, c-media PCI
cards have an opl3 onboard and cost something like $5. :)

> 
> >If you think the mixing should be done inside
> >the application
> Actually I don't think so. But otherwise we have
> to write another output plugin (you can't do too
> much with OSS) and we may still need an internal
> resampling anyway, because the program may alter
> the sampling rate on the fly (without interrupting
> the transferr) and I don't know if any of the
> existing software can handle that properly.
> Internal resampling will also help the current
> OSS output a lot. So it is a matter of writing
> another output plugin and internal resampling.
> This is a good thing to do, but as noone has time...

Yeah.  Also what about sending pc-speaker output to the dsp?

> >I tried to keep the application
> >interface very simple and do most of the device management internal to
> >the library, so the application programmer has to do no more than create
> >a synth device, check if it was successful, and then write data to the
> >device.
> So does it interact with ALSA, or you decided to
> do it a standalone?

(1) Theoretically, it can output to either ALSA or OSS, though I use ALSA to
test it.  I guess the best thing to do is to let the application
programmer set whether it outputs to ALSA or OSS at runtime.

> >I can create a threaded interface to the library instead that operates
> >within the process context, and returns a buffer to be mixed by the
> >programmer of the application.
> []
> >It also
> >requires the program to have different behavior whether there is real 
> >or emulated hardware.
> OK, that makes sense of course. It is good that
> your lib can use the real hardware and no point
> to drop that only because noone wants to write
> another sound plugin (and resampling!) for dosemu:)
> 
> >It didn't seem like as flexible a solution.
> Yes, it is just cheap (I think) and is more
> feasible under the current circumstances etc,
> but after all it is rather poor.
>

Ok, well I'll continue working on libsynth until I see a problem with
its design :) I have wolf3d (the icculus port) playing adlib music
through it, but it needs to be made a lot better.

The configurations I was thinking about being relevant to dosemu are:
- Single OPL2 (adlib)
- Dual OPL2 (SB Pro)
- OPL3 (SB Pro II, SB16)
- CMS chips (Game blaster)
- Tandy/PCJr TI sound chip

Of course you could program a C64-SID from a DOS program if you wanted
to... :)  Just set it up at some port address in dosemu, create the
synth device, and program it like you had a C64.  Maybe if you have a
HardSID card you could use that too.

BTW there is an ongoing project to implement a MT-32 emulator in dosbox.
Once that is complete I can implement the emulator core as an ALSA
sequencer client, which if dosemu had alsa support, it could connect to
that sequencer slot and use the MT-32.  Or else maybe something could be
done with midid?  Is midid a good idea to keep around for the long term?

> >By the way, has anyone looked at using QEMU in dosemu?
> Yes. Fabrice asked me to remove the coopthreads
> from dosemu to make it qemu-compatible. The
> replacement for coopthreads is already in CVS,
> but the complete removal of coopthreads will
> require also removing comcom.com, so the
> coopthreads is still there.
> OTOH I asked Fabrice to add some dos4gw support
> to qemu.
> He did that and dos4gw now runs, but not that
> I was able to really get some of the prot. mode
> apps running. Before qemu to support at least
> the minimal amount of DPMI apps, I think it is
> useless for dosemu (also even far not all the realmode
> apps are working). After all qemu is officially
> in an Alpha stage (the last time I checked),
> so it may be too early for the integration
> (but a good long-term ToDo if someone have enough
> time and motivation).

Agreed, in fact something that might be a good idea to do is start
making a checklist of things that need to be done before dosemu will run
on another non-x86 linux platform.

If the x86 emulator becomes working, dosemu will be the most flexible
dos emulator around, either working in v86 mode, using a svga card,
sound blaster, etc on the real hardware, all the way to a complete
emulation of a DOS machine on completely foreign hardware.  That way if
the user has a x86, they get very fast speed for the most part, and if
they don't have a x86, they can still have the same high level of
compatibility that dosemu has.

There is always the possibility to port to a non-linux platform but I
think it will take untying it from the x86 hardware to get more people
interested in dosemu long-term.

-- 
Ryan Underwood, <nemesis at icequake.net>, icq=10317253

Re: App database, libsynth

[Bart Oldeman]

On Fri, 11 Jul 2003, Ryan Underwood wrote:

> You may be right that people are stuck with OSS drivers that only
> support 1 stream and have no FM device.  I don't see a way to deal with
> this at the moment.  Though you would be hard pressed to find a
> soundcard that didn't have an ALSA driver these days.  And, c-media PCI
> cards have an opl3 onboard and cost something like $5. :)

I just keep wondering about the FM devices. The DOSBOX people seem to have
been able to get that working, so what is special about DOSBOX that is so
difficult in DOSEMU?

I was wondering btw:

http://www.happypenguin.org/show?DOSbox
http://www.happypenguin.org/show?DOSbox&start=10

the opinions here are really different (no I didn't contribute but I'm
wondering who did)... I only recently had a look at
DOSBOX -- they really want games and games only; the builtin DOS doesn't
worry at all about "undocumented" DOS stuff and backspace doesn't work
very well in DEBUG. But then I may be a little biased.

In any case whatever works better in DOSBOX (e.g. parts of VGAEMU still I
think) can be looked up in the source code; they thank DOSEMU too.

> > replacement for coopthreads is already in CVS,
> > but the complete removal of coopthreads will
> > require also removing comcom.com, so the
> > coopthreads is still there.

just to clarify, it's still there but it's dead code as long as you don't
use comcom. Before it was always initialized.

> There is always the possibility to port to a non-linux platform but I
> think it will take untying it from the x86 hardware to get more people
> interested in dosemu long-term.

agreed. And QEMU will probably stand a better chance now than Alberto's
simx86 since some very capable people work at it and Alberto doesn't seem
to have time for simx86 anymore. Right now QEMU also emulates DOSEMU
itself which is a little strange however.

One interesting platform is AMD's x86-64 (hammer, opteron, or whatever
it's called today). Linux for x86-64 does have modify_ldt but no v86.
That means that a potential future DOSEMU for it has to run "real
mode" 16bit apps emulated but can execute DPMI apps natively.

http://holarse.wue.de/?content=emu_dosemu
has an interesting opinion too:

Fazit: Auch wenn Dosbox bereits einiges leistet, kann er auch im Spielebereich
Dosemu noch nicht ersetzten. Beide haben vor und Nachteile. Bei Dosemu stört
sicher am meisten, das er auf Linux/x86 beschränkt ist. An Dosbox vermisst man
dagegen den Fehlenden Protectedmode sehr. Es ist also sicher am besten,
beide zu probieren und für jede Aufgabe den zu wählen, der sie am besten
bewältigt.

rough translation:
Result: Even if DOSBox already really accomplishes something, it cannot
really replace DOSEMU for games. Both have adavantages and disadvantages.
With DOSEMU it's most annoying that it is restricted to Linux/x86. With
Dosbox one misses protected mode a lot. It is certainly best to try both
and to decide which one to use on a case by case basis.

Bart

-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: App database, libsynth

[Ryan Underwood]

Hi Bart,

On Fri, Jul 11, 2003 at 09:23:32PM +0100, Bart Oldeman wrote:
 
> I was wondering btw:
> 
> http://www.happypenguin.org/show?DOSbox
> http://www.happypenguin.org/show?DOSbox&start=10

"A DOS emulator that has exceeded dosemu."
I'm sorry but I disagree with that comment.  Maybe if playing games is
ALL you care about.  dosemu's ability to use terminal I/O, to handle
network locking, to run BBS software and door games, as well as use
whatever DOS your application requires, these are all features that go
missing in the other DOS emulators (besides doscmd).  I *love* being
able to do such things as run a dos program and deal with its output
by piping it through things.

Perhaps dosemu needs a bit of work to make it more friendly to the
gaming-crowd, but it is certainly a long way ahead in the overall
picture of what a modern VDM needs to do.

> In any case whatever works better in DOSBOX (e.g. parts of VGAEMU still I
> think) can be looked up in the source code; they thank DOSEMU too.

I'm glad they do too! :)  Too many people seem to think GPL == free code
for the taking and replacing names & copyrights with my own is ok.

Another side project I work on is a perl config generator for dosemu --
you simply go to a web page, specify the version of dosemu you like to
generate a config for, and the options you want, and it spits out a
dosemu.conf for you.  Perhaps something similar can be made into a nice
perl/gtk app for the point & click crowd.

With the web page config generator cross referencing with a
compatibility database, you could have such things as telling the user
any bad things about the options he/she selects, such as "don't use
these options together with this dosemu version or you won't be able to
use program X".

> agreed. And QEMU will probably stand a better chance now than Alberto's
> simx86 since some very capable people work at it and Alberto doesn't seem
> to have time for simx86 anymore. Right now QEMU also emulates DOSEMU
> itself which is a little strange however.

Haha!  That does present a hall of mirrors effect to dosemu. (DOSEMU
uses qemu to emulate DOSEMU which uses qemu to emulate DOSEMU which uses
qemu...)

> One interesting platform is AMD's x86-64 (hammer, opteron, or whatever
> it's called today). Linux for x86-64 does have modify_ldt but no v86.
> That means that a potential future DOSEMU for it has to run "real
> mode" 16bit apps emulated but can execute DPMI apps natively.

Are you certain about emulation necessary for 16bit apps?  I look at the
developer's overview for hammer, and it starts out with:

"The x86-64 architecture supports legacy 16-bit and 32-bit applications
and operating systems without modification."

It goes on to say:
"compatibility mode is enabled by the operating system on an individual
code-segment basis.  From the application's viewpoint, compatibility
mode looks like a legacy x86 protected-mode environment."

Which means to me, that vm86() will have different semantics on x86-64,
probably setting up a 1MB v86 window but also turning on the
"compatibility mode" flag for that process.  Of course, I don't know
what I'm talking about, but take a look at the pdf here:

http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/x86-64_overview.pdf


> rough translation:
> Result: Even if DOSBox already really accomplishes something, it cannot
> really replace DOSEMU for games. Both have adavantages and disadvantages.
> With DOSEMU it's most annoying that it is restricted to Linux/x86. With
> Dosbox one misses protected mode a lot. It is certainly best to try both
> and to decide which one to use on a case by case basis.

To be honest, I think we can do everything Dosbox does as well.  It is
good to have both projects around though, because Dosbox presents more
of a "zero-configuration" environment to the user, where DOSEMU has many
more features that interact in various ways, so the user has to do some
tweaking most of the time to get it working the way they want.

-- 
Ryan Underwood, <nemesis at icequake.net>, icq=10317253

Re: App database, libsynth

[Bart Oldeman]

On Fri, 11 Jul 2003, Ryan Underwood wrote:

> On Fri, Jul 11, 2003 at 09:23:32PM +0100, Bart Oldeman wrote:
>
> > I was wondering btw:
> >
> > http://www.happypenguin.org/show?DOSbox
> > http://www.happypenguin.org/show?DOSbox&start=10
>
> "A DOS emulator that has exceeded dosemu."

it almost seems this comes from harekiet himself. But it's just a fanboy.
Anyway. I wish them good luck with DPMI.

> > One interesting platform is AMD's x86-64 (hammer, opteron, or whatever
> > it's called today). Linux for x86-64 does have modify_ldt but no v86.
> > That means that a potential future DOSEMU for it has to run "real
> > mode" 16bit apps emulated but can execute DPMI apps natively.
>
> Are you certain about emulation necessary for 16bit apps?  I look at the
> developer's overview for hammer, and it starts out with:
>
> "The x86-64 architecture supports legacy 16-bit and 32-bit applications
> and operating systems without modification."

look carefully. x86-64 has three modes (instead of the familiar real
and protected modes) that can only be (normally) switched between
by rebooting:
real -- legacy    -- long
16bit   32bit pm     64bit pm
        16bit pm     32bit pm (compatibility)
        vm86         16bit pm (compatibility)

dosemu runs in legacy mode but then your x86-64 is just an Athlon on
steroids and other processes cannot use more than 4GB of memory.

In long mode there is no vm86.

> To be honest, I think we can do everything Dosbox does as well.  It is
> good to have both projects around though, because Dosbox presents more
> of a "zero-configuration" environment to the user, where DOSEMU has many
> more features that interact in various ways, so the user has to do some
> tweaking most of the time to get it working the way they want.

DOSEMU is intrinsically a little more difficult to configure (primarily
because it needs an independent DOS rather than having one built in) and
no matter how good FreeDOS gets it seems there will always be some who
really want to run another DOS in it. At least xdosemu+freedos should be
as easy as possible (it's been easy since 1.0.2, it's just that extracting two
tarballs in one's home directory is a little unusual -- that's why I tried
to simplify the systemwide compilation and installation from source, so
making RPMs and DEBs should be easy)

Bart

Re: App database, libsynth

[Ryan Underwood]

Hi Bart,

On Sat, Jul 12, 2003 at 09:57:05PM +0100, Bart Oldeman wrote:
> >
> > Are you certain about emulation necessary for 16bit apps?  I look at the
> > developer's overview for hammer, and it starts out with:
> >
> > "The x86-64 architecture supports legacy 16-bit and 32-bit applications
> > and operating systems without modification."
> 
> look carefully. x86-64 has three modes (instead of the familiar real
> and protected modes) that can only be (normally) switched between
> by rebooting:
> real -- legacy    -- long
> 16bit   32bit pm     64bit pm
>         16bit pm     32bit pm (compatibility)
>         vm86         16bit pm (compatibility)
> 
> dosemu runs in legacy mode but then your x86-64 is just an Athlon on
> steroids and other processes cannot use more than 4GB of memory.
> 
> In long mode there is no vm86.

It looked like the long vs legacy mode could be toggled on a per segment
basis in the rest of the information I pasted.  What do you think that
refers to?

> DOSEMU is intrinsically a little more difficult to configure (primarily
> because it needs an independent DOS rather than having one built in) and
> no matter how good FreeDOS gets it seems there will always be some who
> really want to run another DOS in it.

:)

> At least xdosemu+freedos should be
> as easy as possible (it's been easy since 1.0.2, it's just that extracting two
> tarballs in one's home directory is a little unusual -- that's why I tried
> to simplify the systemwide compilation and installation from source, so
> making RPMs and DEBs should be easy)

The initial setup at least on Debian is a breeze today, it's just
finding the right settings for some application that tends to be the
annoying part, which hopefully gets solved through the application db.

And, many users don't like to hand edit config files, which is why I write
that script to at least partially automate that.

-- 
Ryan Underwood, <nemesis at icequake.net>, icq=10317253

Re: App database, libsynth

[Jan Willem Stumpel]

Bart Oldeman wrote:

> I just keep wondering about the FM devices. The DOSBOX people seem to have
> been able to get that working, so what is special about DOSBOX that is so
> difficult in DOSEMU?
> [..]
> In any case whatever works better in DOSBOX (e.g. parts of VGAEMU still I
> think) can be looked up in the source code; [..]

Yes, that would be an excellent course to take. Dosemu has *far*
more things that work than dosbox, but there are some things in
dosbox that dosemu could use:

-- vga (test with Captain Comic)
-- music (test with Wolf3d; it works on my system without a
   'hardware mixing' sound card)

So how about pasting the code directly from dosbox? I wish I could
do it myself but I lack the skill...

Regards, Jan

Re: App database, libsynth

[Ryan Underwood]

Hi Jan,

On Sat, Jul 12, 2003 at 06:30:44PM +0200, Jan Willem Stumpel wrote:
> Bart Oldeman wrote:
> 
> > I just keep wondering about the FM devices. The DOSBOX people seem to have
> > been able to get that working, so what is special about DOSBOX that is so
> > difficult in DOSEMU?
> > [..]
> > In any case whatever works better in DOSBOX (e.g. parts of VGAEMU still I
> > think) can be looked up in the source code; [..]
> 
> Yes, that would be an excellent course to take. Dosemu has *far*
> more things that work than dosbox, but there are some things in
> dosbox that dosemu could use:
> 
> -- vga (test with Captain Comic)

Doesn't Captain Comic only use the EGA?

-- 
Ryan Underwood, <nemesis at icequake.net>, icq=10317253

Re: App database, libsynth

[Jan Willem Stumpel]

Ryan Underwood wrote:

> Doesn't Captain Comic only use the EGA?

I suppose so, but the display is ok in dosbox while in dosemu
certain things are missing (start-up screen, the frame on the
right-hand side).

Regards, Jan

Re: App database, libsynth (now EGA problems)

[Ryan Underwood]

Hi Jan,

On Sat, Jul 12, 2003 at 10:13:29PM +0200, Jan Willem Stumpel wrote:
> Ryan Underwood wrote:
> 
> > Doesn't Captain Comic only use the EGA?
> 
> I suppose so, but the display is ok in dosbox while in dosemu
> certain things are missing (start-up screen, the frame on the
> right-hand side).

In Commander Keen 1/2/3 a small problem can be seen with dosemu's EGA
emulation too.  When the character moves vertically, the screen
scrolling is perfectly smooth.  When the character moves horizontally,
the screen scrolling is very jerky and causes the game to be unplayable.
I don't know if there is a vsync problem there or what.

-- 
Ryan Underwood, <nemesis at icequake.net>, icq=10317253

Re: App database, libsynth (now EGA problems)

[Paul Eggleton]

On Sun, 13 Jul 2003 09:56, Ryan Underwood wrote:
> In Commander Keen 1/2/3 a small problem can be seen with dosemu's EGA
> emulation too.  When the character moves vertically, the screen
> scrolling is perfectly smooth.  When the character moves horizontally,
> the screen scrolling is very jerky and causes the game to be unplayable.
> I don't know if there is a vsync problem there or what.

Is this a recent thing? Having played Keen 1 a bit with DOSEMU, I would have 
said it was one of the better working applications, at least on my system 
with earlier versions of DOSEMU. Maybe a regression?

Cheers,
Paul

Re: App database, libsynth (now EGA problems)

[Ryan Underwood]

Hi Paul,

On Sun, Jul 13, 2003 at 11:22:52AM +1200, Paul Eggleton wrote:
> On Sun, 13 Jul 2003 09:56, Ryan Underwood wrote:
> > In Commander Keen 1/2/3 a small problem can be seen with dosemu's EGA
> > emulation too.  When the character moves vertically, the screen
> > scrolling is perfectly smooth.  When the character moves horizontally,
> > the screen scrolling is very jerky and causes the game to be unplayable.
> > I don't know if there is a vsync problem there or what.
> 
> Is this a recent thing? Having played Keen 1 a bit with DOSEMU, I would have 
> said it was one of the better working applications, at least on my system 
> with earlier versions of DOSEMU. Maybe a regression?

Not sure.  It is definitely jerky with the X11 version (vgaemu) on my
system in 1.1.5.2.

Maybe it'll be the first bug filed when my db is working! :)

-- 
Ryan Underwood, <nemesis at icequake.net>, icq=10317253

Re: App database, libsynth

[Bart Oldeman]

On Sat, 12 Jul 2003, Jan Willem Stumpel wrote:

> So how about pasting the code directly from dosbox? I wish I could
> do it myself but I lack the skill...

it's never that easy :) One uses C++ the other C and the strategies are a
little different (because we partly emulate the CPU and partly look for
dirty memory pages whereas dosbox completely emulates the CPU). It just
makes for another reference apart from vgadoc and RBIL and so on.

Just like the DosBox people say in THANKS:
"Vlad R. of the vdmsound project for excellent sound blaster info.
Tatsuyuki Satoh of the Mame Team for making an excellent FM emulator.
Jarek Burczynski for the new OPL emulator.

The Bochs and DOSemu projects which I used for information.
Freedos for ideas in making my shell."

Bart