Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: V86 mode & the BIOS (was Need advice: Which OS to port to?) Message-ID: <1993Aug10.195941.17468@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University, Ogden, UT References: <107725@hydra.gatech.EDU> <1993Aug9.224939.19834@fcom.cc.utah.edu> <108137@hydra.gatech.EDU> Date: Tue, 10 Aug 93 19:59:41 GMT Lines: 82 In article <108137@hydra.gatech.EDU> gt8134b@prism.gatech.EDU (Howlin' Bob) writes: >>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. This certainly wouldn't work for some things -- I am thinking, in particular, of Windows and AutoCAD and other uses of advanced video modes; some of the I/O registers are outside the "normal" range and wouldn't fall in that bitmap. >>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? The following was a partial elaboration: >>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. Generally, the INT services provided by DOS would be available as kernel services to kernel extensions. >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. There are several cases where this is obviously broken (sorry). The kernel *must* be able to put the video into a *known* state -- and the only way it can do this is *from* a known state. Here are several instances where this has to be possible: 1) Kernel panic and dump to kdb while X is running. In this case, the X server can not cooperate in the mode switch, since it may be the reason for the panic. In any case, no processes are running when in kdb, and thus no cooperation is possible. 2) Virtual console switch between multiple VC X sessions. 3) Catastrophic failure of the X server. 4) Same reasons applied to any graphic mode user application, such as mgr or a simple DPS or CGI environment. 5) Internal use of the graphic modes available to implement console internationalization/localization that can't be done with simple font changes (KANJI, Tamil, Devangari, Hebrew, Arabic, etc.). >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. In discussing this, the *BSD console group came up with several approaches; the most promising in terms of supporting things like DOS emulators and scan-code terminal emulations (like the WY60) seems to be a post-locale translated scan code. This would pre-translate base on keycap layout and would eliminate the need for KEY*.COM, as well as placing 8-bit NRCS's (National Replacement Character Sets) in reach for normal UNIX applications. Is this a suitable alternative? Terry Lambert terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.