Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!uwm.edu!spool.mu.edu!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: <1993Aug9.224939.19834@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University, Ogden, UT
References: <107181@hydra.gatech.EDU> <1993Aug4.073826.24956@fcom.cc.utah.edu> <107725@hydra.gatech.EDU>
Date: Mon, 9 Aug 93 22:49:39 GMT
Lines: 159
In article <107725@hydra.gatech.EDU> gt8134b@prism.gatech.EDU (Howlin' Bob) writes:
>In <1993Aug4.073826.24956@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>
>>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.
Yes, INT 9; sorry. If it ran at INT 16, there wouldn't be a problem.
>>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.
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
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.
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.
>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.
>>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.
I have to agree that using a VM86 to get DISK I/O to work is a generally
bad thing as well.
*BSD does not have a problem with translated drives; it's just the sharing
of those drives with DOS. As I stated a very long time ago, the translation
in many cases lives in the BIOS, and the BIOS can't be used by the kernel.
The main problem occurs when sharing the drive with a non-protected mode
OS, like DOS. Basically, the problem breaks down into several pieces:
1) The DOS MBR contains the partition table, which must be used to
look up the location of the root partition for another OS. If
the driver was set up in translation mode, the location must be
calculated in BIOS prior to going into protected mode so that
the offset is calculated using the translated geometry which it
was written in. This leads us to the use of BIOS boot blocks.
2) The *BSD OS family has a history of storing the bad track info
at the end of the drive. On drives bigger than can be handled
in BIOS, this makes it difficult to load the kernel if part of
it is written to a bad block, since the replacement block may
be inaccessable to a BIOS read. This means that either the
bad tracking infor needs to go at the front of a logical FS
partition, or the offset information needs to go to the second
stage boot which *is* at the front of the partition [and thus
presumably in range for BIOS reads], and the second stage should
be run in protected mode with this information passed to it, rather
than gathering the information itself (this is *NOT* currently done
except in experimental models, and they can't be released at this
time for non-engineering reasons).
3) Since the BIOS translation may be non-linear (ie: the 750th sector
on the disk may not be the same in BIOS vs. direct controller I/O),
the offset can't be depended on; neither can the integrity of the
supposedly "BSD only" section of the disk, since DOS sectors may
be forwarded to some sector there, with the expectation that BIOS
I/O is being used by whatever OS owns that area, and thus the
linear BSD access may conflict with the translated BIOS access. I
have to say that since Linux is a protected mode OS, this applies
to it sharing a drive with DOS as well. The general rule in the
case of a sector-forwarding drive is "all DOS use"/"all BSD use"/
"turn the forwarding off", with no solutions in between.
*BSD does not "defeat" the translation other than to "defeat" translation
implemented in BIOS -- which is to say, the vast majority of it. Linux,
by definition, must do the same, as must Mach, SVR4, UnixWare, etc.
The cylinder grouping on drives translated because of changes in radial
density (most SCSI drives) is generally still effective on caching
controllers, although the cylinder boundry optimizations for rotational
seek latency are pretty meaningless any more (*BSD can be tuned for this
by setting one of the initialization parameters for the disk to 0, which
means "no delay"). For most drives, the radial density translation is not
software detectable -- that is, it does not impact the ability to find
locations on the drive. The translation in the WD1007 ESDI case is an
example of transparent "in-controller-but-not-in-BIOS" translation, and
the Maxtor Panther series is an example of the translation occurring on a
SCSI drive itself -- it's even invisible to the controller. Most IDE and
Adaptech SCSI controller translation falls into the category of "visible
to the protected mode OS", and this is the main problem area. Only a
very few controllers attempt sector forwarding in BIOS, and fewer of these
don't let you turn the "feature" off.
Editorial comment:
I was *extremely* annoyed with Adaptech and their "technical" "support" when
I asked how to turn the translation off so I could use protected mode boot
blocks. It took me 4 days to get them to admit you couldn't, and when they
finally did, they were rude about it. I finally had to use the new boot
blocks on the machine (I was going to get around to that anyway), and
haven't had reason to give Adaptech another excuse to abuse me since.
Terry Lambert
terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.