From owner-freebsd-current Wed Jul 23 07:25:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA20157 for current-outgoing; Wed, 23 Jul 1997 07:25:58 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA20141 for ; Wed, 23 Jul 1997 07:25:52 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id XAA09434; Wed, 23 Jul 1997 23:55:28 +0930 (CST) From: Michael Smith Message-Id: <199707231425.XAA09434@genesis.atrad.adelaide.edu.au> Subject: Re: Boot file system idea! Slick In-Reply-To: <19970722225126.52940@micron.efn.org> from Jonathan Mini at "Jul 22, 97 10:51:27 pm" To: j_mini@efn.org Date: Wed, 23 Jul 1997 23:55:28 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, bde@zeta.org.au, imp@rover.village.org, freebsd-current@FreeBSD.ORG, pechter@lakewood.com, terry@lambert.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jonathan Mini stands accused of saying: > Very true. I _hate_ the way BIOS works. I hate a lot of other > things about the initial IBM PC design and how we're stuck with it > now. There are a few things we can do that will make it a "little" > safer, such as run under a protected priveledge level and watch > accesses -- i.e. restrict them to ranges, but that is not an option > for a high-performance solution. I can see people screaming about latency already. > > > 2) My favorite method. Take your saved interrupt vector table and put > > > it at the begining of a v86 TSS. Also, map in the appropriate amount of > > > memory, and the ROM address space. Effectively, you get the effect of > > > FreeBSD being a overly complex memory manager for DOS, since this is > > > what QEMM and a few others do. The v86 TSS can be multitasked like a > > > doscmd process, and several other things. The only problem is that > > > > If this is your favorite method, I assume that you have code implementing > > it already? > > No. However, I will start writing code in the near future (less than a month) That'd be invaluable; there is a plethora of data that can be obtained from the BIOS, and it is senseless to try to reinvent the weel _if_ it's possible to do it that way. > > Isn't there a 32-bit interface to the VESA BIOS? > > VBE 2.0 has a 32-bit interface, yes. However, the information > requred to USE the interface has to be gotten via a standard 16-bit > interrupt call. (Ugh. ... > Once you do all this, you can remap (or copy) the table to > anywhere you like, but you only get to access Functions 5 (Set > Address Window), 7 (Set display start), and 9 (Set Primary Palette) ie. it's completely worthless. Good one, guys. > Within a short period, I will be looking into running stuff within v86 > tasks. (My soul screams against it, it seems incredibly backwards and lame) Well, the alternative is just as horrible. > ... bleakness ... desolation ... plastic forks ... -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[