Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!usc!sol.ctr.columbia.edu!hamblin.math.byu.edu!news.byu.edu!news.provo.novell.com!park.uvcc.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: <1993Aug18.034456.6614@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University, Ogden, UT References: <108738@hydra.gatech.EDU> <1993Aug15.062620.6503@fcom.cc.utah.edu> <109159@hydra.gatech.EDU> Date: Wed, 18 Aug 93 03:44:56 GMT Lines: 238 In article <109159@hydra.gatech.EDU> gt8134b@prism.gatech.EDU (Howlin' Bob) writes: >I think we're arguing at cross purposes here: you're aiming for "done right," >but I'm aiming for "done before I die." Maybe that's a little pessimistic; >I have 61 years until I'm ripely 80, but do think that the device support >you're talking about has no place in a PC Unix. With the wide proliferation >of slightly incompatible hardware, non-disclosed programming secrets, etc., >the PC is a bad platform. Actually, I'm just lobbying for Holger and myself with regards to console software model. Both of us want to do the kernel resident driver and get it right. It's precisely because of the wide proliferation of hardware that you want to abstract the interface to it; the problem of being able "fully utilize" the hardware from the application layer (where things like X and dosem do their stuff) is another matter altogether; this is limited by how well the abstraction fits the hardware. Before we go off on a tangent again, I'm *not* suggestiong that you write the console code too. >VGA cards are non-standard: dosemu cannot ever hope to know all the >different card layouts. So, there are two options: 1) use the card as >a standard VGA, and dosemu can save/restore the state reliably. Never >tell any application, including AutoCAD, that you have a FooVGA 1200 >card. Always act vanilla. 2) If the BIOS designers are smart, the >save/restore state BIOS call will work as it should, and you can count >on the BIOS to save/restore the state for you. I still think the third alternative, that of virtualizing the card will work. >However, for my goals, implementing that is just not practical. If >NetBSD 0.10/FreeBSD/386BSD 0.2 implement some such mechanism, believe me, >I will quickly change dosemu to support it. Furthermore, I will steal >it from your kernel and port it to Linux, rip out all the "non-ideal" >code from dosemu, and require the new video drivers. 8-). >It just seems to me that distributed projects like Linux and *BSD must >hold resource management high in their ideals; we can't expect a >handful of volunteer hobbyists and students to work their fingers to >knubs for intangible benefits. You'd be suprised how many "nubby fingers" there are out there 8-). bob>The best solution would be the int10h,1c function described above. bob>If this really does a complete video state save and restore, then bob>many of the problems are solved. Of course, you still have to bob>know how to save all of the video memory... terry>This is perhaps the most speed-effective soloution (I would -- and have terry>done so -- argue the point); however, the standard does not require that terry>states outside of the standard be saved. >Hmm. Do you mean then VGA standard, or VESA? The call I refer to is >part of the standard VGA BIOS. I believe that it might support >modes outside of the standard because you must first request the >size needed to hold the state. Now, if I could depend on the >int10h,ah=4fh VESA functions, then things get even better. I >know that most modern cards have VESA in the BIOS, and many >other cards (like the ET4000) have VESA TSR's (like tlivesa). >The VESA standard, pitiful BIOS-based thing that is, gives a >few extra functions like "save/restore SuperVGA state" "Get SVGA >Mode Information" (i.e. supported/not supported, mode stats), >and "Set SVGA Memory Control" (i.e. set the visible memory window). >I could do a lot with these. I'm not convinced that you can rely on the call to save and restore the states that the card can be in that are not covered by the standard. I believe the "request size" function can be explained as simply as program values for Diamond clocks. The state information need not be the same for every card, and that is enough to explain why it must be requested. Perhaps there are some cards that will do a full state save so that the card state can be restored completely indeterminately, but I am willing to bet that they are few and far between. It has been my experience that manufacturers implement the minimal functionality if they are implementing to a standard, and then go off and reinvent the world with an entirely different flavor to suit themselves to get "extras". >Anyway, I admit that applications written for NT's wide character set >(is it necesarily Unicode? I thought the interface was more general) >could be served by a similar interface on the console, I believe that >similar work put into X would be better spent. Furthermore, I doubt >many NT applications will be content with international text; you >may have a portable *text* rendering engine, but how about the rest >of the Windows environment? As I understand, Windows NT doesn't >provide stdin/stdout analogs: every application must create its >own window. NT *is* necessarily Unicode (it's not more general). Unfortuantely for X, it's really not amenable to becoming a Unicode rendering engine, or at least not one capable of supporting Hebrew, Devangari, Tamil, Arabic, or other languages requiring ligatures (English "longhand" -- or more popularly, "cursive" -- is an example of a ligatured writing style). It's possible to "force" the joints in English in a fixed font; it's not possible in most other languages. The current font technology in X is woefully inadequate to the job that Unicode expects it to do, and this can't be changed without losing a lot of the benefits of X -- my opinion is that it is a problem with the code point layout in Unicode itself. Suffice it to say that there is very little it is possible to do to X without making it "not X" as far as Unicode goes. The Windows NT developer kit I have played around with has text widgets and so on. Yes, you have to instantiate them, but no, you don't have to rewrite an I/O package in every program. X has the same issue of requiring you instantiate your own windows -- but realize that Xt, NT, MS-Windows, and Macintosh operate on an event model rather than a procedural model. To say that they don't have stdin/stdout analogs is pretty much meaningless. All NT applications that deal with text can deal with Unicode unless they are really rewriting the world -- if they are, they aren't "friendly" apps, and won't get certified. bob>I get better performance with fracting under dosemu than I do with bob>xfractint. That's not surprising. X is bound to be slower for some bob>tasks. (of course, some of the slowdown is because xfractint doesn't bob>use its fast assembly integer math code under Linux). > terry>I know some of the X servers takes advantage of acceleration not terry>embodied in even the DOS fractint. Again: > >Well, seeing as how fractint is necessarily point-oriented, not geometric in >the least, I don't see how the X server really benefit from knowing a little >more about the card. It's possible, but unportable as hell, to do direct memory writes to a region bounded by an X window as long as the X server negotiates possible conflicts; the writes write either directly to memory or directly to the backing store, depending on if the screen area is occluded. SCO developers did a lot of this when ODT first came out because it was so slow. bob>A windowing system is the proper place for UNIX graphics. > >Er, so? I was just bragging. And I don't count dosemu+fractint as >"UNIX graphics." I count that as slumming. 8-). [ ... ] bob>That's a little too complex for my kernel, thank you. > terry>OK; here's the re-quote I warned you about: > bob>A windowing system is the proper place for UNIX graphics. terry>The DOS emulator runs in a UNIX environment. > >Yes, yes, and we both know that's a misinterpretation of my statement. >Unless you're IBM or Microsoft, you don't design your OS around >the other OSs you might want to emulate. I mean that native UNIX >programs should stick to X. I have said, and will say it again: >dosemu is an exception. You can say it's not, and we'll have gotten >nowhere. To me, dosemu is a kernel service that just happens to >be implemented in user space. Who here thinks the *BSD people can do a better job than IBM or Microsoft? ;-). Seriously, one of the big complaints about commercial ventures and one of the main attractions CSRG code has is that research is not accountable to a marketing bottom line and can be pursued for its own ends. Research in corporations (with a few notable exceptions) generally moves from "R&D" to strictly "D" -- changes become evolutionary instead of revolutionary; there is risk in pursuing goals beyond the six month bottom line. I think that's where the strength of a "research-for-research-sake" group lies... the strength of the *BSD and Linux groups. terry>Note that Phoenix was able to match the speed of a 4MHz PC on a 7MHz terry>68000 with little trouble. I have a hard time believing I can't do terry>a 33MHz PC on a 50MHz 486 -- especially since there is much less that terry>needs emulation. > >I'm not sure what you're saying here. Are we still talking about >graphics? Yes, and no. Phoenix did the whole ball of wax; graphics is just a piece. They emulated a full PC on an alien processer with an alien video card, keboard, serial ports, everything. And they did it at slightly better than 50% of the speed. It should be possible to "one-up" them, even with emulated video (and anything else we abstract). Give me another month, and I may be able to offer something other than discussion if things work out properly. terry>I'm not asking it to; the state information need not take into account terry>operations in progress on accelerated cards... only the display memory terry>contents and the vidoe card state at the time of the switch. > >This doesn't seem logical. If you go mucking about with display memory >while an S3 operation is still in progress, you're bound to disconcert >something. Not if you bound the switch operation to the base state. That's the point of pushing a virtualization of the card in the first place for VC's. >The UART is a piece of hardware that the kernel > 1) already provides sufficient services for; I lose no functionality > by using virtual UARTs > 2) already provides sufficient services for; I do not have to write > kernel UART device drivers. > 3) UARTs are very standard. > 4) For non-standard UARTs (like AST 4-port cards, etc.), a > virtualization that resembles a standard UART will be a win: > qmodem can run on whatever intelligent hardware you have. > For non-standad VGA's, a standard-constrained virtualization > is a loss: your games/viewers/applications cannot use the > increased color palette and resolution. > 5) UARTs are interrupt driven, and the display is not (for all > practical purposes). Getting interrupts vectored into a > user task and serviced bythe user task would be a nightmare. > Direct access to the UARTs would have to; VGA wouldn't. I'd like to make 1 and 2 true of video cards, and I think the benefit provided b 4 is worth it. 3 isn't true of video hardware, and is yet another reason to virtualize. 5 is nonapplicable. Let me reiterate that I don't expect you to do the video driver writing; I'd prefer it that as many "display services consumers" as possible had input on an interface specification as possible prior to something potentially bad gets in there and sets up housekeeping. It's hard to eveict a bad tenant, especially if he's rented an apartment in your kernel. 8-). If you had your druthers, what interface, above and beyond VGA mode setting, do you think you would need? I assume you would want a particular video memory map layout (at least for text); what else would be needed? Do you feel that a virtual VGA (or lesser virtual hardware if lesser physical hardware was in use) is sufficient? etc.? Terry Lambert terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.