Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!sdd.hp.com!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: <107725@hydra.gatech.EDU>
Date: 6 Aug 93 05:18:05 GMT
References: <3390@vall.dsv.su.se> <CB11pL.D12@imag.fr> <107181@hydra.gatech.EDU> <1993Aug4.073826.24956@fcom.cc.utah.edu>
Organization: Georgia Institute of Technology
Lines: 116
In <1993Aug4.073826.24956@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>In article <107181@hydra.gatech.EDU> gt8134b@prism.gatech.EDU (Howlin' Bob) writes:
>>Actually, I'm using the video BIOS just fine under Linux. All you
>>need is a little bit of code to support the 386's virtual-8086 mode
>>and access to a BIOS image (/dev/mem does fine under Linux). Of course,
>>I wouldn't recommend this sort of thing for real work, but I
>>wouldn't recommend anything else for a DOS emulator. I decided long
>>ago that writing video support code for every card was impossible
>>for a lone author, so running the native BIOS seemed the best way.
>Item of information: Paradise, ATI, and many other vidoe cards disable all
>interrupts other than 2/9 (raster interrupt, don'tcha know) while doing
>INT-10 calls. Therefore it is stupid to do INT-10 calls, even in an emulated
>8086 mode unless you are prepared to lose network, serial, mouse, tape, floppy,
>and keyboard I/O (and have your clock slip).
Ah, perhaps I was not clear. I'm using the BIOS in my DOS emulator, which
of course runs in V86 mode. More importantly, IOPL is set so that
the V86 task(s) fault on privileged instructions, some of which are
INT/CLI/STI/PUSHF/POPF. This is all one needs for IF bit emulation.
It is impossible for a program running under the DOS emulator to disable
*any* interrupts for real; it can only disable "virtual" interrupts.
I am not willing to sacrifice any system reliability for dosemu.
Therefore, what cannot be done safely on the hardware is done
safely (but slowly) in virtual I/O. dosemu's virtualized 8250 UARTs are
a good example. They can't do 9600 baud, but they're good enough
for accessing the mouse under dosemu.
>If you are so swift as to run KEYBUK.COM or other KEYB*.COM files for local
>keyboard layout on British Telecom, Zenith, Toshiba, or Olivetti equipment,
>be prepared to lose serial and other low priority interrupts while the
>keyboard lookup occurs (during INT-16 instead of during the read from the
>queue, like god intended). Seems that they do their lookup in the interrupt
Um, I suppose you mean INT9? INT16 *is* when the queue lookup occurs.
Understand that it is not possible for translation to be done reliably
within INT16, as many, many programs directly dequeue keystrokes from
low RAM. Any translation must be done in the keyboard ISR before the
keystroke is enqueued. Such are the pleasures of DOS.
Ideally, the KEYB*.COM files are unnecessary under dosemu as it has
control of the keyboard mapping. Any translation can be done before
V86 mode gets to see the keystroke. While I have provided for only
limited keyboard remapping under dosemu, this can be fixed with
only a little trouble. A simple scancode->scancode and ASCII->ASCII
lookup table is all that's needed.
I am considering adapting the Xmodmap-like scheme used for loadable
kernel keymaps under Linux to dosemu.
>handler. This will also blow up a UNIX if an 8086 virtual DOS mode session
>is being run.
Again, the DOS "box" provided by Linux's dosemu is, in most cases,
isolated from real hardware. I simulate all the BIOS services, most
notable int13h (disk), int16h (keyboard), int10h (video), and
int15h (various). However, due to the difficulty of writing an int10h
implementation that provides graphics for all cards, and also due to
the desirability of re-using as much code as possible, dosemu provides
all graphics services by using the video adapter's own BIOS. So, my
dosemu-specific int10h is used for running in an xterm (or over any
tty device which supports a few basic termcap commands), or for
running on the Linux console in non-graphics mode (providing color
and line-drawing characters, as well as instantaneous screen updates
if the application uses direct video memoery access). However, the
user may select an option that instead substitutes the video card's
native BIOS for my hand-rolled substitute. This allows for mode
switching, font changes -- all int10h services, in fact. I can
quite easily run most graphics programs under dosemu, including
picture viewers, WordPerfect print preview, Windows 3.0, and
even a few games. To do this I enable access to all the
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.
Except for the system load of Protected mode <-> V86 transitions
and instruction decoding, this use of the BIOS has no detrimental
effects on Linux. I often run my USR Sportster at computer<->modem
rates of 57600 bps transferring files to and from my school,
while my roommate happily accesses his /usr which is my /usr
NFS-mounted over our small Ethernet (WD8013 NICs) and play
Windows Solitaire with no loss of data at all. In fact, my
system load average rarely tops 0.87. I find Windows Solitaire
a good way to while away the minutes during kernel compilations.
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...)
>Yes, BIOS access via VM86 is a good thing(tm) in some cases -- Bill and I
>discussed at length implementing a disk driver this way to get around, once
>and for all, the drive translation problems, for instance. But video and
>keyboard I/O are not the places that this is good.
Well, I'm not too keen on using the BIOS at all for kernel I/O. It's
a nasty, convoluted solution that's bound to be suboptimal. While
OS/2 has done it fairly well, I think {386,Net,Free}BSD and Linux
would do best to steer clear of it. Besides, Linux seems to suffer
from no drive translation problems. Does *BSD attempt to defeat
translation for performance purposes? I have wondered at the
effectiveness of the cylinder group algorithm used in Linux's
ext2fs when applied to a drive whose true physical geometry is
unknown to the kernel.
--
Robert Sanders
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b
Internet: gt8134b@prism.gatech.edu