: : I'm pretty dumb with this stuff, but it's always been something I've
: : wanted to play with too. Do IRC, the I/O access map is essentially
: : just a large bitfield inside the CPU, and this emm386 function is
: : merely providing access to it? That's actually kinda cool-I didn't
: : even know this function existed.
: : Obviously it's possible to do it w/o emm386, since soft-ice is able
: : to trap I/O and it's incompatible with emm386. It does put the cpu
: : into it's own protected mode though.
: : So, sorry that I don't have any help for you, but just wanted to
: : tell you that there's at least someone else who is interested in the
: : subject at hand.
: I'll follow this up with some posts as I get things figured out.
: Scouring some VERY old usenet posts I managed to find some resources
: that look promising.
I've found a good resource, and possibly the only valid resource that may exist for this. He is Bob Smith, one of the founders of Qualitas (the makers of 386MAX). His current e-mail address is email@example.com. He sent the the attached Zip file with some source code and comments. In the Zip file, I renamed the executable file IOTrap.Com to IOTrap.Co_ so that I could upload it here.
The main thing of interest is the IOTrap.Txt file, which explains some problems with the interface, its implementation in EMM386, and the documentation. Microsoft provided a specification on MSDN many years ago (I haven't been able to find it), which is the basis for what's in the RBIL excerpt above (which is both incomplete and incorrect). Apparently, Qualitas tried to get Microsoft to update and correct the spec and EMM386, to no avail. I think 386MAX implemented an improved version of the spec (based on what I see in the Zip file), but don't have a copy of 386MAX to verify any of it. I believe that EMM386 and 386MAX are the only memory managers to implement the function at all.
I can tell you that it does in fact work. I've been doing some experimentation with a joystick emulator, and it seems to work fine so far (I'm testing with EMM386 version 4.48, which comes with DOS 6.20). At first, I couldn't get it to work at all. As it turns out, I was testing the function by single-stepping through with a debugger, which doesn't seem to work. I think it has something to do with the INT 03's that the debugger sticks in memory to do the single-stepping. After I stopped single-stepping and just let the program run, it started working like it was supposed to (this isn't the first time I've had a program react differently in a debugger than it does in real life). Also, FYI, the IOTRAP.COM program in the Zip file crashes on my computer, and I think it might be for the same reason (it contains INT 03's in it).
A few very interesting things to note (I found them very interesting, anyway). The EMM386 implementation only works correctly with byte-level I/O (IN AL,DX and OUT DX,AL). If you try to virtualize a word access (IN AX,DX), EMM386 just does a CBW on the value in AL. It doesn't return the AH that you told it to. Dword accesses (IN EAX,DX) crash the computer. Also, the I/O virtualization code is called in 16-bit protected mode, not 32-bit protected mode as you might expect on a 32-bit processor. And, the virtualization does not get "passed though" to Windows if you run Windows after setting up Virtual I/O (though it would seem logical that it should).
I'll need to experiment some more, but if it keeps working like it has so far, I think I'll be using this function a lot.
(16274 Bytes |
downloaded 281 times)