Re: [Freedos-devel] JEMM can't completely replace EMM386 (yet). Soluti ons?
On 8/9/2021 1:06 PM, tom ehlert wrote: insofar DMA virtualisation is just another device to be understood and emulated, and not something entirely different. there is nothing special about DMA. however if several applications want to access the same DMA controller at the sam time things get complicated. there is no communication between these applications. Considering that by and large, (Free)DOS is a single tasking OS, this isn't such a big issue... ;-) Ralf -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ 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). Soluti ons?
Hi Tom, > details of course matter, as there is a huge difference between > mainboard DMA (afaik mostly used for floppies) and PCI DMA (used by > everybody else). Mainboard DMA also sounds good for ISA SoundBlaster, I guess? > for the former onboard DMA, I'm not sure there was ever some > communication among DMA users. it was just 'set up DMA. use it. > forget it.' this should be emulatable as well. In a way yes, because you had to configure drivers to avoid DMA channel conflicts, or use ISA PnP for that, but then the 8237 DMA has some port overlaps: R- DMA channel 0 current address byte 0, then byte 1 -W DMA channel 0 base addressbyte 0, then byte 1 0001 RW DMA channel 0 word count byte 0, then byte 1 0002 R- DMA channel 1 current address byte 0, then byte 1 0002 -W DMA channel 1 base addressbyte 0, then byte 1 0003 RW DMA channel 1 word count byte 0, then byte 1 0004 R- DMA channel 2 current address byte 0, then byte 1 0004 -W DMA channel 2 base addressbyte 0, then byte 1 0005 RW DMA channel 2 word count byte 0, then byte 1 0006 R- DMA channel 3 current address byte 0, then byte 1 0006 -W DMA channel 3 base addressbyte 0, then byte 1 0007 RW DMA channel 3 word count byte 0, then byte 1 0008 R- DMA channel 0-3 status register (see #P0001) 0008 -W DMA channel 0-3 command register (see #P0002) 0009 -W DMA channel 0-3 write request register (see #P0003) 000A RW DMA channel 0-3 mask register (see #P0004) 000B -W DMA channel 0-3 mode register (see #P0005) 000C -W DMA channel 0-3 clear byte pointer flip-flop register any write clears LSB/MSB flip-flop of addr & counter reg 000D R- DMA channel 0-3 temporary register 000D -W DMA channel 0-3 master clear register any write causes reset of 8237 000E -W DMA channel 0-3 clear mask register any write clears masks for all channels 000F rW DMA channel 0-3 write mask register (see #P0006) As you can see in RBIL tables P0001 to P0005, some registers have the same port, but different data, for each channel. No problem if you have a central virtual 8237 controller. But if you want to write for example a virtual floppy with a built-in 8237 emulation for one channel and a virtual SB16 with a built-in 8237 for another channel, they will both have to virtualize port 8 to F. So it might be nice to have a central virtual 8237 with some sort of API. On the other hand, who needs a virtual floppy? Almost everybody only uses BIOS API to work with floppy drives. And if a virtual soundblaster uses several ISA DMA channels, it would still be for the same single SB16. Eric ___ 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). Soluti ons?
> however if several applications want to access the same DMA controller > at the sam time things get complicated. there is no communication > between these applications. Exactly. That's what the API would somehow need to manage. I'm thinking a program would somehow need to register as the "owner" of the DMA channel (similar to how the API works now where a program registers as "owner" of an I/O port). But, there may some alternative way to handle it as well that doesn't involve a "registration" -- I'm not sure. In the end it's critical that there only be one "manager" of each resource or you'll end up with a big mess. ___ 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). Soluti ons?
> insofar DMA virtualisation is just another device to be understood and > emulated, and not something entirely different. there is nothing > special about DMA. however if several applications want to access the same DMA controller at the sam time things get complicated. there is no communication between these applications. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Devel-Philosophy [was: blocking bugs/issues for FreeDOS 1.3]
On Mon, 9 Aug 2021 at 20:16, Robert Riebisch wrote: > Hi Aitor, > > > I've noticed you Germans have your quirks with the spelling because > > there was a change to standardise the ortography not long ago (when to > > use ss and eszett amongs others :)). > > The last big reform was in 1996. > > But this reform has been reformed in 2004, 2006, 2011, 2017, and 2018. > *lol* > Nice. I've heard German language teachers here complaining about textbooks needing to be changed, hopefully not 5 times! (and some taking the more "practical" approach: why bother with standard German, teach Bavarian and hope the student will travel to Bavaria or be somehow understood everywhere else lol). Trying to get back on-topic, I suppose it will not change the collating tables or upper/lower case of NLSFUNC at all, right? Best, Aitor ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Devel-Philosophy [was: blocking bugs/issues for FreeDOS 1.3]
Hi Aitor, > I've noticed you Germans have your quirks with the spelling because > there was a change to standardise the ortography not long ago (when to > use ss and eszett amongs others :)). The last big reform was in 1996. But this reform has been reformed in 2004, 2006, 2011, 2017, and 2018. *lol* (English) Wikipedia says: Even though German spelling was already more consistent than English or French spelling, the German-speaking countries signed an agreement on spelling reforms in 1996; these were planned to be gradually introduced beginning in 1998 and fully in force by 2005. The so-called Rechtschreibreform was subject to dispute, and polls consistently showed a majority against the new spelling. In summer 2004, various newspapers and magazines returned to the old spelling, and in March 2006, the most controversial changes of Rechtschreibreform were reverted. Therefore German media outlets which had formerly opposed the changes began to use the new spelling. Cheers, Robert -- +++ BTTR Software +++ Home page: https://www.bttr-software.de/ DOS ain't dead: https://www.bttr-software.de/forum/ ___ 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). Soluti ons?
> One thing that I think > still definitely needs to be added is DMA virtualization, though I > haven't yet worked through the details on how to do that. details of course matter, as there is a huge difference between mainboard DMA (afaik mostly used for floppies) and PCI DMA (used by everybody else). for the latter, that's straight forward. for your example of NE2000 (which you intend to emulate), it sets up the DMA to point to some memory, then makes some outport command 'please send these data'. sure you must also trap the DMA commands to the understand what memory is to be transmitted, but 'these data' are what is loaded into the DMA registers. for the former onboard DMA, I'm not sure there was ever some communication among DMA users. it was just 'set up DMA. use it. forget it.' this should be emulatable as well. insofar DMA virtualisation is just another device to be understood and emulated, and not something entirely different. there is nothing special about DMA. Tom ___ 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). Soluti ons?
> RBIL sort of implies that all sizes should work, but dword is broken > and the byte/word distinction is only partially explained in RBIL? In my actual testing, the only thing that works properly is Bytes. > Have you seen apps which make use of the QPI way, apart from > SoftMPU? No, I haven't. But they could exist. I've ran across a dozen or so implementations of the MS API. Many of them are just "test" programs, though, and I never kept track of them. My USBJSTIK (for USB joysticks/gamepads) is a "real" implementation of the MS API. Is your implementation a superset of QPI? Or MS style? Both? Just MS. Qualitas provided a superset of the MS API also, and mine is a superset of the Qualitas superset. > How understandable is the API by reading source comments, as > no docs are there yet, so software beyond your USB drivers > can start to use the extra features? :-) As I think you are aware, I do a pretty good job of commenting my code so just reading the comments (especially the comments in the test program which tests all the features) will give you a good idea of what's going on. BTW, the test program is written for NASM. > I would suggest that you publish your code so people can look > around in it and ponder adding it to JEMM. Maybe even Japheth > himself would want to test it in the current state already :-) I really don't think that's a good idea, but maybe could be convinced otherwise. I don't think a "willy nilly" approach to this is a good idea -- it needs to be centralized so that there ends up only being one API. I know lots of folks don't like the idea of a "centralized" approach to something like this, but I think it's needed here. > Of course I would be happy to absorb some of your thoughts > and put them into some text file if you think that helps, > in comparison to you providing a readme yourself. I know you would, Eric, and I do appreciate everything you do. That's perhaps a little premature for now, though. I think I might be willing to publish the test program right away, though (without documentation). > To be honest, I am not aware of JLM (loadable protected mode > drivers) beyond the demo KEYB provided by Japheth. I'm not aware of any "real" JLMs either (other than test programs), but there may be some out there. > Also, is your goal to provide I/O trapping accessible by JLM, or > is there a general compatibility problem which breaks all JLM > as soon as the I/O trapping (your style, QPI or MS style?) My goal is simply be to not break existing JLM compatibility, though I don't see JLMs as the way to go in the future. That would particularly apply if Bob ever did publish the source code for QEMM since JLMs are strictly a JEMM thing. > Apart from the sound cards (although even those have VESA/AI) > you can probably virtualize all of those at the BIOS level or > packet driver level without too much compatibility loss with > common apps or drivers. The problem is that even where there are BIOS-level APIs for things (like keyboards, joysticks, mice, and even serial ports) the BIOS API's aren't always used (and in the case of joysticks and serial ports, are almost never used). To maintain compatibility with as many old programs as possible, I/O and, at least in some cases, DMA virtualization is required. > Of course, a BIOS would probably use SMM for port level > virtualization, which is not a style which user drivers like yours > can use. Exactly. That would need to be implemented by the BIOS (or EFI/UEFI) -- the can be only one SMM "manager". As you know, BIOS implementations of USB only address keyboards, mice, and/or disks. I've never seen a BIOS that supports USB COM ports, joysticks, sound cards, or Ethernet, though some Virtual Machines do. > But all of those would not yet be used by any other software ;-) The use of these is to set up a "virtualization layer" so other programs that don't understand the newer hardware can still work. E.g., a program can in fact be "talking to" a USB keyboard when it believes it is "talking to" a PS2 keyboard even when it is accessing the keyboard at the hardware (I/O port) level. > Thanks once again for your low level coding! Eric Thank You!!! ___ 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?
Hi Tom,
offer Japeth (or other developers) this money to implement your wishes?
That would be weird in a _Free_DOS(-related) project. ("Free" in the
"gratis" meaning here, not the "open source".)
you are aware that 80+% of linux developers are paid for there work?
I din't know but why should I care? Good for them. :-) They accepted the
situation that this is their job, with all advantages (being paid etc.)
and disadvantages (having a boss etc.). I'm sure they (i.e. the companies
they work in) _do_ sell something - e.g. professional customer support -,
otherwise they couldn't make money, unless they are crowd sourced or
company/government sponsored (?).
However, _this_ is FreeDOS, not GNU/Linux. I was trying to show you the
mindset why possibly a money offer wouldn't work at all - perhaps, even
the opposite - in a different kind of "society". I never had the feeling
that someone here tried to sell anything, only be proud of their
accomplishments that became part of FreeDOS. Bye,
Joe
--
KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org
Don't E-mail spam, HTML or uncompressed files! More contacts on homepage___
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). Soluti ons?
Hi Bret, > I've been working on adding an implementation of I/O port trapping to > JEMM using the EMM386/QEMM API (INT 2F.4A15). I have it basically working. Great news! > As far as the I/O port trapping, MS did a really crummy job of implementing > it. > Bob Smith of Qualitas found this out as he was implementing it in QEMM. > E.g., the MS implementation only supports byte I/O (not Word or DWord)... RBIL sort of implies that all sizes should work, but dword is broken and the byte/word distinction is only partially explained in RBIL? > The description in RBIL is incomplete and doesn't even detail the > de-installation > procedure. Qualitas' implementation fixed the MS problems and expanded its > features > (but I've never actually seen or tested the Qualitas implementation). Have you seen apps which make use of the QPI way, apart from SoftMPU? > I've added even more features in the JEMM implementation. Is your implementation a superset of QPI? Or MS style? Both? How understandable is the API by reading source comments, as no docs are there yet, so software beyond your USB drivers can start to use the extra features? :-) > If anybody wants to do it, I'll send you the code I've got so far and try to > explain my thinking. I would suggest that you publish your code so people can look around in it and ponder adding it to JEMM. Maybe even Japheth himself would want to test it in the current state already :-) Of course I would be happy to absorb some of your thoughts and put them into some text file if you think that helps, in comparison to you providing a readme yourself. > One of the main things missing is supporting JLMs (JLOAD needs > to be fixed to make it compatible). To be honest, I am not aware of JLM (loadable protected mode drivers) beyond the demo KEYB provided by Japheth. Also, is your goal to provide I/O trapping accessible by JLM, or is there a general compatibility problem which breaks all JLM as soon as the I/O trapping (your style, QPI or MS style?) would be invoked? I assume JEMM could block the respective other feature while either JLM or I/O trapping are in use, without bothering most users at all :-) > The main reason I started working on it was to support my > USB drivers, and in particular the ability to virtualize > the following kinds of USB devices: > > Keyboards > Mice > Joysticks/Game Pads > Serial/COM ports > Sound Cards > Ethernet Cards > Parallel ports (maybe -- these aren't as critical as Serial/COM ports) Apart from the sound cards (although even those have VESA/AI) you can probably virtualize all of those at the BIOS level or packet driver level without too much compatibility loss with common apps or drivers. Of course, a BIOS would probably use SMM for port level virtualization, which is not a style which user drivers like yours can use. Also, you already mentioned that packet drivers are no good abstraction level for USB LAN. https://en.wikipedia.org/wiki/System_Management_Mode#Problems > A couple of the things I've added in my JEMM implementation are > support for ports below 100h (though each port can only have a > single "manager" or "virtualizer") and IRQ virtualization (which > requires manipulation of ports 20h and 70h). One thing that I > think still definitely needs to be added is DMA virtualization But all of those would not yet be used by any other software ;-) Thanks once again for your low level coding! Eric ___ 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). Soluti ons?
I've been working on adding an implementation of I/O port trapping to JEMM using the EMM386/QEMM API (INT 2F.4A15). I have it basically working. I want to clear up some misconceptions, though. As far as the I/O port trapping, MS did a really crummy job of implementing it. Bob Smith of Qualitas found this out as he was implementing it in QEMM. E.g., the MS implementation only supports byte I/O (not Word or DWord), has a very limited number of port traps that it can implement, and doesn't always uninstall the I/O traps correctly. The description in RBIL is incomplete and doesn't even detail the de-installation procedure. Qualitas' implementation fixed the MS problems and expanded its features (but I've never actually seen or tested the Qualitas implementation). I've added even more features in the JEMM implementation. Even though I have it basically working, it's still far from where it needs to be and would really like someone else to take it and finish so I can concentrate on other things. If anybody wants to do it, I'll send you the code I've got so far and try to explain my thinking. One of the main things missing is supporting JLMs (JLOAD needs to be fixed to make it compatible). However, if this is going to be a "fork" of JEMM rather than an "upgrade", fixing JLOAD may not be necessary. The main reason I started working on it was to support my USB drivers, and in particular the ability to virtualize the following kinds of USB devices: Keyboards Mice Joysticks/Game Pads Serial/COM ports Sound Cards Ethernet Cards Parallel ports (maybe -- these aren't as critical as Serial/COM ports) E.g., for an Ethernet card, it's possible to implement a USB Ethernet drive as a simple packet driver, but virtualizing something like an NE2000 at the hardware level opens up many more possibilities for compatibility with older programs. A couple of the things I've added in my JEMM implementation are support for ports below 100h (though each port can only have a single "manager" or "virtualizer") and IRQ virtualization (which requires manipulation of ports 20h and 70h). One thing that I think still definitely needs to be added is DMA virtualization, though I haven't yet worked through the details on how to do that. And, of course, let's not forget the documentation which I haven't even started yet (and which I'm sure most implementers would just slip through the cracks). I've also created a test program to be able to test all the features to make sure they work. The version of JEMM I started with when I did this was 5.79, and I think Japheth has a newer version out and Japheth's latest changes would also need to be incorporated. I also went through and "cleaned up" some of the code to make it look more consistent. Anyway, does anybody else want to take this over and finish it? I know a lot of people want to see it happen (including me), and I think I've got a good start on it. ___ 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?
Hallo Herr Joe Forster/STA,
am Montag, 9. August 2021 um 13:24 schrieben Sie:
> Hi guys,
> (Apart from the condescending tone...)
>> offer Japeth (or other developers) this money to implement your wishes?
> That would be weird in a _Free_DOS(-related) project. ("Free" in the
> "gratis" meaning here, not the "open source".)
you are aware that 80+% of linux developers are paid for there work?
Tom
___
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?
Hi Volkert, > Wasn't there a limitation in the MS API that didn't allow lower I/O ports > (under 100 or something?) to be trapped? Correct. But then, the QEMM QPI interface is 11 different far call functions, plus some more to get the QEMM install check and other expectations which apps may have while using QPI I/O traps working. See int 67, ah=3f, cx=5145, dx=4d4d, far call functions 1a00 to 1a0a: - untrapped I/O (inb, outb, read indexed, write indexed, outb/outw) - get/set I/O trap callback (only one, not per port) - get/set trap mask item (any port, does not specify I/O width) For comparison, the MS EMM386 variant int 2f, ax=4a15 lets you install a LIST of callbacks for a RANGE of ports. The callbacks will get a custom DS of selectable size and ports must be >= 100h. They get a ring0 code and data selector and port, direction and size of the transfer when called and can select whether the real I/O should subsequently be done by EMM386 or not. In the latter case, only data received/sent via EAX matters, but no physical I/O ports will be touched. RBIL says only byte and word I/O is working, while dword I/O crashes classic EMM386 of MS DOS :-p Note that SB Live is a physical soundcard, so it could receive DSP data by DMA while still using a driver to create the illusion of having MIDI or ADLIB/OPL3 hardware in pure virtual software. Why does the DOSBOX world care so much about SOFTMPU? I would assume DSP and ADLIB are more important than a MIDI interface and DOSBOX could virtualize anything on the host OS side, not needing a DOS TSR for those things? If you want to port VSB away from TASM, use the NoMySo script which exists exactly for that, or try using JWASM :-) > I can try. I could use some help with that, though. GEMMIS: int 2f function 1605 to notify EMM386 that Windows in 386enh is about to start. You also need "get EMM import structure address" (int 21, ax=4402, sub function 1, bx=emm0 handle, cx=6, ds:dx buffer, returns 6 bytes with a linear 32 bit pointer and 2 byte version, 1, 0 or 1, 10, the latter is necessary for Win 3.1 with not only EMS but also XMS, HMA and UMB details, supported by QEMM, CEMM, MS EMM386, RBIL does not list 386MAX here? Version 1, 11 adds memory driver product name as blank-padded strings) > Format of Global EMM Import record: > Offset SizeDescription (Table 01515) > 00hBYTEbit flags > bit 2: ??? > bit 3: free EMM386 virtual HMA only if hma_page_table_paddr!=0 > bit 4: no UMB??? > 01hBYTEreserved (0) > 02hWORDsize of structure in bytes > 04hWORDstructure version > 06hDWORD reserved > 0Ah 384 BYTEs 64 EMS frame status records (see #01516), one per 16K of > real-mode 1M address space > 18AhBYTE??? (must be at least 3*number_of_EMS_frames+4) > 18BhBYTEnumber of UMB frame descriptors following > 18Ch 4N DWORDs UMB frame descriptors > each is 4 DWORDs giving physical page numbers for the four > 4K pages of a 16K EMS frame (h if non-UMB page) > var BYTEnumber of EMS handle info records following > 16N BYTEs EMS handle info records (see #01518) > ---version 1.10+ --- > DWORD realmode INT 67 vector (used by Windows to set breakpoints) > DWORD physical address of HMA page table values > BYTEnumber of free page entries following > 2N DWORDs free page entries > each is: > DWORD physical page number > DWORD number of consecutive physical pages > BYTEnumber of XMS handle info records following > 00h if memory manager does not emulate XMS or has real mode > XMS code which can execute in the Windows environment > 12N BYTEs XMS handle info records (see #01519) > BYTEnumber of free UMB info records following > 2N WORDs free UMB info records > each is: > WORDreal mode start segment > WORDsize in paragraphs > ---version 1.11--- > 20 BYTEs blank-padded maker name > 20 BYTEs blank-padded product name > Format of EMS frame status record: > Offset SizeDescription (Table 01516) > 00hBYTEframe type (see #01517) > 01hBYTEowner handle (00h/FFh = none) from frame including UMB > index to UMB frame descriptors > 02hWORDlogical page for frame, 7FFFh if none, h if non-EMS frame > 04hBYTEEMS physical page number (FFh for non-EMS = don't care???) > 05hBYTEflags for non-EMS frames (00h for EMS frame) > bits 0,1 for first 4K, bits 2,3 for second 4K, etc: > 10: direct mapping (linear address = physical address) > 01: UMB mapping > Bitfields for EMS frame type: > Bit(s) Description (Table 01517) > 0 EMS
Re: [Freedos-devel] JEMM can't completely replace EMM386 (yet). Solutions?
Hi guys,
(Apart from the condescending tone...)
offer Japeth (or other developers) this money to implement your wishes?
That would be weird in a _Free_DOS(-related) project. ("Free" in the
"gratis" meaning here, not the "open source".)
I personally would feel it insulting if someone offered me money to
implement his or her personal wish in my free software, if I didn't like
the idea contained in that wish. I'm lucky that I have no commercial
software into which I _must_ add functionality requested by customers,
only because they give me money to do so and I make a living off them.
(And, before you'd ask, I _am_ a software developer. :-) ) I assume
Japheth feels similarly about his software. This is a different kind of
"software scope". Bye,
Joe
--
KOVÁCS Balázs aka Joe Forster/STA; s...@c64.rulez.org; http://sta.c64.org
Don't E-mail spam, HTML or uncompressed files! More contacts on homepage___
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?
> 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 1st, you are reviving an 8 years old threat. They either found a solution in the meantime oor lost interest anyway. 2nd, in these 8 years there was plenty of time to read a few lines down on the mentioned page for There are a couple of gotchas: - Only real-mode games work (no DOS extenders etc.) - Games that use MPU interrupts (a handful of intelligent-mode games) are currently not supported Nevertheless this allows a lot of classic games (Lucasarts adventures etc) to work with a MT-32 connected to a Sound Blaster or SB Pro, something that's not been possible before. Wow. Wasn't the lack of Sound Blaster the problem for most people, and not some inability to play MIDI tones? > 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, Wow. do you have the slightest idea what the 95 refers to? > 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. as you ton't qualify as a developer, how about going to work, earn somemoney, and offer Japeth (or other developers) this money to implement your wishes? Tom ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
