Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!swrinde!gatech!prism!gt8134b
From: gt8134b@prism.gatech.EDU (Howlin' Bob)
Newsgroups: comp.os.386bsd.development
Subject: Re: V86 mode & the BIOS (was Need advice: Which OS to port to?)
Message-ID: <108137@hydra.gatech.EDU>
Date: 10 Aug 93 00:41:41 GMT
References: <107181@hydra.gatech.EDU> <1993Aug4.073826.24956@fcom.cc.utah.edu> <107725@hydra.gatech.EDU> <1993Aug9.224939.19834@fcom.cc.utah.edu>
Organization: Georgia Institute of Technology
Lines: 99
In <1993Aug9.224939.19834@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>In article <107725@hydra.gatech.EDU> gt8134b@prism.gatech.EDU (Howlin' Bob) writes:
>>relevant VGA registers and map the VGA memory into the DOS
>>emulator's address space. However, console switches disable access
>>to these resources (perhaps even so that other dosemu sessions
>>can use them), but all this is done by the Linux ioperm() system
>>call, which makes use of the 386's TSS I/O bitmap field.
>This implies (I believe) an I/O map per process -- kinda messy, and a
>generally bad thing if two devices live in the same page. The best of
Yes, the Linux TSS has an I/O bitmap large enough to map the I/O
addresses from 0 to 0x3ff. 128 bytes is not too high a cost, really.
I believe your second comment refers to memory-mapped devices; yes,
if you have two devices sharing the same page, giving dosemu access
to one of them is probably a bad idea. However, there should be no
devices other than the VGA card in the 0xa0000-0xbffff address range,
so this isn't a problem. And, as I said before, one of dosemu's
video modes doesn not require direct access to the video at all:
it works through standard UNIX tty services.
>both worlds would be a kernel BIOS service provider for emulated BIOS
>in VM86 mode that was layered on top of the existing kernel functions.
Hmm, I'm not sure what you mean. Could you elaborate a bit?
>We have been talking for some time about a known-state video driver for
>use with virtual consoles and the X server so that the only states that
>X can put the video into are states which it knows how to get out of and
>back into. That would solve the INT-10 problem by emulation of a particular
>minimal video card, or by self-emulation in the worst case.
Well, I'm interested in the exact opposite scenario: I'd like to implement
a V86 mode BIOS box that would run as a subordinate program to XFree86 --
much like the diamond clock setting programs do -- that would allow XFree86
to get into modes it has absolutely no idea how to leave. It would
simply request mode changes by calling a modified dosemu, which would then
simply pass the appropriate mode number on to int 10h, ah=0.
>>I assure you that dosemu will not "blow up" Linux in any way.
>>Nor would it adversely affect a machine running *BSD. (If someone
>>with the proper knowledge of kernel internals could be persuaded
>>to implement a simple V86 mode somewhat similar to Linux's, someone
>>could port dosemu to *BSD with acceptable effort. Of course, the
>>different console drivers would cause some trouble...)
>This is an interesting point; what exactly do you feel you would need as
>far as OS services provided for your DOS emulator to be run under *BSD?
>It's quite possible that what you want would end up being fairly simple
>for a number of available people to implement.
It looks like that may in fact be happening soon. I need very few
kernel services that BSD does not already provide, I suppose.
Shared memory of some form is necessary for HMA/A20-line emulation
(NOTE: this memory much appear at two different places in the process's
virtual address space. If 386BSD supports MAP_SHARED mmap(), then
that would do.) The current two-process dosemu requires semaphores,
which can be implemented with flock(). My plans to wedge dosemu
back into one process would require asynchronous I/O and the delivery
of the SIGIO signal.
I'd like to see a vm86() system call implemented similarly to
Linux's, although I wouldn't be opposed to suggested improvements
that I could incorporate back into Linux. Note that the Linux
implementation of vm86() is extremely simple; this could not
by any stretch of the imagination be called "kernel bloat."
If anyone is interested, I could describe vm86() in greater
detail.
For dosemu to be able to take control of the console for VGA
graphics, I'd need a way to enable I/O permissions
in arbitrary ranges, a way to map the VGA memory into dosemu's
address space at 0xa0000, and -- to support console switching on
console drivers that support virtual consoles -- some way of
registering dosemu as the "controlling process" of the console.
The Linux (and SYSVR4) console method of doing this is through
an ioctl() to gain control of a console. This ioctl() registers
2 signals, one of which is delivered when the process's console
is being switched to (so the process can set the proper video
mode and restore the video state), and one when the console
is being switched into the "background," so the controlling process
can restore the old (text) video mode. A VC switch is not considered
complete until the controlling process performs an ioctl() to
"release" the console. XFree86 1.2/1.3 uses this to provide
console switching under Linux; I assume a similar scheme is
used under *BSD.
Having access to raw scancodes when run on the console is
extremely useful. Again, I'm sure XFree86 does it, so dosemu
could do the same thing.
Robert
--
Robert Sanders
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b
Internet: gt8134b@prism.gatech.edu