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

[Bernhard Bialas]

Hello,
an application database would be great.
For mysel I have made a table which documents the compatibility of my dos 
programs. Regarding your database at http://www.icequake.net/dosemu, I miss a 
field for description of the fault or errormessage and also one for a 
download address. But it should be easy to extend.

I like to encourage you to finish this database.

Thanks
Bernhard Bialas

Re: App database

[Paul Eggleton]

On Thu, 10 Jul 2003 04:21, Ryan Underwood wrote:
> My question is, is this something the DOSEMU developers and users would
> find useful?  

Yes, I think this is a great idea.

Cheers,
Paul

App database

[Ryan Underwood]

Hi,

I sort of hacked together an application compatibility database for
DOSEMU in PHP.  I ran out of motivation to finish it before presenting
it though.

http://www.icequake.net/dosemu

My question is, is this something the DOSEMU developers and users would
find useful?  The idea was to be able to file bugs against a particular
application under a particular DOSEMU version, and also to generate a
ranking of the topmost working applications to show how well DOSEMU
really does work.  DOSEMU developers would be able to
open/reassign/close bugs, regular users would be able to open/amend bugs
and provide success reports.

The difference between this and some huge bugzilla applciation is that
it doesn't need all the bells and whistles and that success reports are
most likely more important to users evaluating a DOSEMU solution,
than bugs.

If there is interest, I will finish it.  I might finish it anyway, but
interested people would help me finish it faster. :)

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