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

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

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

(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:

Re: [Freedos-devel] PCI BIOS

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

Re: [Freedos-devel] Dreidl game

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

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

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

Re: [Freedos-devel] PCI BIOS

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

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

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

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

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

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

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/

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

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

Re: [Freedos-devel] digipak drivers

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,

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

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:

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

@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:

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

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

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

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

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

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

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

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,

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

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

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

> > 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

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

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

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

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

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

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

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

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

Re: [Freedos-devel] 386MAX

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

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

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,

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

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

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

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

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

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

Re: [Freedos-devel] 386MAX

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. > > O