Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!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: <108354@hydra.gatech.EDU>
Date: 11 Aug 93 16:53:54 GMT
References: <107725@hydra.gatech.EDU> <1993Aug9.224939.19834@fcom.cc.utah.edu> <108137@hydra.gatech.EDU> <1993Aug10.195941.17468@fcom.cc.utah.edu>
Organization: Georgia Institute of Technology
Lines: 152
In <1993Aug10.195941.17468@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>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 have come to understand that {386,Net,Free}BSD do not use the 386
hardware task switching. Could someone explain why? More importantly,
is one systemwide TSS used for all processes?
>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.
Dosemu also allows the use of I/O addresses > 0x3ff in a different way;
I/O instructions to those addresses trap into dosemu. dosemu sets IOPL
to 3, does the I/O, puts the result into the appropriate register,
resets IOPL to 0, and returns. As most of the useful registers lie
below 0x3ff, this really isn't as bad as it sounds. As for Windows
and Autocad using high registers, I would imagine it depended more on
the video card in use than on the application.
I use every mode available on my ET4000 card from within dosemu, which
includes the 15 and 16 bit DAC modes. xv is nice, but I like my JPEGs
in 64k colors.
>>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
It's not so obvious to me (sorry). You are a little quick to assume your
pessimism is justified, and your conclusions absolute. Let me address
the points individually.
>*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
I'm not sure about this. To get into 80x25 text mode on my ET4000,
I need only set all the appropriate registers with the appropriate values.
The previous state is not useful. The error in your logic is here: the
BIOS sets the video card to 80x25 text mode upon powerup/initialization
with *no* knowledge of the previous, possibly insane, state.
>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.
This is a special case, and hopefully not considered a real end-user
problem. Switching to *a* known state need not involve knowledge of
*all* known states. Simply, as I said, have the kernel be able to
switch into 80x25 text mode upon a panic.
There are a couple of ways to do this. One way is to provide a way
for a program to register a "sane state" I/O map with the
kernel: a simple array of ports and values should suffice. Another
is to built minimal support for the one-known-state for all supported
video cards into the kernel, or into a video daemon.
The sane state I/O map could be registered by the program responsible
for the altered video mode (i.e. the X server). This implies a trusted
program, but I really don't think that non-trusted programs should
be allowed to fiddle with the screen state.
>2) Virtual console switch between multiple VC X sessions.
Uh, this works under Linux without any kernel knowledge of graphics modes.
The philosophy is that the graphics application can take care of
the graphics modes, i.e. if you got there, you should be able to
get back out. I think that console graphics support really doesn't
belong in the kernel, as the X Window System is a sufficient standard for
UNIX graphics. Only special applications such as X, dosemu, and MGR
could benefit from this, which does not justify the kernel bloat
entailed.
Virtual console switching is instead handled by the concept of a
controlling process for a VC. Any switches to or away from that
VC must first be "cleared" by the controlling process. It works
well for X and dosemu; these two applications can co-exist in
graphics mode just fine.
>3) Catastrophic failure of the X server.
Again, not really an important end-user case. It's never happened to me.
But, given the one-known-state kernel extension I describe above, and
the controlling process concept, the kernel could be changed (trivially)
to set the console to the one-known-state if a controlling process
dies and the console is left in graphics mode (which is registered
with the kernel, by the way).
>4) Same reasons applied to any graphic mode user application, such as
> mgr or a simple DPS or CGI environment.
Again, there are only so many graphics environments, and they all have
their own video drivers, so they should be able to handle mode switching.
>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.).
This is a good idea, but I think it will never be realized by the
free Unices. You'll have to do a lot more than add console
internationalization, you'll have to write a lot of applications which
support this international console, too. I think the best environment
for internationalization is X11.
I do agree that a kernel with knowledge of video modes would be preferable.
However, the effort to write video drivers for all the cards and
mode extensions, and ramdac sizes, and programmable clocks, etc.
would parallel the total effort put into the free Unices so far.
>>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?
I'm not sure I follow. You say that there scancodes would be available,
but that a translation layer would exist before the scancodes reach
the requesting process? In effect, all national keyboard layouts
would be mapped to one super-keyboard. That sounds fine, I suppose,
depending on the way that nationalized DOS applications handle scancodes.
I'm sure some, let's say Dutch, games might prefer untranslated Dutch keyboard
layout scan codes instead of the American equivalent. I'm not sure, though.
This does seem to imply kernel locale support, though. I was under the
impression that locale could be handled in user space.
Robert
--
Robert Sanders
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b
Internet: gt8134b@prism.gatech.edu