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=emmxxxx0 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 Size Description (Table 01515) > 00h BYTE bit flags > bit 2: ??? > bit 3: free EMM386 virtual HMA only if hma_page_table_paddr!=0 > bit 4: no UMB??? > 01h BYTE reserved (0) > 02h WORD size of structure in bytes > 04h WORD structure version > 06h DWORD reserved > 0Ah 384 BYTEs 64 EMS frame status records (see #01516), one per 16K of > real-mode 1M address space > 18Ah BYTE ??? (must be at least 3*number_of_EMS_frames+4) > 18Bh BYTE number 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 (00000000h if non-UMB page) > var BYTE number 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 > BYTE number of free page entries following > 2N DWORDs free page entries > each is: > DWORD physical page number > DWORD number of consecutive physical pages > BYTE number 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) > BYTE number of free UMB info records following > 2N WORDs free UMB info records > each is: > WORD real mode start segment > WORD size in paragraphs > ---version 1.11--- > 20 BYTEs blank-padded maker name > 20 BYTEs blank-padded product name > Format of EMS frame status record: > Offset Size Description (Table 01516) > 00h BYTE frame type (see #01517) > 01h BYTE owner handle (00h/FFh = none) from frame including UMB > index to UMB frame descriptors > 02h WORD logical page for frame, 7FFFh if none, FFFFh if non-EMS frame > 04h BYTE EMS physical page number (FFh for non-EMS = don't care???) > 05h BYTE flags 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 frame > 1 (if EMS frame) in standard 64K page frame > 2 first 4K of frame is UMB > 3 second 4K of frame is UMB > 4 third 4K of frame is UMB > 5 last 4K of frame is UMB > Format of EMS handle info record: > Offset Size Description (Table 01518) > 00h BYTE handle number (00h = system handle) > 01h BYTE flags > bit 0: normal handle rather than system handle > bit 2: ??? (set by some EMS managers) > 02h 8 BYTEs EMS handle's name > 0Ah WORD number of 16K pages for handle > 0Ch DWORD physical address of page table entries forming page map > Note: all values should be zero for the system handle if no large frame > support is present > Format of XMS handle info record: > Offset Size Description (Table 01519) > 00h WORD handle > 02h WORD flags > bit 0: handle usable by Windows > (already in use when Windows started if clear) > bit 1: reserved (0) > 04h DWORD size in KB (may be zero, used only if flags bit 0 set) > 08h DWORD physical address (only if flags bit 0 set) Those data structures basically are how MS EMM386 manages internal state, if you ask me. If other EMM provide them, they either have to have internal state in the same style or have to keep a copy in MS format in sync at the right moment. Int 2f, function 1605 also provides a callback to switch between VM86 and real mode. The latter basically disables EMM386 and makes room for others to do everything they want in protected mode. Switching to real mode breaks interrupts, according to the text, so one either has to switch back to VM86 or be a complete protected mode and VM86 manager yourself, which is what Windows 3 in 386enh mode probably does. Which is why it needs GEMMIS. So the API does not have many functions which you can call, but it forces EMM386 alternatives to have internal state which can be expressed in MS style data structures to make it possible for Windows to interpret this state and let Windows grab the task of being the EMM386 itself while it is running and return to DOS and normal EMM386 again when you leave Windows, which is when int 2f function 1606 is called. I would HOPE that Windows is not allowed to return to DOS with a modified EMM386 state, so you would probably be safe to make a MS style state data structure as soon as int 2f function 1605 is called, without PERMANENTLY keeping state in that format. And I would HOPE that you can just refuse to handle any requests which would modify UMB, EMS, HMA or XMS state between the call to function 1605 and the call to function 1606, because the text says one has to allocate memory BEFORE calling those. So my idea is that 1605 freezes EMM386 state and expresses it as data tables ONCE for Windows, then Windows immediately calls the mode switch to real mode and load the Windows built-in EMM386 implementation, which does all work until Win exits and calls function 1606. I think it would be worth a try :-) Same for the I/O traps. Regards, Eric _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
