Re: [Freedos-devel] 386MAX

[Volkert via Freedos-devel]

Thanks for figuring out how to build this at least in some way, and sharing
the results of that work, Rodrigo!

It's unfortunate to read that you discovered binary blobs in the code base
that are apparently needed to build 386MAX.

Could anybody here maybe shed some light on the feasibility of replacing
these blobs with open-source alternatives, or barring that, a legally sound
way of reverse-engineering them? The Windows compatibility is exactly the
feature that made 386MAX so interesting in the first place.

On Mon, Mar 20, 2023 at 5:14 AM Rodrigo Morette  wrote:

> Hey all,
>
> I have been playing around with these sources, a minimal "working" build
> is possible with 386MAX.SYS and 386MAX.VXD.
>
> But there is a problem who inviabilizes an OSS build: 386MAX.VXD
> statically link 3 proprietary objects who seems to be from a development
> kit made by Microsoft: LOADHI.OBJ, INSTINIT.OBJ and INSTSWAP.OBJ. A quick
> search shows these files are related to EMM386, looks like the Windows
> compatibility comes from these libraries.
>
> There are also some files from Windows DDK in the include directories.
>
> I plan to keep my attempt to rebuild MAX just for fun as it cannot be
> considered reliable for any major OSS project... I left the sources (no
> proprietary files included) for this minimal build with the serial code
> verification disabled here: https://github.com/rmorette/MAX
>
> Rodrigo.
>
> On Tue, Mar 7, 2023 at 6:56 PM Volkert via Freedos-devel <
> freedos-devel@lists.sourceforge.net> wrote:
>
>>
>>
>> On Mon, Mar 6, 2023 at 7:45 PM Bret Johnson  wrote:
>>
>>>
>>> Or just take some of the important stuff that Bob Smith and Qualitas
>>> discovered about Windows/GEMMIS/EMM386 and import it into something like
>>> JEMM.  There's some knowledge embedded in 386MAX about what MS did that you
>>> will never directly get out of MS.
>>
>>
>> I already opened a ticket for this on GitHub
>> <https://github.com/Baron-von-Riedesel/Jemm/issues/5> a few years ago,
>> but Japheth (a.k.a. Baron-von-Riedesel on GitHub) has expressed
>> reluctance to implement this functionality in Jemm, unfortunately.
>>
>> By the way, DOSBox already has an open-source GEMMIS implementation
>> <https://sourceforge.net/p/dosbox/code-0/2601/>, which would likely be
>> easier to port to Jemm than any of the 386MAX sources.
>>
>> I was hoping that 386MAX could ship with FreeDOS as an alternative EMM
>> manager because there appeared to be no near-term prospect of having GEMMIS
>> support (and thus Windows 3.x 386 Enhanced mode compatibility) added to
>> Jemm. Also, since 386MAX implements the same port trapping API as that of
>> Microsoft EMM386, I was hoping that it would offer compatibility with
>> certain drivers and emulators such as SoftMPU, which don't work with Jemm.
>>
>> At least there's some encouraging news on that front, in the form of a
>> Jemm Loadable Module that adds support for QPI (QEMM's port trapping API),
>> or a subset of it. Baron-von-Riedesel recently developed that module, so
>> crazii's recently developed Sound Blaster emulator called SBEMU
>> <http://gitlab.com/crazii/SBEMU> (also a very promising project for
>> FreeDOS!) can work with Jemm.
>>
>> So GEMMIS support appears to be the one missing feature that would make
>> Jemm a complete replacement for all the known EMM managers of old (EMM386,
>> QEMM, 386MAX).
>>
>> But perhaps if someone creates a pull request for adding GEMMIS support
>> to Jemm, Japheth might be persuaded to merge it. (Although he has expressed
>> skepticism towards that as well.)
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS

[Volkert via Freedos-devel]

On Wed, Mar 8, 2023 at 11:35 AM tom ehlert  wrote:

>
> > Over a month ago, I opened an issue on the FreeDOS project on
> > GitLab about the Open Watcom v2 installer being extremely slow in
> > FreeDOS. It takes an hour or more on FreeDOS, while the same
> > installation completes on MS-DOS 7.1 within just a few minutes.
>
> either you report your config.sys and autoexec.bat for both tests
> or your report is basically useless.
>
> write caching smartdrv (which freedos is known not to have) makes a
> HUGE difference for installers, so you are comparing apples to oranges.
>
> of course running both without autoexec/config.sys would place them on
> an equal playing field.


OK, that's a fair point. When I have time again, I'll try to do more of an
apples-and-apples comparison between the two, and then I'll share my
findings here.

An installation time of an hour still seems excessively slow though, even
when no disk cache is loaded.

What added value does that issue reporting project on GitLab have over this
mailing list, by the way? Is it actively used, or is it expected to in the
future?

Thanks.
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS

[Volkert via Freedos-devel]

On Wed, Mar 8, 2023 at 2:02 AM Ralf Quint  wrote:

> Well, I just download both v1.9 and the latest 2.0 and the later is 1.75x
> as big as v1.9 (143MB vs 81MB), so there must be some more than trivial
> difference between the installers...
>

I was referring specifically to the DOS installer code within the sources.
The side of the payloads may (the stuff being installed by the installer)
may indeed have changed considerably.
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Goo gle Summer of Code?

[Volkert via Freedos-devel]

You might want to take a look at the VMusic project by javispedro
. It's an
open-soure extension pack for VirtualBox that enhances sound emulation
support, notably adding high quality OPL3 FM synthesis emulation and
MPU-401 emulation with MIDI passthrough to the host. It only supports Linux
hosts, though. Perhaps this extension pack could be further improved by
having it include an alternative SB16 emulation option that would implement
the fixes suggested in that VirtualBox ticket.

On Fri, Jan 27, 2023 at 6:24 PM Ben Collver  wrote:

> On Fri, 27 Jan 2023 at 16:42, tom ehlert  wrote:
>
> > any reason you don't download VirtualBox for your platform, select
>
> > proper devices (there is even a Soundblaster16 emulated), install DOS
>
> > on it and go.
>
> VirtualBox SoundBlaster16 emulation doesn't actually work with DOS.
> VirtualBox developers have gaslit DOS users about this in their forum.  It
> is a known problem and VirtualBox developers rejected fixes for it.  For
> technical details, see the following support ticket.
>
> https://www.virtualbox.org/ticket/14883
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS

[Volkert via Freedos-devel]

On Wed, Mar 8, 2023 at 1:40 AM Ralf Quint  wrote:

>
> Well, I know some folks will hate me for that (what else is new) but there
> is no MS-DOS 7.1. It's the bootup DOS system of Windows 95SR2 and up.
>

That's just getting pedantic about things. Whatever you prefer to call it,
the "bootup DOS system of Windows 95SR2" doesn't have this problem, but
FreeDOS does. At least as of version 1.3. By the way, I'm pretty sure I
used FAT32 in both cases. And even if I didn't, the use of FAT32 really
shouldn't lead to such an excessive slowdown. I would still consider that a
bug that ought to be looked into.


> So possible issues at hand could be the use of FAT32 and/or long file
> names, which I somehow recall OW2 defaulting to.
>

Funny you'd mention LFN support, since the maintainer of OW2 disabled it
when I initially reported this finding there, before someone else pointed
out that it ran fine in "MS-DOS 7.1":

https://github.com/open-watcom/open-watcom-v2/issues/1025

Anyway, disabling LFN support in the installer did not resolve the issue,
so it's not that.


> The last time I installed OW was on one of my physical laptops, which are
> currently in storage, so I can't easily test this right now, and I am
> pretty sure that I installed the v1.9 from openwatcom.org. Not sure if
> both 1.9 and 2.0 are actually using the same installer...
>
I would guess they do, since it doesn't look like the DOS installer was
touched much since the project was forked.
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS

[Volkert via Freedos-devel]

Hi,

Over a month ago, I opened an issue on the FreeDOS project on GitLab about
the Open Watcom v2 installer being extremely slow in FreeDOS. It takes an
hour or more on FreeDOS, while the same installation completes on MS-DOS
7.1 within just a few minutes. I've reproduced this in VM instances, both
with VirtualBox and Qemu/KVM on a Linux host. I have not tested this on a
bare-metal DOS machine.

See https://gitlab.com/FreeDOS/issue-reporting/-/issues/42

But I haven't seen anybody respond to the issue. Is that really the proper
place to report FreeDOS bugs these days? With the `issue-reporting`
subproject, this is at least implied.

To be clear, I used a recent DOS build of the Open Watcom v2 fork
 to test this. I did not
explicitly test this with the old original v1.9 release, but since the
installer runs fine on MS-DOS, it seems unlikely that this issue with
FreeDOS was introduced in the forked project.

The difference in installation time is extreme, which suggests some kind of
bug or inefficiency in the file access routines of FreeDOS.

Could somebody maybe take a look at this?

Also, I wonder if others have noticed similar poor file I/O performance
under FreeDOS with other DOS software.

Thanks.
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] 386MAX

[Volkert via Freedos-devel]

On Mon, Mar 6, 2023 at 7:45 PM Bret Johnson  wrote:

>
> Or just take some of the important stuff that Bob Smith and Qualitas
> discovered about Windows/GEMMIS/EMM386 and import it into something like
> JEMM.  There's some knowledge embedded in 386MAX about what MS did that you
> will never directly get out of MS.


I already opened a ticket for this on GitHub
 a few years ago,
but Japheth
(a.k.a. Baron-von-Riedesel on GitHub) has expressed reluctance to implement
this functionality in Jemm, unfortunately.

By the way, DOSBox already has an open-source GEMMIS implementation
, which would likely be
easier to port to Jemm than any of the 386MAX sources.

I was hoping that 386MAX could ship with FreeDOS as an alternative EMM
manager because there appeared to be no near-term prospect of having GEMMIS
support (and thus Windows 3.x 386 Enhanced mode compatibility) added to
Jemm. Also, since 386MAX implements the same port trapping API as that of
Microsoft EMM386, I was hoping that it would offer compatibility with
certain drivers and emulators such as SoftMPU, which don't work with Jemm.

At least there's some encouraging news on that front, in the form of a Jemm
Loadable Module that adds support for QPI (QEMM's port trapping API), or a
subset of it. Baron-von-Riedesel recently developed that module, so
crazii's recently developed Sound Blaster emulator called SBEMU
 (also a very promising project for
FreeDOS!) can work with Jemm.

So GEMMIS support appears to be the one missing feature that would make
Jemm a complete replacement for all the known EMM managers of old (EMM386,
QEMM, 386MAX).

But perhaps if someone creates a pull request for adding GEMMIS support to
Jemm, Japheth might be persuaded to merge it. (Although he has expressed
skepticism towards that as well.)
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] The 386MAX source code has been released :)

[Volkert via Freedos-devel]

Thanks for the quick analysis of the source code, Jim!

Perhaps it would be a good idea to open these 3 issues on GitHub, and get
the ball rolling that way? https://github.com/sudleyplace/386MAX/issues

On Sat, Jul 2, 2022 at 12:31 AM Jim Hall  wrote:

> This is excellent news! It's great that he has released this under the
> GNU GPL. I did a quick review, and I think these are the only issues I
> found:
>
>
> Issue 1. Bob needs to take the extra step to review his comments in
> his code, to make sure this doesn't conflict with the GNU GPL. For
> example, I did a little poking around and found source files like
> this:
> https://github.com/sudleyplace/386MAX/blob/main/386MAX/LOADALL.INC
>
> At the top of that file, we have:
>
> ;' $Header: P:/PVCS/MAX/386MAX/LOADALL.INV 1.0 11 Aug 1995 10:56:06 HENRY $
> ;
> ; (C) Copyright 1987-92 Qualitas, Inc. All rights reserved.
> ;
> ; LOADALL.INC
> ;
> ; 286 LOADALL and 386 LOADALL structures
> ;
>
> The "(C) Copyright 1987-92 Qualitas, Inc" is fine. I'd recommend that
> this get updated to "1987-92, 2022" to represent that the code was
> also released in 2022. And it would probably be best for Bob to put
> his name in there somewhere, to indicate he has the rights to release
> this as GNU GPL. (Maybe Bob would be willing to copy/paste his comment
> from
> https://github.com/sudleyplace/DPMIONE/issues/3#issuecomment-1172710414
> into a README file in the GitHub project? That would probably get to
> the same place.) But as it is, that should be okay. (IANAL)
>
> But the "All rights reserved" is a problem. This is incompatible with
> the GNU GPL. At best, it is confusing. But this really needs to get
> cleaned up before we can include it in FreeDOS. (Note we had the same
> "All rights reserved" issue with FDNET's Crynwr network drivers a
> while ago. That issue was resolved when Russel later confirmed the
> extra "All rights reserved" statements were added by an automated
> process.[*1])
>
>
> Issue 2. Bob should also review his GitHub project to ensure that
> every binary file included there has source code for it somewhere. For
> example, https://github.com/sudleyplace/386MAX/tree/main/CYADISK seems
> to be nothing but DLL and EXE files. I think the source is in
> https://github.com/sudleyplace/386MAX/tree/main/CYASETUP but I'm not
> sure.
>
> In general, if there's no source code for something, Bob should
> consider removing that from the tree.
>
>
> I think those are the only issues I found in doing a quick review of
> Bob's GitHub project. In the meantime, I'll post a news item about it
> on the website and tweet about it from our Twitter account.
>
>
> Jim
>
>
> [*1] I just realized that Russel's email gave me permission to update
> the Crynwr network source code files on Ibiblio and I haven't done
> that yet, so I'll do it this weekend
>
> On Fri, Jul 1, 2022 at 5:03 PM Volkert via Freedos-devel
>  wrote:
> >
> > Hello FreeDOS developer community!
> >
> > Bob Smith of Sudley Place Software has released the source code of
> > 386MAX and related tools under the GPLv3 license!
> >
> > He'd like this news to be passed on to whomever would be
> > interested in this source code, but he does add that the project
> > has little to no documentation available. See his comment at
> > https://github.com/sudleyplace/DPMIONE/issues/3#issuecomment-1172710414
> >
> > The reason why this is of particular importance to the FreeDOS project,
> > is because it provides the following two features that JEMM currenty
> > lacks:
> >
> > 386MAX supports the Global EMM Import Specification (GEMMIS), which
> > allows Windows 3.x to start in 386 Enhanced mode, even when the EMM
> > manager is loaded. (The documentation in the 386MAX source code seems to
> > refer to it as the "Global Paging Import Spec".)  386MAX supports the
> > same I/O port trapping API through INT 2fh that EMM386 provides. This
> > (at least in theory) should make it compatible with certain emulation
> > TSRs such as SoftMPU and VSB, which currently don't support JEMM,
> > and would require separate non-trivial ports to work with JEMM's
> > JLOAD feature.
> >
> >
> > Anyway, the code is available at https://github.com/sudleyplace/386MAX
> >
> > I would very much like to see 386MAX included in the FreeDOS
> > distribution, with the option for users to choose between it and JEMM.
> >
> > It seems that the assembly code requires MASM, so I guess the first
> > step would be to try getting it to build with WASM or JWASM.
> >
> > Who's up for helping me get this ready for inclusion with FreeDOS?
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] The 386MAX source code has been released :)

[Volkert via Freedos-devel]

Hello FreeDOS developer community!

Bob Smith of Sudley Place Software has released the source code of 386MAX
and related tools under the GPLv3 license!

He'd like this news to be passed on to whomever would be interested in this
source code, but he does add that the project has little to no
documentation available. See his comment at
https://github.com/sudleyplace/DPMIONE/issues/3#issuecomment-1172710414

The reason why this is of particular importance to the FreeDOS project, is
because it provides the following two features that JEMM currenty lacks:


   - 386MAX supports the Global EMM Import Specification (GEMMIS), which
   allows Windows 3.x to start in 386 Enhanced mode, even when the EMM manager
   is loaded. (The documentation in the 386MAX source code seems to refer to
   it as the "Global Paging Import Spec".)
   - 386MAX supports the same I/O port trapping API through INT 2fh that
   EMM386 provides. This (at least in theory) should make it compatible with
   certain emulation TSRs such as SoftMPU and VSB, which currently don't
   support JEMM, and would require separate non-trivial ports to work with
   JEMM's JLOAD feature.


Anyway, the code is available at https://github.com/sudleyplace/386MAX

I would very much like to see 386MAX included in the FreeDOS distribution,
with the option for users to choose between it and JEMM.

It seems that the assembly code requires MASM, so I guess the first step
would be to try getting it to build with WASM or JWASM.

Who's up for helping me get this ready for inclusion with FreeDOS?
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] DIGPAK sound drivers now open source under MIT license :) Can anybody help me port these from TASM?

[Volkert via Freedos-devel]

Hi everyone,

A few months ago, John W. Ratcliff released the sources of most of the
DIGPAK DOS sound drivers on GitHub. He wrote those drivers in the '90s and
used to license them commercially under the name The Audio Solution.

DIGPAK drivers are used in many DOS games, and provide hardware abstraction
to software developers through a well-documented INT 66h API.

A few days ago, he clarified the license terms under which he was releasing
this code. He has chosen to release it under the MIT License.

His repository can be found here:
https://github.com/jratcliff63367/oldsource

It would be great if we could include these drivers in the FreeDOS
distribution, and perhaps also use them as a basis for the development of
DOS drivers for more modern audio hardware.

Unfortunately, these drivers have been written in TASM Ideal mode dialect.
To my knowledge, there are currently no open source assemblers in existence
that can build such sources.

Would anybody here care to help "fully liberate" these assembly sources by
porting them to another dialect, such as regular MASM (that can be built
with WASM or JWASM) or NASM?

I know that VBE/AI is considered a more modern DOS sound API to standardize
on for DOS driver development, but at least the DIGPAK drivers are already
out there, and now with sources too. Also, one of the DIGPAK drivers in
these sources is a wrapper around VBE/AI, which would be particularly
useful, since it would allow possible future VBE/AI drivers to be made to
work with many existing games.

I've gained some experience from trying to port the sources of Virtual
Sound Blaster (VSB) from TASM to other assembly dialects, and although I
haven't been successful with that, I have gained some experience from it.
With some help from other more experienced assembly coders here, I believe
I can be more successful porting these drivers.

Who's up for helping me with this? Your help would be greatly appreciated.
:)
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] JEMM can't completely replace EMM386 (yet). Solutions?

[Volkert via Freedos-devel]

@Eric Auer  Basically he was pretty sure that it would
simply be too much work.
See the discussion in this other GitHub thread:
https://github.com/volkertb/temu-vsb/issues/4#issuecomment-703362672

On Mon, Aug 9, 2021 at 2:36 AM Volkert 
wrote:

>
> On Mon, Aug 9, 2021 at 2:26 AM Volkert 
> wrote:
>
>>
>> On Mon, Aug 9, 2021 at 1:36 AM Eric Auer  wrote:
>>
>>>
>>> Hi Volkert,
>>>
>>> which worries does Japheth have regarding accepting I/O trap patches?
>>>
>>
>> He wrote: *"My experiences - so far - with patches from unknown people
>> are "mixed". So I'm rather sceptical."*
>> Source:
>> https://github.com/Baron-von-Riedesel/Jemm/issues/5#issuecomment-770343181
>>
>> As for my suggestion to implement this in the form of a JLM (and the
>> question whether that would even be
>> possible), he hasn't replied to that yet.
>>
>
> @Eric Auer  Sorry, I confused two things in my answer
> above: this was in response to my request
> for GEMMIS support, not for implementing the EMM386 I/O port trapping API.
> I never created a GitHub issue
> for that. (I did open a separate feature request for QPI support, namely
> the I/O port trapping API of QEMM, but
> I closed that issue when it became clear that this would not be
> implemented.)
>
> But apparently Japeth's is skeptical of third party patches from unknown
> people in general. I guess it would
> help if someone who he knows well and trusts would be willing to step up
> to the plate here.
>
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] JEMM can't completely replace EMM386 (yet). Solutions?

[Volkert via Freedos-devel]

On Mon, Aug 9, 2021 at 2:26 AM Volkert 
wrote:

>
> On Mon, Aug 9, 2021 at 1:36 AM Eric Auer  wrote:
>
>>
>> Hi Volkert,
>>
>> which worries does Japheth have regarding accepting I/O trap patches?
>>
>
> He wrote: *"My experiences - so far - with patches from unknown people
> are "mixed". So I'm rather sceptical."*
> Source:
> https://github.com/Baron-von-Riedesel/Jemm/issues/5#issuecomment-770343181
>
> As for my suggestion to implement this in the form of a JLM (and the
> question whether that would even be
> possible), he hasn't replied to that yet.
>

@Eric Auer  Sorry, I confused two things in my answer
above: this was in response to my request
for GEMMIS support, not for implementing the EMM386 I/O port trapping API.
I never created a GitHub issue
for that. (I did open a separate feature request for QPI support, namely
the I/O port trapping API of QEMM, but
I closed that issue when it became clear that this would not be
implemented.)

But apparently Japeth's is skeptical of third party patches from unknown
people in general. I guess it would
help if someone who he knows well and trusts would be willing to step up to
the plate here.
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] JEMM can't completely replace EMM386 (yet). Solutions?

[Volkert via Freedos-devel]

Hi Eric,

On Mon, Aug 9, 2021 at 1:36 AM Eric Auer  wrote:

>
> Hi Volkert,
>
> which worries does Japheth have regarding accepting I/O trap patches?
>

He wrote: *"My experiences - so far - with patches from unknown people are
"mixed". So I'm rather sceptical."*
Source:
https://github.com/Baron-von-Riedesel/Jemm/issues/5#issuecomment-770343181

As for my suggestion to implement this in the form of a JLM (and the
question whether that would even be
possible), he hasn't replied to that yet.


> What are the pros and cons of supporting the QEMM API for I/O traps,
> compared to the MS EMM386 API? I think SB Live PCI soundcard drivers
> only support the MS API? How hard would MS API support for VSB be?
>

Wasn't there a limitation in the MS API that didn't allow lower I/O ports
(under 100 or something?) to be trapped?
If so, then EMM386 would not be capable of intercepting I/O to the 8257 DMA
controller. Then again, how would
the SB Live PCI drivers be able to work without DMA port trapping? 樂

Assuming that DMA port trapping wouldn't be an issue, my guess is that
adapting VSB to EMM386 would be
doable, at least for someone with sufficient experience with x86 assembly
language programming. After all,
SoftMPU supports both MS EMM386 and QEMM without too much trouble. I'd need
some serious help to adapt
VSB to work with the EMM386 API, though. So far, I haven't even been able
to get the code to successfully
assemble with the Open Watcom assembler yet. My first priority has been to
eliminate the dependence of VSB
on TASM. Some assistance or even a remote pair programming session would be
cool. I'm sure I would learn
a lot from it.

Feel invited to convey our interest via his github :-)


Some more thumbs-up responses there might help, though. :)


> I guess Japheth would not want to spend too much time reading specs,
> maybe you can extract possible constraints from the GEMMIS specs and
> then just ask Japheth whether those would bother JEMM performance?
>

I can try. I could use some help with that, though.


> > By the way, DOSBox apparently has built-in GEMMIS support already
>
> At least DOSEMU does not, it supports DPMI instead, which is okay
> for Windows. Makes me wonder whether DPMIONE can help to run Win3
> better within FreeDOS, for example with 386enh and multiple DOS
> windows at improved stability beyond Jeremy's recent updates?
>

This other thread on GitHub might interest you:
https://github.com/sudleyplace/DPMIONE/issues/1


> I do not know more about it now than in 2012, seems like a not widely
> used EMM386 replacement, but if the quality is similar to 386SWAT and
> DPMIONE, I would be quite optimistic :-)
>

Good point. Perhaps we should just play with 386MAX a little, to see how
well it works with various stuff.

For instance, does SoftMPU even work as-is with 386MAX right now,
considering its supposed compatibility with EMM386?
That should be easy and fun to try out. Ditto for Windows 3.1 under
FreeDOS, combined with Jeremy's patches.


On Mon, Aug 9, 2021 at 1:36 AM Eric Auer  wrote:

>
> Hi Volkert,
>
> which worries does Japheth have regarding accepting I/O trap patches?
> What are the pros and cons of supporting the QEMM API for I/O traps,
> compared to the MS EMM386 API? I think SB Live PCI soundcard drivers
> only support the MS API? How hard would MS API support for VSB be?
>
>
> > In point 4 of his opening post, Bob Smith (sudleyplace on GitHub)
> mentioned
> > that with enough interest, he would be willing to "release the source
> code
> > for Qualitas MAX (a.k.a. 386MAX)".
>
> Feel invited to convey our interest via his github :-)
>
> > As for your suspicion that GEMMIS support would limit JEMM in terms of
> > optimally supporting modern CPUs, I would like to get some clarity about
> > this. Perhaps Japeth and/or others here can confirm whether or not this
> is
> > the case.
>
> I guess Japheth would not want to spend too much time reading specs,
> maybe you can extract possible constraints from the GEMMIS specs and
> then just ask Japheth whether those would bother JEMM performance?
>
> > By the way, DOSBox apparently has built-in GEMMIS support already
>
> At least DOSEMU does not, it supports DPMI instead, which is okay
> for Windows. Makes me wonder whether DPMIONE can help to run Win3
> better within FreeDOS, for example with 386enh and multiple DOS
> windows at improved stability beyond Jeremy's recent updates?
>
> > But how well do you think 386MAX would compete with it, if it were to
> > become open source?
>
> I do not know more about it now than in 2012, seems like a not widely
> used EMM386 replacement, but if the quality is similar to 386SWAT and
> DPMIONE, I would be quite optimistic :-)
>
> Regards, Eric
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list

Re: [Freedos-devel] JEMM can't completely replace EMM386 (yet). Solutions?

[Volkert via Freedos-devel]

On Sun, Aug 8, 2021 at 9:43 PM Steve Nickolas  wrote:

>
> :O
>
> If 386^MAX could be released under suitable terms (for example the 4DOS
> terms are problematic) then that would be something major to add to
> FreeDOS.
>

As you can see in his existing repositories on GitHub (
https://github.com/sudleyplace ), Bob seems partial to the GPLv3, so I
guess that would be acceptable to FreeDOS, right? 

Anyway, I opened an issue in his DPMIONE project on GitHub, with a request
for a release of the 386MAX source code:
https://github.com/sudleyplace/DPMIONE/issues/3


> Isn't it not only a replacement for EMM386, but also for MEMMAKER?
>

I have no idea. I never used 386MAX back in the day, but if it came with a
MEMMAKER-like utility, perhaps that will be included in the source code,
should he decide to release it.

Perhaps you can ask him in that GitHub thread.

On Sun, Aug 8, 2021 at 9:43 PM Steve Nickolas  wrote:

> On Sun, 8 Aug 2021, Volkert via Freedos-devel wrote:
>
> > It turns out that writing another EMM386 reimplementation from scratch
> > might not be necessary after all.
> >
> > Do you remember this thread from 2012? I see you participated in it as
> well:
> >
> >
> https://sourceforge.net/p/freedos/mailman/freedos-devel/thread/4F2097D2.5060500%40sudleyplace.com/#msg28740668
> >
> > In point 4 of his opening post, Bob Smith (sudleyplace on GitHub)
> mentioned
> > that with enough interest, he would be willing to "release the source
> code
> > for Qualitas MAX (a.k.a. 386MAX)".
> >
> > In that same thread in 2012, BretJ mentioned that 386MAX supports the
> same
> > I/O port trapping API as the one offered by Microsoft EMM386. Also,
> 386MAX
> > supports GEMMIS.
> >
> > So this might be the ideal solution for both these problems! :) I'll try
> to
> > reach out to him to ask him if he would still be willing to release the
> > source code.
>
> :O
>
> If 386^MAX could be released under suitable terms (for example the 4DOS
> terms are problematic) then that would be something major to add to
> FreeDOS.
>
> Isn't it not only a replacement for EMM386, but also for MEMMAKER?
>
> -uso.
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] JEMM can't completely replace EMM386 (yet). Solutions?

[Volkert via Freedos-devel]

Hi Eric,

On Sun, Aug 8, 2021 at 8:20 PM Eric Auer  wrote:

>
> How about letting the SoftMPU maintainers write a patch for JEMM?
>

If they're not interested in maintaining a fork of their own project, I
think it will be very unlikely to convince them to contribute such a patch
to JEMM.

Also, Japeth (Baron-von-Riedesel on GitHub) expressed skepticism w.r.t. any
submitted patches for this, in the same GitHub issue thread I linked to
earlier.


> This TSR simulates a MIDI device. Other related software includes
> VSB, the virtual sound blaster.
>

VSB doesn't even work with Microsoft EMM386, since it uses QEMM's QPI API
for port trapping. It works only with QEMM, or with no 386 memory manager
loaded at all.

I opened a GitHub issue with a feature request for QPI support in JEMM
earlier, but when I was told that would be a non-starter, I closed it again.


> Understandable, but fixing JEMM is easier than writing another EMM386.
>

It turns out that writing another EMM386 reimplementation from scratch
might not be necessary after all.

Do you remember this thread from 2012? I see you participated in it as well:

https://sourceforge.net/p/freedos/mailman/freedos-devel/thread/4F2097D2.5060500%40sudleyplace.com/#msg28740668

In point 4 of his opening post, Bob Smith (sudleyplace on GitHub) mentioned
that with enough interest, he would be willing to "release the source code
for Qualitas MAX (a.k.a. 386MAX)".

In that same thread in 2012, BretJ mentioned that 386MAX supports the same
I/O port trapping API as the one offered by Microsoft EMM386. Also, 386MAX
supports GEMMIS.

So this might be the ideal solution for both these problems! :) I'll try to
reach out to him to ask him if he would still be willing to release the
source code.


> Given that Windows already ships with MS EMM386, this seems to be a
> limited problem. Also, I suspect that having GEMMIS compatible state
> data structures would make JEMM less able to optimize for modern CPU.
>

Like I said, it would still be annoying to have to switch between boot
profiles, since JEMM offers certain advantages too. It would be great to
just have one good open-source EMM manager that would work with all of
this. :)

As for your suspicion that GEMMIS support would limit JEMM in terms of
optimally supporting modern CPUs, I would like to get some clarity about
this. Perhaps Japeth and/or others here can confirm whether or not this is
the case.


> That sounds rather exotic, given that they can more easily
> run their DOS extenders on DPMI, VCPI or raw hardware.
>

Yeah, that was my thought too. Why not just use a DOS extender or something?


> > More info on that here: http://dgi_il.tripod.com/gemmis.txt
>
> Thanks for the link!
>

You're welcome. :) It's cool to have this spec documented, regardless of
whether this ultimately makes it into an open-source EMM386 replacement or
not.

By the way, DOSBox apparently has built-in GEMMIS support already, so there
is at least one open-source implementation out there. As to how suitable
that code would be for reuse in a memory manager, that is of course another
question. :)


> > But going back to my main point: there is no full open-source drop-in
> > replacement for EMM386, as far as I know.
>
> Life is hard. Help to make the existing solution JEMM better ;-)
>

I'd love to! But as I said before, my low level coding skills are too
limited. I'd love to assist and learn, though. Also, we would have to
convince Japeth to accept a patch, even if it proves feasible to write one.


> > Perhaps these features could themselves be implemented as JLMs?
>
> At least for I/O dispatch, there might be a chance?
>

Yeah, I'd like to know this too. Does anybody else here have a clue?


> PS: I think JEMMEX and JEMMEX are far ahead of any other open
> source EMM386 style drivers.
>

Yeah, I was aware that there was an older EMM386 replacement that has since
been replaced by JEMM(EX). I guess it would be a lot more effort to dust
that off and extend it with such functionality, than to enhance JEMM.

But how well do you think 386MAX would compete with it, if it were to
become open source?
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] JEMM can't completely replace EMM386 (yet). Solutions?

[Volkert via Freedos-devel]

Hi FreeDOS devs,

I understand that the EMM manager that currently ships with FreeDOS, JEMM,
has several advantages over Microsoft's EMM386. Apparently it is more
efficient in memory use and has some additional features and tweakable
settings. And that's of course great.

However, there are two things that JEMM currently doesn't provide.

Firstly, JEMM doesn't have a port trapping API that is compatible with
Microsoft's EMM386 memory manager. Yes, JEMM can offer similar
functionality using JEMM Loadable Modules (JLMs), but the programming model
of JLM is considerably different than the API in EMM386, or even QEMM's QPI.

Most notably, JEMM/JLM requires the port trap handler (the emulation code)
to be written in 32-bit protected mode code, whereas the EMM386 and QEMM386
APIs allow such handler code to be written as 16-bit code.

This is a problem particularly for the popular SoftMPU TSR.

The SoftMPU developers don't want to take on the burden of having to
develop and support a JEMM version, in parallel to their EMM386/QEMM386
version. They prefer to work with a common codebase. See the comment at
https://www.vogons.org/viewtopic.php?p=332252#p332252

To provide some context about this tool: SoftMPU emulates the Roland
MPU-401 MIDI interface, including its so-called "Intelligent Mode", on
sound cards that support only the UART mode subset of MPU-401, and since
more recently, also on the RS-232 serial port, using a MIDI adapter, such
as the recently released MPU-232: https://www.serdashop.com/MPU-232

SoftMPU is a popular utility for retro gamers, and it sucks that this
software, which is itself an open-source project, currently requires a
proprietary/closed-source component (namely EMM386 or QEMM386) in order to
work with FreeDOS.

The second limitation of JEMM is its lack of support for the GEMMIS
specification. This means that it is not compatible with Windows 3.x, at
least when we want to run it in 386 Enhanced Mode. (This is actually a
second piece of the puzzle, since FreeDOS also requires kernel patches for
this to work, as detailed in the recent "video FreeDOS running Windows 3.1"
thread in this mailing list.)

The GEMMIS standard provides a means to seamlessly hand over control of
memory management from the EMM manager to the Windows kernel, and vice
versa when exiting back to DOS. It is supported by only a select number of
EMM managers, notably by Microsoft's own EMM386 and QEMM.

The maintainer of JEMM doesn't consider GEMMIS worth the effort to
implement, unfortunately. See this discussion:
https://github.com/Baron-von-Riedesel/Jemm/issues/5

Now granted, in the latter case (lack of GEMMIS support), you could argue
that since Windows is itself proprietary/closed-source, it's not that big a
deal having to rely on a closed-source EMM manager. But having to replace
JEMM with EMM386 or some other closed-source alternative would make the
overall system less free. And alternatively, switching back and forth
between EMM managers with different boot profiles is a hassle. Also, isn't
maximum compatibility with MS-DOS the ultimate goal of FreeDOS? Being as
much of a drop-in replacement as possible? In that sense, Windows 3.x
should be considered just another application to run from DOS. An extensive
graphical shell, as opposed to the quasi-OS that Microsoft intended the
DOS/Win3.1 combo to be.

As an additional argument: it is possible that GEMMIS was adopted by
software outside of Windows as well, namely in the demo scene. Apparently,
in order to compete in the Assembly'95 demo contest, applicants were
required to ensure that their entries would be able to coexist with 386
memory managers. The GEMMIS spec was floated as a possible solution for
meeting that requirement. Whether any demos with GEMMIS support were
actually developed, I don't know. But that might be worth investigating
further. More info on that here: http://dgi_il.tripod.com/gemmis.txt

But going back to my main point: there is no full open-source drop-in
replacement for EMM386, as far as I know.

The ideal solution would be for some developers to enhance JEMM in such a
way that support for both these features (GEMMIS and the EMM386 port
trapping API) could be added.

Perhaps these features could themselves be implemented as JLMs? That would
keep JEMM lean, and make these features optional, just for those who need
it. I currently lack the experience to implement such support, at least on
my own. But nevertheless, I would like to start a discussion about this
here. Perhaps others here know of better alternative solutions.

For instance, maybe my assumption that there currently is no open-source
drop-in replacement for EMM386 (including the aforementioned features) is
incorrect? Do any of you know of any such projects that could fit the bill?

Thanks.
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] video FreeDOS running Windows 3.1

[Volkert via Freedos-devel]

>
> I think Windows' 386 mode is pretty heavily tied into undocumented
> features of EMM386 when it is active, so it wouldn't surprise me if a free
> version of EMM386 made it go down in flames.
>

See my earlier reply about the lack of support for the GEMMIS spec in
JEMM386.

Windows 3.x in 386 Enhanced mode should work with any EMM386 alternative
that supports GEMMIS, such as QEMM386, and I believe also 386MAX.
Unfortunately, there are currently no Free and Open source EMM386
alternatives with GEMMIS support, at least as far as I know.

Is there anybody here with the knowledge and interest to work on such
support? There is documentation available for this. See the GitHub issue
link I shared in my earlier reply.

On Sat, Jul 24, 2021 at 3:29 PM Steve Nickolas  wrote:

> On Sat, 24 Jul 2021, Eric Auer wrote:
>
> > I see you are using the Microsoft HIMEM 3.07 (02/14/92), Microsoft
> > EMM386 4.44 (1991) and Microsoft SMARTDRV, are all of those actually
> > necessary? I would expect things to also work with HIMEMX or XMGR,
> > as long as no free EMM386 is loaded at all? Why do you use 4DOS in
> > the DOS window inside Windows? Any special system.ini [386enh] items?
> > See my notes below :-) Is setting VERSION=6.0 required, too?
>
> For what it's worth, Windows 3.x comes with its own versions of HIMEM and
> SMARTDRV.  I *think* it also comes with EMM386, but I'm not so sure about
> that one.  Have to check my setup disks.
>
> I think Windows' 386 mode is pretty heavily tied into undocumented
> features of EMM386 when it is active, so it wouldn't surprise me if a free
> version of EMM386 made it go down in flames.
>
> -uso.
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] video FreeDOS running Windows 3.1

[Volkert via Freedos-devel]

Great work Jeremy! 

Watching your YouTube video, I noticed the FreeDOS VM booting with
Microsoft EMM386. And that makes sense, since JEMM386 currently doesn't
support GEMMIS, a standard required for by Win3.x and Win9x for
memory management handover from the EMM manager to the Windows kernel as it
starts up from DOS. (That's necessary when you want to start Windows 3.x in
386 Enhanced mode while having an EMM manager loaded.)

There is an outstanding feature request for GEMMIS in JEMM, but the JEMM
maintainer has expressed a disinterest in adding such support:
https://github.com/Baron-von-Riedesel/Jemm/issues/5

That's unfortunate, since GEMMIS support in JEMM, in addition to Jeremy's
FreeDOS kernel patch, would result in full support for Windows 3.x (and
even Win9x) by the FreeDOS distribution.

Would any other developer here with the necessary expertise be willing to
work on GEMMIS support in JEMM? Or perhaps on adding GEMMIS to another open
source EMM386 alternative? For instance, wasn't there an older EMM386
alternative that used to ship with FreeDOS before it was replaced with
JEMM? Apparently, there is a GEMMIS implementation integrated in DOSBox, so
this code could perhaps be copied or used as an example, when implementing
GEMMIS in JEMM or in another open source EMM386 alternative.

And in addition to that, another question for Jeremy: I also noticed how
that DOS window within Windows 3.11 still seemed to "boot" an instance of
MS-DOS as opposed to FreeDOS. Would it be possible to have the DOS windows
inside Windows launch FreeDOS instead as well? Or would that require
patching Windows itself?

Thanks again!

On Sat, Jul 24, 2021 at 12:43 PM Eric Auer  wrote:

>
> Hi Jeremy,
>
> does that mean the unstable kernel already supported Win 3.1 386enh?
>
> Cool to know :-) How about Windows for Workgroups in 386 mode, which
> is "non safe mode" there, so features are lost without it in WfW 3.11?
>
> Thanks for cherry-picking all the relevant patches! I guess the FDPP
> kernel of DOSEMU2 will have some more of those for you ;-)
>
> Checking your video, it says kernel 2043 build Jul 24 2021,
> but the copyright messages says 1995-2012, probably a typo.
>
> Do you have a link to the relevant patchsets for proof-reading
> in case there is a risk of regressions?
>
> I see you are using the Microsoft HIMEM 3.07 (02/14/92), Microsoft
> EMM386 4.44 (1991) and Microsoft SMARTDRV, are all of those actually
> necessary? I would expect things to also work with HIMEMX or XMGR,
> as long as no free EMM386 is loaded at all? Why do you use 4DOS in
> the DOS window inside Windows? Any special system.ini [386enh] items?
> See my notes below :-) Is setting VERSION=6.0 required, too?
>
> Cool that WIN, WIN /3 and WIN /S apparently all work :-)
>
> Some custom (un-)settings from an old system.ini [386enh] of mine:
>
> ; device=lanman10.386
> ; mouse=lvmd.386
> ; network=*dosnet,*vnetbios
> ; old version: device=*vtd new version: device=vtda.386 (in "WW0981" fix)
> device=vtda.386
> FileSysChange=0
> PagingFile=C:\WINDOWS\WIN386.SWP
> MaxPagingFileSize=1024
> ; also: PermSwapDOSDrive=... PermSwapSizeK=...
> ; disable swapfile stuff:
> Paging=0
> ; prepare for more than 200 breakpoints, 150 is minimum useful:
> MaxBPs=768
> ; better if lots of RAM:
> PageOverCommit=1
> ; equivalent of /D:FSVX
> 32BitDiskAccess=No
> SystemROMBreakPoint=No
> VirtualHDIrq=No
> ; *** EMMEXclude=A000-
> NoEmmDriver=1
> IgnoreInstalledEMM=1
> WinExclusive=1
> ;
> TimerCriticalSection=1
> DMABufferSize=64
> XlatBufferSize=128
> KeyBoostTime=.005
> MinUserDiskSpace=5120
> PageBuffer=32
> Com1Buffer=512
> ComBoostTime=20
> Com1AutoAssign=-1
> ScreenLines=50
> ;
> InDOSPolling=1
> ; P.V.F.: 10, or 0 if share installed
> PerVMFILES=0
> ReflectDosInt2a=1
> INT28Critical=1
> ; I.V.W.U.T.: 1/2/4/*8*... seconds: how often to pump int 8/1c into idle
> VMs
> IdleVMWakeUpTime=1
> ; D.P.E.I.: enable to get explanation how to leave DOS box when starting
> one
> DOSPromptExitInstruc=0
> ; force DMA buffers to be in 1st 1MB range:
> DMABufferIn1MB=1
>
> For standard mode, I also had those settings:
>
> [standard]
> ; Stacks=12 (8..64) StackSize=384 - Settings for DOSX DOS Extender
> ; Int28Filter=0,1..*10*..: only let through every Nth int 28 ...
> Stacks=16
> StackSize=512
> Int28Filter=1
> DOSPromptExitInstruc=0
>
> Note that Windows 3.x all have issues when you have too much
> RAM. There are binary patch files for that, but the obvious
> other workaround is telling your EMM386 or HIMEM or similar
> to not let Windows know how much RAM you really have ;-)
>
> Cheers, Eric
>
> > https://youtu.be/35OQjLYdvJ0
>
> > For the technical aspect - the changes are minimal to the kernel,
> > added support for a few int 2F function calls that were never merged
> > in was about all it took.  All significant changes behind a
> > WIN31SUPPORT #ifdef so doesn't need to be compiled in if unwanted.
>
>
>
> ___
> Freedos-devel 

Re: [Freedos-devel] VBE/AI SDK released on GitHub, to celebrate the Google vs. Oracle SCOTUS decision 拾

[Volkert via Freedos-devel]

A follow-up to my previous announcement:

I got a reply from The Fat Man, and he graciously allowed free use of his
FM timbres, on the condition that his copyright notice is included in any
software in which they are included. Seems very reasonable to me. ☺️ I
therefore added the MIDI/OPL2/TOOLS/ folder that I left out earlier, and
added a LICENSE.md file that contains the copyright notice that he proposed.

The FM timbres are useful when you are developing a DOS game for which you
have music assets in General MIDI format, but you also want to support
sound cards or sound devices with OPL2/OPL3 FM synthesizer chips, such as
Adlib, Sound Blaster, etc. A similar mapper for the Roland MT32 synthesizer
appears to be included in the VBE/AI SDK as well, but I'm not sure if that
is also developed by The Fat Man.

Again, I hope any of this is useful in some way to you retro DOS game
developers out there. 

By the way, we could use some help "porting" the C/C++ code in the VBE/AI
SDK so that it can be compiled by Open Watcom. Right now, the code contains
"far pascal" keywords, which unfortunately are specific to Borland (Turbo)
C/C++.

Here's a link to the GitHub repo again:
https://github.com/volkertb/vbe-ai-sdk

On Mon, Apr 5, 2021 at 10:23 PM Volkert 
wrote:

> Hi everyone!
>
> Thank Goodness the US Supreme Court ruled in favor of common sense today.
> The copying of APIs for the purpose of implementation in original work is
> considered Fair Use! 拾
>
> Also today, as coincidence would have it, someone at VESA responded to my
> inquiry on the current legal status of the VBE/AI SDK that has been
> floating around the internet. Their response was that VESA no longer
> supports VBE/AI and that it is in the public domain, and that we are free
> to do with the sources whatever we want. ☺️
>
> I therefore unpacked the ZIP file from cd.textfiles.com and published it
> to GitHub, with the exception of one subfolder: MIDI/OPL2/TOOLS/.
>
> The repo can be found at https://github.com/volkertb/vbe-ai-sdk
>
> The reason why I left that one subfolder out of the repository is because
> it contained files copyrighted by The Fat Man, with non-free terms of use.
> Specifically, those are thimbres for OPL2 and OPL3 FM synthesizer chips as
> found in many sound cards back in the '90s.
>
> I've emailed George Sanger (a.k.a. "The Fat Man") with the question of
> whether he would be open to releasing those files as open source. If he
> agrees, I'll add that subfolder to the repository in a later commit.
> However, those files shouldn't be required when you're writing new VBE/AI
> sound drivers. As far as I understand it, you might only need those
> thimbres when you want to support the VBE/AI Adlib driver in your game and
> have a properly sounding instrument mapping when your game music is
> composed according to the General MIDI specification. But I digress.
>
> I also added the VBE/AI 1.0 specification document in PDF format
>  to the
> repository, so it's a one-stop shop for anybody here who'd like to take a
> stab at writing standard open source DOS audio drivers and/or
> applications/games making use of such drivers.
>
> The SDK also contains some existing VBE/AI drivers for Sound Blaster,
> Adlib, Disney Sound Source and MPU-401 MIDI. Those are binary-only,
> however. But if those are now public domain as well, perhaps we'll be able
> to reverse-engineer the COM files using something like Ghidra. (I've asked
> this in a follow-up question to VESA. I'll let you know if I get a more
> specific answer on that as well.)
>
> I hope all of this will be a useful piece of the puzzle w.r.t. scratching
> off the "*Drivers for modern, unsupported hardware*" item from the (Free)DOS
> development wishlist
> 
> . ☺️
>
> I've been working on the development of a VBE/AI driver for Intel ICHx
> AC'97 devices in my spare time, but I'm not very experienced in low level
> assembly and C development, so progress has been slow. Any help is welcome,
> though! 
>
> It would be nice to see VBE/AI drivers for modern sound devices such as
> these:
>
>- AC'97/ICHx (like what I've been working on)
>- Intel HD Audio
>- USB Audio
>- VirtIO (paravirtualized) Sound Driver
>- Popular PCI sound cards (SB Live, Audigy, etc)
>- OPL2LPT/OPL3LPT
>- MIDI over RS-232
>- Some other cool stuff that I'm undoubtedly missing here
>
> Note that the VBE/AI sources currently include the "far pascal" keyword
> that gcc-ia16 doesn't support yet. That's being looked into, though.
> 
> (Help with that is welcome too, of course!)
>
> Anyway, I hope this is useful to at least some of you.
>
> have a great day/evening/night, everyone! 珞
>
> Volkert
>
___
Freedos-devel mailing list

[Freedos-devel] VBE/AI SDK released on GitHub, to celebrate the Google vs. Oracle SCOTUS decision 拾

[Volkert via Freedos-devel]

Hi everyone!

Thank Goodness the US Supreme Court ruled in favor of common sense today.
The copying of APIs for the purpose of implementation in original work is
considered Fair Use! 拾

Also today, as coincidence would have it, someone at VESA responded to my
inquiry on the current legal status of the VBE/AI SDK that has been
floating around the internet. Their response was that VESA no longer
supports VBE/AI and that it is in the public domain, and that we are free
to do with the sources whatever we want. ☺️

I therefore unpacked the ZIP file from cd.textfiles.com and published it to
GitHub, with the exception of one subfolder: MIDI/OPL2/TOOLS/.

The repo can be found at https://github.com/volkertb/vbe-ai-sdk

The reason why I left that one subfolder out of the repository is because
it contained files copyrighted by The Fat Man, with non-free terms of use.
Specifically, those are thimbres for OPL2 and OPL3 FM synthesizer chips as
found in many sound cards back in the '90s.

I've emailed George Sanger (a.k.a. "The Fat Man") with the question of
whether he would be open to releasing those files as open source. If he
agrees, I'll add that subfolder to the repository in a later commit.
However, those files shouldn't be required when you're writing new VBE/AI
sound drivers. As far as I understand it, you might only need those
thimbres when you want to support the VBE/AI Adlib driver in your game and
have a properly sounding instrument mapping when your game music is
composed according to the General MIDI specification. But I digress.

I also added the VBE/AI 1.0 specification document in PDF format
 to the
repository, so it's a one-stop shop for anybody here who'd like to take a
stab at writing standard open source DOS audio drivers and/or
applications/games making use of such drivers.

The SDK also contains some existing VBE/AI drivers for Sound Blaster,
Adlib, Disney Sound Source and MPU-401 MIDI. Those are binary-only,
however. But if those are now public domain as well, perhaps we'll be able
to reverse-engineer the COM files using something like Ghidra. (I've asked
this in a follow-up question to VESA. I'll let you know if I get a more
specific answer on that as well.)

I hope all of this will be a useful piece of the puzzle w.r.t. scratching
off the "*Drivers for modern, unsupported hardware*" item from the (Free)DOS
development wishlist
. ☺️

I've been working on the development of a VBE/AI driver for Intel ICHx
AC'97 devices in my spare time, but I'm not very experienced in low level
assembly and C development, so progress has been slow. Any help is welcome,
though! 

It would be nice to see VBE/AI drivers for modern sound devices such as
these:

   - AC'97/ICHx (like what I've been working on)
   - Intel HD Audio
   - USB Audio
   - VirtIO (paravirtualized) Sound Driver 
   - Popular PCI sound cards (SB Live, Audigy, etc)
   - OPL2LPT/OPL3LPT
   - MIDI over RS-232
   - Some other cool stuff that I'm undoubtedly missing here

Note that the VBE/AI sources currently include the "far pascal" keyword
that gcc-ia16 doesn't support yet. That's being looked into, though.
 (Help
with that is welcome too, of course!)

Anyway, I hope this is useful to at least some of you.

have a great day/evening/night, everyone! 珞

Volkert
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS as a unikernel?

[Volkert via Freedos-devel]

Yep, you pretty much described the dosemu2, which was already mentioned
here. Itś a continuation of the old DOSEMU project. The original DOSEMU
relied on the V8086 virtualization mode that was introduced in the 386 CPU,
but V8086 mode isn't available in 64-bit (Long) mode. So instead, dosemu2
(optionally) leverages KVM, the hardware-assisted hypervisor in built into
the Linux kernel, to virtualize a DOS environment. And yes, it can emulate
Sound Blaster cards as well.

By the way, the dosemu2 developers are also developing fdpp, a 64-bit DOS
kernel that aims to provide a DOS-compatible userspace and that can run in
Dosemu2. (Not sure if it always uses fdpp by default.) Since it's a 64-bit
process, I'm not sure how fdpp and dosemu2 handle the running of 16-bit
code without some kind of software emulation.

But regardless, they run on Linux and leverage its virtualization features.

On Wed, Mar 3, 2021 at 1:24 AM Liam Proven  wrote:

> On 3/1/2021 10:42 AM, Pablo Pessolani wrote:
> >
> > Hi Guys.
> >   I am working on several unikernels on Linux (not over QEMU, KVM,
> XEN or any other emulator/hypervisor) using Linux system calls and the
> virtualization facilities offered by the Linux kernel.
> >  Would there be any interest in modifying freedos so that it can run
> on Linux and its virtual devices instead of running on real hardware (as
> User Mode Linux does) ?
>
> Are you aware of DOSemu?
>
> https://en.wikipedia.org/wiki/DOSEMU
>
> V1 is in most distros' repositories.
>
> V2 is in development.
> http://dosemu2.github.io/dosemu2/
>
> Most DOSes run under it, and the Ubuntu version comes bundled with FreeDOS.
>
> It is in essence a FOSS version of Locus DOS/Merge, which I was using
> in the late 1980s.
> https://en.wikipedia.org/wiki/Merge_(software)
>
> --
> Liam Proven – Profile: https://about.me/liamproven
> Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com
> Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
> UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] digipak drivers

[Volkert via Freedos-devel]

Hi Eric,

I searched for copyright notices in the code and this is what I found:

Copyright notices we don't have to worry about:


   - ✔️ The Audio Solution -> John W. Ratcliff himself, who has given
   permission to "do whatever we want" with his code
   - ✔️ Miles Design, Inc. -> John Miles, who has also permission for his
   AIL2 code and DIGPAK/MIDPAK contributions to be used freely


Copyright notices that are probably not problematic (although IANAL):


   - ❓VESA, Inc -> VBE/AI specification and SDK, can now freely be
   downloaded from VESA (upon free registration)


Copyright notices of now defunct companies, the rights of which could still
be in the hands of other companies:


   - ⚠️Media Vision -> out of business, not sure what company (if any)
   would own the IP to their DIGPAK contributions
   - ⚠️Forte Technologies -> Gravis Ultrasound SDK files, no redistribution
   permitted, but where is Forte Technologies now?

Copyright notices and possible IP from companies that still exist:


   - ⚠️Turtle Beach Systems -> company still exists
   - ⚠️Missing from any copyright notices is Creative Labs, although John
   Ratcliff explicitly mentioned receiving code contributions from them, which
   he explicitly does not claim ownership (or sublicensing rights) to.


Copyright notices from other contributors:

   - ⚠️Scott E. Sindorf -> contributed a secondary screen debugger and some
   tweaks to the Sound Blaster driver code


So if we wanted to be safe, we would have to leave out the source code for
the following drivers and tools:

   - ⚠️all the Sound Blaster and compatible drivers (including the Sound
   Blaster Clone and Media Vision Thunderboard drivers)
   - ⚠️all of the Media Vision drivers (Pro Audio Spectrum)
   - ⚠️all of the Turtle Beach drivers (such as the Multisound, not sure if
   there are others from this company)
   - ⚠️The Gravis Ultrasound (GF166) driver
   - ⚠️The secondary screen debugger (it's a separate single file that
   doesn't seem to be included by any of the other sources)

The rest I'm not so worried about. We could inquire with VESA if they are
okay with the VESA AI Include file (with service definitions and such, but
no source code) could be included with these sources. I think it's highly
unlikely that they were to object to that, since it's an obsolete standard
that sadly didn't even gain seriou adoption back in the day.

Here's the thing with all these drivers, though: most of them (except for
the Gravis Ultrasound driver, the Turtle Beach drivers and the later Sound
Blaster model drivers) are built from a single assembly source file, with
all the device-specific parts placed inside IFDEF statements. So I think a
practical approach would be to write a script that would filter out the
potentially legally problematic driver code by their device-specific
IFDEFs, before publishing the resulting sanitized code on GitHub. We could
then worry about porting the remaining drivers to another assembler dialect
later.

What do you guys think?

On Sat, Feb 13, 2021 at 9:22 PM Eric Auer  wrote:

>
> Hi Volkert,
>
> if you ask me, unless you can convince Creative otherwise,
> we should really omit any third party sources in that digipak
> driver source code release. Any other third parties involved?
>
> I remember that there is a NoMySo (not my source) script to
> convert ASM sources to more free dialects, you could try how
> well that works on digipak sources :-) I am not sure whether
> it has TASM, MASM or both as input. Output was NASM or JWASM
> as far as I remember.
>
> Regards, Eric
>
> PS: Feel free to reply as part of the freedos-devel thread.
>
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Adopting the DIGPAK sound driver sources for inclusion in FreeDOS

[Volkert via Freedos-devel]

Hello FreeDOS developers,

For quite a few years, DOS drivers for sound cards have been on the FreeDOS
development wishlist
.

I've had a conversation with John W. Ratcliff, who as many of you know used
to develop and maintain the DIGPAK and MIDPAK sound drivers under the
company name "The Audio Solution". The DIGPAK driver model has been used in
many DOS games back in the '90s and has a well-documented API, which can be
accessed from most popular programming languages, as well as from assembly
language through Interrupt 66h calls. There are DIGPAK drivers for many
different sound cards, including all the popular ones, as well as a number
of more obscure ones. A little known bonus feature of DIGPAK drivers is
that they can also be used as drop-in replacements for Miles Design AIL2
(ADV) drivers, as a result of a cooperation between John Ratcliff and John
Miles.

John Ratcliff has given his blessing for people to freely use the source
code of his DIGPAK drivers. He told us that "we can do anything we want
with it", although he did add the caveat that the sources of some of the
drivers contain third party code that was contributed by various sound card
manufacturers, and that he did not own the rights to those specific
portions of the source code. He specifically mentioned Creative Labs. Also,
he made it clear that he was completely disinterested in any further
cooperation or involvement w.r.t. further maintenance and development of
this DOS era source code. Naturally, I respect that.

Personally, I think it would be great to have FreeDOS bundle at least the
DIGPAK drivers that are free of such third party sources, as well as to use
the DIGPAK driver model as a standard and basis from which to develop
drivers for more modern sound devices. Not only can they be used to develop
new DOS games and other DOS software with support for newer sound devices,
but support for such newer devices could be patched into older games that
already rely on DIGPAK or AIL2 drivers. And the list of such games is
actually a lot higher than many people may realize.

Now most of the third party companies (aside from Creative Labs) of which
there are copyrighted portions in the existing DIGPAK driver sources are
defunct: Media Vision and Advanced Graphics and Forte Technologies. Turtle
Beach and Creative Labs still exist as companies of course.

If the FreeDOS developers and maintainers are indeed interested in adopting
the DIGPAK sources, there are a few options we can consider:

   - Adopt and bundle only the sources of drivers deemed safe: Covox Speech
   Thing, Disney Sound Source, the NOSOUND dummy driver, the VBE/AI wrapper
   driver, and the Microsoft Windows Sound System driver (since that is an
   open sound card specification anyway, and Microsoft is quite open source
   friendly these days)
   - Adopt and bundle the sources of the above "safe" drivers *plus* the
   sources containing third party code of companies that no longer exist
   - Adopt and bundle all of the sources, assuming that no company will
   bother coming after us for such obsolete and niche source code

One third party contributor to the DIGPAK drivers is John Miles, who not
only has already released the source code to his AIL2 drivers years ago,
but recently also explicitly gave his blessing for the release of any of
his contributions to John Ratcliff's DIGPAK drivers.

One additional thing to bear in mind is that the drivers are written in the
TASM Ideal mode assembly language dialect. That means that some work would
have to be done to port the source code to open source assemblers (NASM,
FASM, WASM, JWASM, etc).

What do you all think? Can FreeDOS adopt these drivers and include them in
the distribution? And perhaps some of you know people who have worked (or
currently work) at some of these sound card companies, and could vouch for
the release of the drivers that partly contain code from those companies?

I really hope we can give the DIGPAK drivers a new home within the FreeDOS
project! Not just to solve the current lack of any hardware-independent
sound support, but also to preserve this source code for its historic
significance.

Thank you all for your input on this matter. ☺
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Fwd: GEMMIS support in JEMM386 for FD 1.3? (for Win3.1 and Win9x compatibility)

[Volkert via Freedos-devel]

(Sorry for posting it to freedos-users earlier as well, I should have
posted this question here directly.)

Hi,

Is Japeth the only one maintaining JEMM386?

A few months ago, I opened a feature request to have support for GEMMIS
added to JEMM386: https://github.com/Baron-von-Riedesel/Jemm/issues/5

GEMMIS stands for *Global EMM Import Specification* and is a mechanism for
handing over memory management control from EMM managers such as EMM386 and
QEMM386 to Windows, allowing Windows 3.1 to run in 386 Enhanced mode even
if a supported EMM manager is loaded. Even Windows 95/98/Me can be started
from DOS using the same mechanism.

Unfortunately, JEMM386 currently lacks this support, so Windows 3.1/9x can
only be started from FreeDOS when JEMM386 isn't loaded.

It would be great if this limitation could be removed. DOSBox has
integrated support for GEMMIS, so perhaps some code could be copied from
there to implement this in JEMM386.

Is it too late to push for this feature to be delivered as part of FreeDOS
1.3? And could other experienced DOS/assembly developers perhaps work on
this as well, or are we completely dependent on a single developer for this?

I understand that I may be underestimating the level of complexity involved
in adding this feature. But FreeDOS releases don't happen often, so it
would be nice to have this included with 1.3.

Thanks for considering this. ☺
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] GEMMIS support in JEMM386 for FD 1.3? (for Win3.1 and Win9x compatibility)

[Volkert via Freedos-devel]

Hi,

Is Japeth the only one maintaining JEMM386?

A few months ago, I opened a feature request to have support for GEMMIS
added to JEMM386: https://github.com/Baron-von-Riedesel/Jemm/issues/5

GEMMIS stands for *Global EMM Import Specification* and is a mechanism for
handing over memory management control from EMM managers such as EMM386 and
QEMM386 to Windows, allowing Windows 3.1 to run in 386 Enhanced mode even
if a supported EMM manager is loaded. Even Windows 95/98/Me can be started
from DOS using the same mechanism.

Unfortunately, JEMM386 currently lacks this support, so Windows 3.1/9x can
only be started from FreeDOS when JEMM386 isn't loaded.

It would be great if this limitation could be removed. DOSBox has
integrated support for GEMMIS, so perhaps some code could be copied from
there to implement this in JEMM386.

Is it too late to push for this feature to be delivered as part of FreeDOS
1.3? And could other experienced DOS/assembly developers perhaps work on
this as well, or are we completely dependent on a single developer for this?

I understand that I may be underestimating the level of complexity involved
in adding this feature. But FreeDOS releases don't happen often, so it
would be nice to have this included with 1.3.

Thanks for considering this. ☺
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Dreidl game

[Volkert via Freedos-devel]

Aw, man. Now I have Kyle's Dreidl Song from that South Park holiday episode
repeating in my head. 

Thanks for sharing this with the world.

Can you double-check that link, though? It's giving me a 404.

On Tue, Oct 27, 2020 at 11:16 PM Jim Hall  wrote:

> It's kind of early for Hanukkah, but a friend suggested a little dreidl
> game. It looked easy to do, so I wrote it. This is a VERY SIMPLE dreidl
> game.
>
> The rules are in the dreidl.c file. This is under the GNU GPL v2.
> http://www.freedos.org/jhall/dreidl/
>
> I wrote it on Linux but it should compile under FreeDOS just fine. It's
> not doing anything weird. I might later update it to support DOS conio or
> DOS graphics mode or Linux ncurses, but right now it's just using puts()
> and printf(). The code has a few "stubbed in" functions that I'll use later
> to support graphics mode.
>
> If you know the dreidl game, you know this is basically a simulator, so
> it's not really a game. More than anything, this is probably a demo about
> writing a simple program. You spin the dreidl, and you automatically do
> stuff based on the spin that comes up.
>
> Jim
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] 1.3-rc3: should give meaningfull error message on AHCI (SATA) only system

[Volkert via Freedos-devel]

Wouldn't that effort be better spent on actually adding AHCI support to
UDVD2?

One cool thing about AHCI is that it has considerably lower emulation
overhead than legacy IDE. So that would be an additional argument in favor
of adding full native AHCI support to FreeDOS.

On Fri, Oct 30, 2020 at 4:56 PM Paul Dufresne via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

> If I had: '-M q35' to qemu to enable a SATA only machine, when booting in
> live mode 1.3-rc3:
> UDVD2: Nothing to use; UDVD2 not loaded.
> I hope UDVD return an error code we could use to give a more meaninful
> message like:
> Your computer is running in SATA only mode, so I cannot access the CD-ROM.
> You might try to see if your BIOS support Legacy IDE mode.
> My newer BIOS does not have this compatibility option anymore, sadly.
> I see: https://sourceforge.net/p/freedos/bugs/266/?limit=25 (about
> this)... oh we do have bugs list, I should maybe use it more!
>
> If I boot with a normal PC to do the fdisk, then reboot in SATA only mode
> and select install, installation will go until:
> "Unable to locate the installation packages.
> A reboot may help."
> Maybe where "A reboot may help" should be replaced by: "Reboot, and try to
> enable Legacy IDE mode in your BIOS before trying again."
>
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] PCI BIOS

[Volkert via Freedos-devel]

On Sat, Oct 31, 2020 at 4:43 PM Eric Auer  wrote:

>
> While you are creating that very promising VBE/AI AC97
> driver, do you have a list of games which support that
> interface or which support miles / ail / digipak / midipak
> replaceable sound drivers or docs about the driver format?
>
> Thank you :-)


Someone posted a fairly extensive list on the VOGONS forum here:
https://www.vogons.org/viewtopic.php?f=24=39270=358631=bristlehog+miles#p357303

The list is grouped in sub-lists per modular audio driver standard. The
first one, "*Audio Interface Library and MIDPAK - ADV drivers*", is the
list of games that (at least in theory) can be made to work with VBE/AI,
using the aforementioned shim/wrapper drivers. As you can see, it's quite
an extensive list. I've successfully tested this with Dune II a while back.
(NOTE: AIL2 and ADV are the same driver standard, both by John Miles of
Miles Design.)

Also, back in the '90s, I used the same trick to add Gravis Ultrasound
support to games that didn't support that card out-of-the-box. Gravis
actually made the Miles/AIL and DIGPAK/MIDPAK drivers available on their
FTP site, so customers could "patch" existing games with those drivers
themselves. Usually you'd have to replace the Sound Blaster (DAC) and
General MIDI (music) drivers and then select those in the setup program.
Although in the came of DIGPAK/MIDPAK, I think you could also just load the
drivers before starting the game, since they were TSRs, not unlike how
VBE/AI works.

One current challenge is that I don't know who has the source code to the
shim/wrapper drivers that allow those games to work with VBE/AI drivers.
That's a shame, since it would be really nice to have those shipped with
FreeDOS as well. John Miles released the source code to his AIL2 drivers
years ago and you can still download them from his page, but unfortunately
the VBE/AI shim/wrapper drivers aren't included in those sources. Those
drivers were written a few years later. I emailed John Miles about it, and
he was quick and friendly in his reply, but unfortunately he had no idea
who wrote those drivers. I'm specifically talking about the source code
to VESADIG.ADV and the VESAMID.ADV. My guess would be that someone at Media
Vision wrote those driver, since thatś company was the main backer of the
VBE/AI standard, obviously in an attempt to break Creative Lab's dominance
over the DOS sound card market.

The VBE/AI specification can be found in a PDF document on-line, and in one
of the first pages it lists a committee of members from different companies
who worked on this standard. I'm not sure what the status of that document
is, since the VESA organization usually charges money for specification
documents. On the other hand, this is a defunct standard, so that may not
apply to this particular document.

If anybody reading this happens to have any information on this topic (the
VBE/AI standard in general, the source code of the wrapper drivers for
other more popular DOS audio driver models, etc), please chime in!
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] PCI BIOS

[Volkert via Freedos-devel]

On Fri, Oct 30, 2020 at 8:28 PM Eric Auer  wrote:

>
> Also, you do not want to write a DOS driver for AC97
> or HDA sound, because sound drivers are not part of
> DOS: They are part of the games and very few games
> let you replace their sound drivers with your own.
>

Actually, there are actually quite a few DOS games that used sound drivers
that you could replace, notably Miles (AIL), DIGIPAK/MIDPAK, etc.

There is also the VBE/AI standard, which is an extension to he VESA VBE
(int 10h) API to offer a hardware-indepenent audio interface.
Unfortunately, this standard never gained any traction, since it arrived on
the market too late (in 1994), but there are shims/wrappers available to
allow VBE/AI drivers to be used by games that use AIL2 or DIGPAK/MIDPAK
drivers.

My goal has been to use Jeff Leyda's Intel ICHx AC'97 audio player code as
a basis for developing an open source VESA VBE/AI sound driver that could
be shipped with FreeDOS, as a way to kickstart the adoption of VBE/AI as
"the" audio driver standard for FreeDOS, going forward. An audio driver
standard has been on the FreeDOS wishlist for quite some time now:
http://wiki.freedos.org/wiki/index.php/(Free)DOS_development_wishlist

Anyway, if anybody would like to help me out with my driver, I would
appreciate that. I'm still working on the first "phase", namely adding
compatibility with more on-board AC'97 devices, before building a VBE/AI
driver around it. Link to the project page:
https://github.com/volkertb/ich2player

If this successful, perhaps we can start developing a VBE/AI driver for
Intel HDA (and compatible) devices, as well as other more modern and common
sound devices.

Speaking of VBE/AI, do any of you happen to know who has the source code of
the released VBE/AI drivers (for Adlib, Sound Blaster, Pro Audio Spectrum
and Disney Sound Source), and has the rights ro release them as open
source? That way, we would start out with a list of already supported sound
card and audio devices to ship with FreeDOS.
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel