Re: App database

Re: App database

[Stas Sergeev]

Hello.

Ryan Underwood wrote:
> The idea was to be able to file bugs against a particular
>  application under a particular DOSEMU version
I think that can be helpfull. But as the
bottleneck of a dosemu development process is
unfortunately elsewhere, I wouldn't assign the
prio to that your project higher than to your
adlib server:)

> It should function similarly to the WINE application compatibility database.
Just wondering, is/was that possible to reuse
their (or other) code rather than writing your
own?

> whether or not it works with any of the other emulators (FreeBSD doscmd,
> DosBox, Bochs, etc)
Actually testing against NT or 2000 dos box is
the most important. Bochs and doscmd are out of
comparision.

PS: I think there will be problems with your
adlib server as a separate process to mix the
sound with dosemu's SB digital output in real-time.
The adlib server must do a frequent small transferrs
together with taking care about keeping the OSS's
buffers partially filled to avoid underruns.
At the same time dosemu's DMA will write a
large blocks and very infrequently. When the
block from DMA arrives, there is already a data
from an adlib server in a real card's DMA buffers,
and there is no possibility to mix so lately
(unless the hardware permits).
So I beleive the DMA and Adlib sounds will always
interrupt each other, unless they are coordinated
and using an internal mixing (not per your design).
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?

Re: App database, libsynth

[Ryan Underwood]

Hi Stas,

On Thu, Jul 10, 2003 at 09:20:50PM +0400, Stas Sergeev wrote:
> 
> Ryan Underwood wrote:
> >The idea was to be able to file bugs against a particular
> > application under a particular DOSEMU version
> I think that can be helpfull. But as the
> bottleneck of a dosemu development process is
> unfortunately elsewhere, I wouldn't assign the
> prio to that your project higher than to your
> adlib server:)

No problem!

> >It should function similarly to the WINE application compatibility 
> >database.
> Just wondering, is/was that possible to reuse
> their (or other) code rather than writing your
> own?

Possibly.  I felt like hacking something though and started it, but if
anyone has suggestions for a pre-existing software that will do the
trick, that is fine too.  I didn't want to use something huge like
bugzilla because there are too many irrelevant/redundant features, and
it's not really good for a "compatibility database" as far as I can see.

> >whether or not it works with any of the other emulators (FreeBSD doscmd,
> >DosBox, Bochs, etc)
> Actually testing against NT or 2000 dos box is
> the most important. Bochs and doscmd are out of
> comparision.

doscmd actually is quite similar to dosemu, it uses a v86 window to do
its work, but doesn't support lots of nice dosemu features like DPMI.

> PS: I think there will be problems with your
> adlib server as a separate process to mix the
> sound with dosemu's SB digital output in real-time.
> The adlib server must do a frequent small transferrs
> together with taking care about keeping the OSS's
> buffers partially filled to avoid underruns.
> At the same time dosemu's DMA will write a
> large blocks and very infrequently. When the
> block from DMA arrives, there is already a data
> from an adlib server in a real card's DMA buffers,
> and there is no possibility to mix so lately
> (unless the hardware permits).
> So I beleive the DMA and Adlib sounds will always
> interrupt each other, unless they are coordinated
> and using an internal mixing (not per your design).
> 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, or a soundcard that supports hardware streams mixing, will be
required if the user does not have a real OPL* chip.

The other option is to do the mixing internal to dosemu.  But I think
any soundcard that is modern enough to not have a OPL* cell on it should
support multiple opens.  If you think the mixing should be done inside
the application, I will need to re-design the library.

I turned it into plain old libsynth already, because it can support all
sorts of programmable synth using either emulation cores or forwarding
to hardware (CMS chips, C64 SID, etc).  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.

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.  The problem with this is that I don't
know if pthreads are scheduled by the kernel on every platform.  It also
requires the program to have different behavior whether there is real or
emulated hardware. (If you have real hardware, there is no buffer to be
mixed...)  It didn't seem like as flexible a solution.

By the way, has anyone looked at using QEMU in dosemu?

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

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

[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

Re: App database, libsynth

[Stas Sergeev]

Hello.

Ryan Underwood wrote:
>> 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.
Yes. But I was wondering will they be able
to use dmix both. Is it available via the
OSS emulation layer at all?

> Unfortunately OSS emulation blocks when ALSA is in use
OK, so it seems the be not possible to use
the current OSS plugin then...

> so one would have to use a wrapper like aoss to redirect 
> the dosemu OSS output to ALSA.
I don't know about aoss, but the redirectors
like esddsp, artsdsp and the redirector for
NAS (don't remember the name) are unable to
work in O_NONBLOCK mode, which is exactly what
dosemu uses due to a lack of threading.

> I would be curious to find out if XP really got rid of 
> hardware streams mixing or not.
I think that info came to me from Vlad R, but
I was unable to find that message for you so
never mind.

> Yeah.  Also what about sending pc-speaker output to the 
> dsp?
Yes. I wanted to mention that in my previous
posting but was distracted and forgot.
This will require translating the 6-bit PDM
stream to a 8-bit PCM stream. This is very
easy IIRC, I think I've done something like
that in my ZX Spectrum emulator back in 1995.
Dosbox is doing that so (considering other
messages in that ML today) also we have to:)
Would be nice to see that in your lib. This
will require an additional stream, but what's
the deal provided we have the dmix.

>> 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.
There was a discussion in the past where you
said you'll make it the timidity-sequencer alike
plugin for alsa. I was asking about that. Now
It seems you decided to make it completely
standalone.

> 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?
midid is fully functional and together with
timidity it can provide you with General Midi
and (limited) MT-32. I've heard timidity is not
powerfull enough for the *real* MT-32, so they
(dosbox) needed their own code, but I am not
a musician and what timidity produces sounds
rather good for me.

> Is midid a good idea to keep around for the long 
> term?
Yes. Among other things it allows to capture
your favourite music from games into a .mid files.

Re: App database, libsynth

[Ryan Underwood]

Hi Stas,

On Sun, Jul 13, 2003 at 03:47:28AM +0400, Stas Sergeev wrote:
> Hello.
> 
> Ryan Underwood wrote:
> >>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.
> Yes. But I was wondering will they be able
> to use dmix both. Is it available via the
> OSS emulation layer at all?

Unfortunately not without the wrapper.  The dmix is done in userspace,
so writing to /dev/dsp kernel device would bypass it.  The aoss wrapper
intercepts those writes and puts them through alsalib instead, allowing
dmix to be used.

> >Yeah.  Also what about sending pc-speaker output to the 
> >dsp?
> Yes. I wanted to mention that in my previous
> posting but was distracted and forgot.
> This will require translating the 6-bit PDM
> stream to a 8-bit PCM stream. This is very
> easy IIRC, I think I've done something like
> that in my ZX Spectrum emulator back in 1995.
> Dosbox is doing that so (considering other
> messages in that ML today) also we have to:)
> Would be nice to see that in your lib. This
> will require an additional stream, but what's
> the deal provided we have the dmix.

Interesting.  It would fit the model of the library because I am
supporting any synth that is accessed only through port writes and
nothing more complicated like interrupts/DMA.  The PC speaker would seem
to fit that model, so if you have some emulation code, I should be able
to include it.

This would help in portability effort too.

> >>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.
> There was a discussion in the past where you
> said you'll make it the timidity-sequencer alike
> plugin for alsa. I was asking about that. Now
> It seems you decided to make it completely
> standalone.

Yeah, that is going to be a separate thing, since this libsynth supports
any synth you want, whereas there is only MIDI sequencer for the OPL3,
so only a emulated-OPL3 sequencer client would make any sense.

> >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?
> midid is fully functional and together with
> timidity it can provide you with General Midi
> and (limited) MT-32. I've heard timidity is not
> powerfull enough for the *real* MT-32, so they
> (dosbox) needed their own code, but I am not
> a musician and what timidity produces sounds
> rather good for me.

It may be possible to implement another backend to timidity but that
would require more research.

If the timidity/mt-32 emulator becomes an ALSA sequencer client (which
is the optimal situation so it can be used in any ALSA application), how
would dosemu/midid support it?

> >Is midid a good idea to keep around for the long 
> >term?
> Yes. Among other things it allows to capture
> your favourite music from games into a .mid files.

Interesting.  What about making the ALSA sequencer a backend
for midid?

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

Re: App database, libsynth

[Stas Sergeev]

Hello.

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?
AFAIK dosbox people are using an SDL lib for
output, while we are using an OSS directly
and are going to write more plugins.
I wish dosemu to use SDL, pthreads and all
the other tasty things, but it just doesn't.
So for us it will require significantly more
work than for them to add an Adlib.

> http://www.happypenguin.org/show?DOSbox 
> http://www.happypenguin.org/show?DOSbox&start=10
Wery interesting indeed!
Well, after all I can understand their reasons:
they are comparing 1.0.2 most likely, as a last
"very stable" version and this is understandable
after all.
Also some people claim dosemu crashes their system
even without being root. It is no longer possible
since linux-2.4.20, but they haven't specified the
kernel they used, so they blame dosemu instead.
Configuring dosemu is now trivial, but again, they
were comparing against 1.0...
So probably that was not a FUD, but rather a
consequence of the fact that dosemu had recently
celebrated its first decade of existance, but there
is still no a version that is both really and officially
stable. But that can be changed eventually.

>> > 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.
Unfortunately that makes no difference at all: the
coopthreads/qemu problem was triggering only when
comcom or "unix -e" was used. Now "unix -e" is safe,
but comcom, still being a default, keeps the problem
exactly where it was. Initialisation of coopthreads
didnt raised the problem and even using a builtins was
possible.
But I accept the fact that freecom needs some work
before it can be used.

Re: App database, libsynth

[Stas Sergeev]

Hello.

Ryan Underwood wrote:
>> 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?
Note the "real mode" in the quote above.

> 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."
Note the "protected-mode" in the quote above.
See? :)

> Which means to me, that vm86()
You might have confused the v86 mode with 16-bit
protected mode. There is nothing about vm86() in
what you have quoted from the docs.

> 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.
That will not give you the v86 mode however.

Re: App database, libsynth

[Ryan Underwood]

Hi Stas,

On Sun, Jul 13, 2003 at 04:21:04AM +0400, Stas Sergeev wrote:
> Hello.
> 
> Ryan Underwood wrote:
> >>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?
> Note the "real mode" in the quote above.
> 
> >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."
> Note the "protected-mode" in the quote above.
> See? :)

Okay, I gathered from "protected-mode environment" that it would be like
a DOS box running under Win95, a protected mode environment.  But they
are saying that in this example, it would be Win95's view of the system,
not the DOS program's view.

So under longmode there will be no more vm86() and we will definitely
need to use QEMU.  So the "compatibility mode" is only good for running
the 32-bit applications while in longmode. Correct?

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

Re: App database, libsynth

[Stas Sergeev]

Hello.

Ryan Underwood wrote:
>> 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?
That refers to that you seem like confusing
the legacy mode with the compatibility mode.
See this about switching:
http://www.x86-64.org/lists/discuss/msg03333.html

For now the decision was AFAIK to not mess with
vm86() in x86-64 linux port. That may sound sad
for us, but I guess they had some reasons for
doing so.

Re: App database, libsynth

[Ryan Underwood]

Hi Stas,

On Sun, Jul 13, 2003 at 04:29:36AM +0400, Stas Sergeev wrote:
> Hello.
> 
> Ryan Underwood wrote:
> >>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?
> That refers to that you seem like confusing
> the legacy mode with the compatibility mode.
> See this about switching:
> http://www.x86-64.org/lists/discuss/msg03333.html

Yes, that clears it up.  So the legacy mode can only be enabled by
rebooting the system since it is too difficult to switch between legacy
and longmode on the fly.  Furthermore, all the compatibility mode is
good for is running 32-bit applications in longmode.

> For now the decision was AFAIK to not mess with
> vm86() in x86-64 linux port. That may sound sad
> for us, but I guess they had some reasons for
> doing so.

I think most people will be using longmode on AMD-64 anyhow, so we
should get the fast CPU emulation going as soon as possible.

Side effect of the CPU emulation : can we do things with it like run
Win95 or other VCPI program underneath DOSEMU?

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

Re: App database, libsynth

[Stas Sergeev]

Hello.

Ryan Underwood wrote:
>> Yes. But I was wondering will they be able to use dmix
>>  both. Is it available via the OSS emulation layer at 
>> all?
> Unfortunately not without the wrapper.  The dmix is done
>  in userspace, so writing to /dev/dsp kernel device would
>  bypass it.  The aoss wrapper intercepts those writes and
>  puts them through alsalib instead, allowing dmix to be 
> used.
That practically means using dosemu's OSS output
plugin will not be possible that way. It does all
the possible things to make it not compatible
with any redirectors. Leaving apart the nonblocking
I/O, it also writes a partial fragments, demands
the precise quering of a current buffer load and
all the other weird things, so it is not compatible
even with most of the third-party OSS drivers.
But have you tried it with aoss? I have to port my
pcsp driver to ALSA before I can do that.

> The PC speaker would seem to fit that model, so if you 
> have some emulation code, I should be able to include it.
Unfortunately I don't have anything like that.
The program I was referring to, was written in
Pascal.
You can also have a look in my pcsp driver, but
it does only the PCM->PDM conversion and not
the vice-versa (no recording via speaker:),
and also the code there is complicated by a
software amplification tricks.
Finally you may want to steal the code from a
dosbox, but it is in C++.
There are some explanation about PDM (aka PWM)
on the net in case you are wondering:
http://www.wikipedia.org/wiki/Pulse-width_modulation
http://www.powerdesigners.com/InfoWeb/design_center/articles/PWM/pwm.shtm
http://www.netrino.com/Publications/Glossary/PWM.html

> If the timidity/mt-32 emulator becomes an ALSA sequencer
>  client (which is the optimal situation so it can be used
>  in any ALSA application), how would dosemu/midid support
>  it?
No modifications at all. See sound-usage.txt
about how to use dosemu->ALSA->timidity. This
is quite fundamental and doesn't require midid.
But to keep the midid up-to-date, probably some
small modification to the midid's timidity
frontend will be required, as currently it
assumes that only GM is supported. That is for
the OSS users, as ALSA users doesn't need midid
at all.

> Interesting.  What about making the ALSA sequencer a 
> backend for midid?
No, actually there is an overlap of a functionality.
midid is also a kind of a sequencer. It receives the
same data on input the alsa sequencer receives. It
can't work after/before the ALSA sequencer because
they are doing the similar job. Only the output is
different: midid talks to timidity's server interface,
while alsa talks to timidity's alsaseq interface.

> So under longmode there will be no more vm86() and we 
> will definitely need to use QEMU.
Unless someone will finally implement it, which
is unlikely but not impossible: after all also X vesa
driver uses it, and so does wine, so there might be
some motivation after all...
The syscall will have to switch the CPU between the
longmode and the legacy mode, which is possible, as
per the link in a previous posting.

> So the "compatibility mode" is only good for running the 
> 32-bit applications while in longmode. Correct?
No: 16 bit is also OK.

> I think most people will be using longmode on AMD-64 
> anyhow, so we should get the fast CPU emulation going as 
> soon as possible.
The speed is not a problem on that CPUs I
guess. The problem is to make a relatively bug-free
CPU emulator. Lets see if the qemu people can do
that, otherwise qemu will add bugs to dosemu, while
dosemu has plenty of its ows ones:)

> Side effect of the CPU emulation : can we do things with
> it like run Win95 or other VCPI program underneath
> DOSEMU?
I think it will be possible. Right now qemu can
run Linux kernel itself, so running
linux->dosemu->qemu->win95 might also be possible.

Re: App database, libsynth

[Ryan Underwood]

Hi Stas,

On Sun, Jul 13, 2003 at 06:37:56AM +0400, Stas Sergeev wrote:
> Hello.
> 
> Ryan Underwood wrote:
> >>Yes. But I was wondering will they be able to use dmix
> >> both. Is it available via the OSS emulation layer at 
> >>all?
> >Unfortunately not without the wrapper.  The dmix is done
> > in userspace, so writing to /dev/dsp kernel device would
> > bypass it.  The aoss wrapper intercepts those writes and
> > puts them through alsalib instead, allowing dmix to be 
> >used.
> That practically means using dosemu's OSS output
> plugin will not be possible that way. It does all
> the possible things to make it not compatible
> with any redirectors. Leaving apart the nonblocking
> I/O, it also writes a partial fragments, demands
> the precise quering of a current buffer load and
> all the other weird things, so it is not compatible
> even with most of the third-party OSS drivers.
> But have you tried it with aoss? I have to port my
> pcsp driver to ALSA before I can do that.

Just tried aoss.  It didn't work too horribly on the ones I tried
(Duke3D, Hardball III).  The sound warbles and there are lots of
clicking, but overall it could be a lot worse.  Also some sound is
repeated, like there is a buffer underrun and the buffer gets wraped
around, or something like that.  Duke3D sounds pretty good which
surprised me a lot, considering it is hard on the sound card, and my
Vortex driver is still in pre-alpha for ALSA. :)

> >The PC speaker would seem to fit that model, so if you 
> >have some emulation code, I should be able to include it.
> Unfortunately I don't have anything like that.
> The program I was referring to, was written in
> Pascal.
> You can also have a look in my pcsp driver, but
> it does only the PCM->PDM conversion and not
> the vice-versa (no recording via speaker:),
> and also the code there is complicated by a
> software amplification tricks.

Just to make sure, the PC speaker needs no programming besides writing
to the two hardware ports, correct?

> >If the timidity/mt-32 emulator becomes an ALSA sequencer
> > client (which is the optimal situation so it can be used
> > in any ALSA application), how would dosemu/midid support
> > it?
> No modifications at all. See sound-usage.txt
> about how to use dosemu->ALSA->timidity. This
> is quite fundamental and doesn't require midid.
> But to keep the midid up-to-date, probably some
> small modification to the midid's timidity
> frontend will be required, as currently it
> assumes that only GM is supported. That is for
> the OSS users, as ALSA users doesn't need midid
> at all.

I see that now.  Very nice.  I wonder if there is an easier way to set
the MIDI up than making the user manually connect pipes with MIDI
devices.  Perhaps dosemu could use a launcher program of some sort?

> >Interesting.  What about making the ALSA sequencer a 
> >backend for midid?
> No, actually there is an overlap of a functionality.
> midid is also a kind of a sequencer. It receives the
> same data on input the alsa sequencer receives. It
> can't work after/before the ALSA sequencer because
> they are doing the similar job. Only the output is
> different: midid talks to timidity's server interface,
> while alsa talks to timidity's alsaseq interface.

Hmm, so what's the best way to use a OPL3-emulated sequencer from
dosemu?  If I make it an ALSA client, people using midid will not be
able to use it.  If I make it a server application that midid talks to,
it is less flexible for the people who could use it through ALSA
applications.

I could do both but that takes a lot of time. :)

> >So under longmode there will be no more vm86() and we 
> >will definitely need to use QEMU.
> Unless someone will finally implement it, which
> is unlikely but not impossible: after all also X vesa
> driver uses it, and so does wine, so there might be
> some motivation after all...

What does wine use it for?  I think XFree86 uses it for Int10 support
too.

> >So the "compatibility mode" is only good for running the 
> >32-bit applications while in longmode. Correct?
> No: 16 bit is also OK.

But not 16-bit realmode applications or 32-bit ring0 applications
either?

> >I think most people will be using longmode on AMD-64 
> >anyhow, so we should get the fast CPU emulation going as 
> >soon as possible.
> The speed is not a problem on that CPUs I
> guess. The problem is to make a relatively bug-free
> CPU emulator. Lets see if the qemu people can do
> that, otherwise qemu will add bugs to dosemu, while
> dosemu has plenty of its ows ones:)

:)

> >Side effect of the CPU emulation : can we do things with
> >it like run Win95 or other VCPI program underneath
> >DOSEMU?
> I think it will be possible. Right now qemu can
> run Linux kernel itself, so running
> linux->dosemu->qemu->win95 might also be possible.

Those VCPI-games should be taken care of like that too, Privateer,
Strike Commander et.al.

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

Re: App database, libsynth

[Stas Sergeev]

Hello.

Ryan Underwood wrote:
> Just tried aoss.  It didn't work too horribly on the ones
>  I tried (Duke3D, Hardball III).  The sound warbles and 
> there are lots of clicking, but overall it could be a lot
>  worse.
Better than I expected, at least a nonblocking
IO is not a problem. But all that clicks and
underruns you see are most likely due to an
inaccurate buffer load reporting. It is difficult
to report the "expected" buffer load after the
resampling and mixing are performed.

> Just to make sure, the PC speaker needs no programming 
> besides writing to the two hardware ports, correct?
Which ones do you mean?
There is only one port to control the
speaker - 0x61. But one have to also
program a PIT channel 0 and 2 to do the
PWM, which uses 3 more ports.
So you have to define the interface for
client to provide the timestamps to your
lib for the decoding.

> Hmm, so what's the best way to use a OPL3-emulated 
> sequencer from dosemu?
The *only* way I can think of, is simply
passing the raw data that the app is writing
to the OPL3 ports.
Midi is an absolutely different thing here.
Dosemu emulates the MPU-401 UART, so for
midi it is able to produce the raw midi stream
which can be interpreted by midid and passed
to a sequencer (or handled internally by one
of the midid plugins).

> If I make it an ALSA client, people using midid will not 
> be able to use it.  If I make it a server application 
> that midid talks to, it is less flexible for the people 
> who could use it through ALSA applications.
There might be some misunderstanding.
The OPL3 software synthesizer can be used in
two ways:
1. It implements a sequencer interface *for midi*.
The app (like midid) writes the midi messages
to it, and the lib is trying to generate some music
for them (yes, OPL3 is not very good for midi
I would say, but I know several DOS  midi players
that can use OPL3 as an output device).
This is good to have in general, but it
has zero use for dosemu. Dosemu/midid can work with
timidity, which does much better than an OPL3
synthesizer can do for midi.
2. It implements an OPL3 emulator, i.e. provides
its ports and produces some sound output (or the
midi output, like the bochs does IIRC).
In this case only dosemu can use it, but then
it will be used not for playing midi (which is
done by timidity much better anyway), but rather
for emulating the Adlib.

So:
>> If I make it an ALSA client, people using midid will 
>> not be able to use it.
You seem to be talking about the way (1) here.
I am sure midid doesn't need to use your libsynth
at all because it can use timidity. OTOH writing
an alsa-alike plugin for midid is very easy
because it will be much similar to midid's current
timidity plugin.

> If I make it a server application
>> that midid talks to, it is less flexible for the people
>>  who could use it through ALSA applications.
The same, midid doesn't need the libsynth at all,
but it is very flexible and can mimic the alsa.

> I could do both but that takes a lot of time. :)
I think you *have* to do both, otherwise your
lib would be useless.

Overall I might be misunderstanding you, but it
seems to me that you have confused the midi with
an OPL synth, which are very different and orthogonal
things. They have different code pathes inside dosemu
and must have different pathes outside it. So
essentially midid cannot be used for an OPL synth.
In short: you can use OPL synth for emulating an
Adlib, *or* as a midi sequencer (like timidity). For
dosemu it is important to have an Adlib emulation,
because the midi support is already in place, but
you can do both.

>> is unlikely but not impossible: after all also X vesa 
>> driver uses it, and so does wine, so there might be 
>> some motivation after all...
> What does wine use it for?
Dos emulation:)
Wine has an SB and DMA emulation for DOS progs even
AFAIK.

> I think XFree86 uses it for Int10 support too.
Yes, that's what I reverred to as "X vesa driver".

>>> So the "compatibility mode" is only good for running 
>>> the 32-bit applications while in longmode. Correct?
>> No: 16 bit is also OK.
> But not 16-bit realmode applications or 32-bit ring0 
> applications either?
Seems like that.

> Those VCPI-games should be taken care of like that too,
> Privateer, Strike Commander et.al.
I don't understand why the game would require a
ring-0 access. I think that is a bad design so I
wouldn't care too much about it. The authors must
fix that games, use a proper extender or whatever.
I hope there are not too much of those.
But VCPI would be good to have after all:)

Re: App database, libsynth

[Ryan Underwood]

Hi Stas,

On Sun, Jul 13, 2003 at 11:50:05PM +0400, Stas Sergeev wrote:
> >Just to make sure, the PC speaker needs no programming 
> >besides writing to the two hardware ports, correct?
> Which ones do you mean?
> There is only one port to control the
> speaker - 0x61. But one have to also
> program a PIT channel 0 and 2 to do the
> PWM, which uses 3 more ports.
> So you have to define the interface for
> client to provide the timestamps to your
> lib for the decoding.

Ok, will look into this more.

> >If I make it an ALSA client, people using midid will not 
> >be able to use it.  If I make it a server application 
> >that midid talks to, it is less flexible for the people 
> >who could use it through ALSA applications.
> There might be some misunderstanding.
> The OPL3 software synthesizer can be used in
> two ways:
> 1. It implements a sequencer interface *for midi*.
> The app (like midid) writes the midi messages
> to it, and the lib is trying to generate some music
> for them (yes, OPL3 is not very good for midi
> I would say, but I know several DOS  midi players
> that can use OPL3 as an output device).
> This is good to have in general, but it
> has zero use for dosemu. Dosemu/midid can work with
> timidity, which does much better than an OPL3
> synthesizer can do for midi.
> 2. It implements an OPL3 emulator, i.e. provides
> its ports and produces some sound output (or the
> midi output, like the bochs does IIRC).
> In this case only dosemu can use it, but then
> it will be used not for playing midi (which is
> done by timidity much better anyway), but rather
> for emulating the Adlib.

Yes, I am talking about both ways.  the 1st is where the opl3-emulated
ALSA sequencer client is used,  the 2nd is where libsynth is used.

> Overall I might be misunderstanding you, but it
> seems to me that you have confused the midi with
> an OPL synth, which are very different and orthogonal
> things.

Definitely not :)
Any program in DOS that writes to OPL port goes to libsynth.  That
includes DOS programs that program the synth directly, or even a DOS
program that plays midi files through OPL.

However, the user might like to use an OPL-emulated chip for playing
MIDI music from DOS programs that don't support OPL for music.  The
DOS program would write to MPU-401, the data would go to the sequencer, and
the sequencer would use the emulated OPL3 that is connected to it to
play the MPU-401 data.

> >Those VCPI-games should be taken care of like that too,
> >Privateer, Strike Commander et.al.
> I don't understand why the game would require a
> ring-0 access. I think that is a bad design so I
> wouldn't care too much about it. The authors must
> fix that games, use a proper extender or whatever.
> I hope there are not too much of those.
> But VCPI would be good to have after all:)

Yes it is a very bad design, but I've waited a long time to play
Privateer under DOSEMU. :)

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

Re: App database, libsynth

[Stas Sergeev]

Hello.

Ryan Underwood wrote:
>> Overall I might be misunderstanding you, but it
> Definitely not :)
Then why do you think it is necessary for
midid to use your server? For overall
completeness? Do it an ALSA-compatible I
would say, and if someone is ever to find
it usefull for midid to talk to your OPL3
server, that can be easily implemented, but
I don't think it can have any use.

> However, the user might like to use an OPL-emulated chip
> for playing MIDI music from DOS programs that don't
> support OPL for music.
Yes, but what's the use? What is the use??
Is it because someone have a very limited
internet connection to download the timidity
and all the samples for it? Or too slow CPU
to power up the timidity? But I think MAME
OPL emu eats even more CPU than the timidity
does:)
OK, never mind. If you do that lib and you
think it is usefull for midid to be able to
use it - then it is.

Re: App database, libsynth

[Ryan Underwood]

Hi Stas,

On Mon, Jul 14, 2003 at 09:43:58PM +0400, Stas Sergeev wrote:
> Hello.
> 
> Ryan Underwood wrote:
> >>Overall I might be misunderstanding you, but it
> >Definitely not :)
> Then why do you think it is necessary for
> midid to use your server? For overall
> completeness? Do it an ALSA-compatible I
> would say, and if someone is ever to find
> it usefull for midid to talk to your OPL3
> server, that can be easily implemented, but
> I don't think it can have any use.

Ok :)

> >However, the user might like to use an OPL-emulated chip
> >for playing MIDI music from DOS programs that don't
> >support OPL for music.
> Yes, but what's the use? What is the use??
> Is it because someone have a very limited
> internet connection to download the timidity
> and all the samples for it? Or too slow CPU
> to power up the timidity? But I think MAME
> OPL emu eats even more CPU than the timidity
> does:)

Nah, some people (like me) just like that FM sound.  Perhaps I am crazy?
:) Probably...

> OK, never mind. If you do that lib and you
> think it is usefull for midid to be able to
> use it - then it is.

The lib for direct access comes first priority because we need working
FM in dosemu.  Currently I have it spawning a synthd and talking to it,
but sometimes it doesn't clean up after itself, and the concurrent
usage of libsynth by multiple programs is not working.  Also I need to
hack dosemu to use it, I am testing it only with wolf3d for the moment.

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

Re: App database, libsynth

[Paul Eggleton]

On Tue, 15 Jul 2003 09:06, Ryan Underwood wrote:
> Nah, some people (like me) just like that FM sound.  Perhaps I am crazy?

No, I prefer to play old DOS games with FM too. Wavetable just doesn't sound 
the same.

Cheers,
Paul

Re: App database, libsynth

[Ryan Underwood]

Hi Paul,

On Tue, Jul 15, 2003 at 08:38:59PM +1200, Paul Eggleton wrote:
> On Tue, 15 Jul 2003 09:06, Ryan Underwood wrote:
> > Nah, some people (like me) just like that FM sound.  Perhaps I am crazy?
> 
> No, I prefer to play old DOS games with FM too. Wavetable just doesn't sound 
> the same.

Actually, in that context, we were talking about sending MIDI data to an
emulated FM chip.  (i.e., data that was meant for a midi synth on the
MPU-401 port).  This is a rather unorthodox application of an FM
synthesis chip, which is why Stas was questioning it. :)

Playing DOS games with the FM synthesis should be no problem and is the
point of the emulation in the first place, just needs to get enough time
from dosemu and a concurrent process seems the best way to do that at
this moment.

Argh! I need to work on this...

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

Re: App database, libsynth

[Paul Eggleton]

On Tue, 15 Jul 2003 22:10, Ryan Underwood wrote:
> Actually, in that context, we were talking about sending MIDI data to an
> emulated FM chip.  (i.e., data that was meant for a midi synth on the
> MPU-401 port).  This is a rather unorthodox application of an FM
> synthesis chip, which is why Stas was questioning it. :)

Ah, I hadn't followed the thread closely enough... yes, that is a bit odd. 
However I have to say I never (at least knowingly) used MPU-401 with any of 
the DOS games I played.

> Playing DOS games with the FM synthesis should be no problem and is the
> point of the emulation in the first place, just needs to get enough time
> from dosemu and a concurrent process seems the best way to do that at
> this moment.

Well it sounds like a good idea to me, FWIW, unless you want to use threads to 
accomplish the same thing.

> Argh! I need to work on this...

I feel bad because I promised Stas I would help out with the sound code a 
while back, but as yet I haven't been able to set aside any time to actually 
do any work on it :(

If you can point out any specific areas you might need help with I'll see what 
I can do (simple stuff is fine, I can code C but I have done only a very 
little real DOS programming and no sound programming to speak of).

Cheers,
Paul

Re: App database, libsynth

[Ryan Underwood]

Hi Paul,

On Wed, Jul 16, 2003 at 12:26:48AM +1200, Paul Eggleton wrote:
> > Argh! I need to work on this...
> 
> I feel bad because I promised Stas I would help out with the sound code a 
> while back, but as yet I haven't been able to set aside any time to actually 
> do any work on it :(
> 
> If you can point out any specific areas you might need help with I'll see what 
> I can do (simple stuff is fine, I can code C but I have done only a very 
> little real DOS programming and no sound programming to speak of).

Well, this is probably as good a time and place as ever to discuss the
library design.  Won't really go into excruciating detail here, but it
should give a good idea what i'm after.

int SynthOpen(synthlist_t model, preference_t preference, panning_t
panning) { }

This function is called by the programmer before he wants to use a
particular synth.  The program needs to figure out what type of synth it
wants to use, based on the options the user picks probably, or default
behavior.

If a program wants a OPL2 synth:

if (!SynthOpen(SYNTH_OPL2, PREFER_REAL, PANNING_MONO)) {
	printf("No OPL2 available, disabling sound\n");
	...
}

SYNTH_OPL2 is an enumeration that specifies that we want a YM3812
device.

PREFER_REAL means that we want to use real hardware if available, else
fall back to an emulated device if it can be created.  The PREFER_REAL
does hardware detection of the relevant device, and if the hardware
detection fails, it tries to create an emulated device instead.
Some synth chips cannot be hardware detected, so PREFER_REAL is
equivalent to DEMAND_REAL in those cases -- the real chip will be
attempted to used regardless of whether we know it exists or not.

PANNING_MONO is only relevant in the case that we create an emulated
device.  It specifies the output channel(s) of the dsp that the emulated
output will be written to.  In this case, the programmer probably wanted
the equivalent of an AdLib card or the 0x388 port on a soundblaster
card; any writes to it will produce sound that goes to both channels.

If you wanted to emulated a SB Pro with dual OPL2, you could create two
SYNTH_OPL2 PREFER_EMULATED devices one on PANNING_LEFT and one on
PANNING_RIGHT.  Then program them just like 0x220-0x223 on a SB Pro.


If SynthOpen() succeeds, it returns a int which is the library slot
for that synth.  That int can be used like a handle for that particular
synth.  You can SynthWrite(synthno, addr, data) and if the real hardware
is being used, it will simply be passed through, and if an emulated
hardware is being used, it sends it to the emulator daemon.  The
emulator daemon since it is scheduled independently of the parent
process, internally updates its state on a continuous basis and writes
the result to the dsp (or to a file).

The design is simple to me.  The programmer of the application need do
nothing but SynthOpen the correct devices, and then SynthWrite the data
to them.

The emulator daemon, synthd, is spawned when the library first
encounters a need for an emulated device.  IPC is done through a
unix socket with the library.  synthd is multi-threaded and can handle
emulation of as many different synth devices concurrently as the library is
allowed to create.  The output of all the synth devices is mixed and
written to the dsp.  so you could have an emulated SID-chip as well as a
OPL3 or something all at the same time.  Or perhaps a POKEY on the left
channel and a PC speaker on the right.  The possibilities are very open.

Plan to support the following synths in the library, all can be
either hardware or emulated:

        SYNTH_PCSP = 0, /* PC Speaker */
        SYNTH_OPL,      /* YM3526 */
        SYNTH_OPL2,     /* YM3812 */
        SYNTH_OPL3,     /* YMF262 */
        SYNTH_PCJR,     /* TI-SN76496 */
        SYNTH_SID,      /* MOS 6581 */
        SYNTH_SID2,     /* MOS 8580 */
        SYNTH_NES,      /* Ricoh 2A03 */
        SYNTH_POKEY,    /* Atari 400/800 POKEY */

Though right now I only implement OPL2 for the DOSEMU project to have
something to work with.  Note that for a particular synth to fit the design
of this library, it needs to be able to be programmed through simply
reading and writing address and data pairs.  So chips that need IRQ-lines
or DMA and such are not candidates.  The OPL-chip has an internal IRQ but
it can be triggered or cleared by simply writing to the OPL's port.

synthd checks regularly for the existence of the parent process, and when the
parent process pid/argv[0] pair no longer exists, it self-terminates so a
bunch of synthd are not left hanging around.  I don't think synthd is incredibly
useful without libsynth managing it, so this does not seem to be a problem.

Any comments, ideas?

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

Re: App database, libsynth

[Stas Sergeev]

Hello.

Ryan Underwood wrote:
> The design is simple to me.  The programmer of the 
> application need do nothing but SynthOpen the correct 
> devices, and then SynthWrite the data to them.
Sounds good. It would probably be a good
idea to provide an optional way to query
user's time and request the timer events
from user. It may be that the user's time
is different than the real time. dosemu
uses the real time, but AFAIK dosbox uses
the emulated time (CPU-emu relative).
It may also be possible that the real card's
sampling rate is not very precise (the pcsp
driver rounds the sampling rate rather cruely),
in which case you'll have one more timing
source with which you also have to keep in
sync. Last time I dealt with all that mess,
it wasn't very simple (see linux_sound.c :)

> Plan to support the following synths in the library, all 
> can be either hardware or emulated:
How are you accessing the hardware btw?
ioperm() ?

> or DMA and such are not candidates.
Yes, DMA is out of question, that's for sure.

> The OPL-chip has an internal IRQ but it can be triggered
> or cleared by simply writing to the OPL's port.
AFAIK it is not even connected to any of
the PIC wires, but why can't you provide an
optional way to notify the user about an IRQ?
Simply calling the user's registered call-back
function might just do the trick, so why not?

Re: App database, libsynth

[Ryan Underwood]

Hi Stas,

On Thu, Jul 17, 2003 at 08:07:25PM +0400, Stas Sergeev wrote:
> Hello.
> 
> Ryan Underwood wrote:
> >The design is simple to me.  The programmer of the 
> >application need do nothing but SynthOpen the correct 
> >devices, and then SynthWrite the data to them.
> Sounds good. It would probably be a good
> idea to provide an optional way to query
> user's time and request the timer events
> from user. It may be that the user's time
> is different than the real time. dosemu
> uses the real time, but AFAIK dosbox uses
> the emulated time (CPU-emu relative).
> It may also be possible that the real card's
> sampling rate is not very precise (the pcsp
> driver rounds the sampling rate rather cruely),
> in which case you'll have one more timing
> source with which you also have to keep in
> sync. Last time I dealt with all that mess,
> it wasn't very simple (see linux_sound.c :)

Ok, I will look into this.

> >Plan to support the following synths in the library, all 
> >can be either hardware or emulated:
> How are you accessing the hardware btw?
> ioperm() ?

For the OPL chips, I use the direct-FM API of OSS/ALSA.  (This is not
implemented yet because I do not have a working OPL-chip on my
soundcard.  I will swap out my card with SB16 to test it or else hack
the vortex driver to get FM access).

For any other chips, it will have to use iopl(3).  I can create ALSA
hwdep driver to handle all the other chips, but I might wait until
people wiht the actual hardware request the capability. :)

But the design of the library does not exclude it.

> >The OPL-chip has an internal IRQ but it can be triggered
> >or cleared by simply writing to the OPL's port.
> AFAIK it is not even connected to any of
> the PIC wires, but why can't you provide an
> optional way to notify the user about an IRQ?
> Simply calling the user's registered call-back
> function might just do the trick, so why not?

You have a good point, I will look into this.

I rewrote the library last few days, now having trouble with some
"chainsaw" noise in wolf3d music. :)  Hopefully won't be hard too
fix.

Thanks,

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