Date: Thu, 24 Jul 1997 00:42:16 -0700 From: Jonathan Mini <j_mini@efn.org> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: bde@zeta.org.au, imp@rover.village.org, freebsd-current@FreeBSD.ORG, pechter@lakewood.com, terry@lambert.org Subject: Re: Boot file system idea! Slick Message-ID: <19970724004216.19551@micron.efn.org> In-Reply-To: <199707231425.XAA09434@genesis.atrad.adelaide.edu.au>; from Michael Smith on Wed, Jul 23, 1997 at 11:55:28PM %2B0930 References: <19970722225126.52940@micron.efn.org> <199707231425.XAA09434@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Michael Smith stands accused of saying : > 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. Well. My field is usally more sound and video and less netowrk performance. Every loss means less fps, and high timeouts for streaming devices can cause ruined output. So, for me, the latency isn't a big deal, more the amount of CPU cylces it takes. (thought latency hurts often too) > > > > 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. Well, then. I will make sure I send my modifications into the FreeBSD core team to be commited. I agree abotu BIOS having lots of useful info, I jsut don't like its API. > > > 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. Basically, yeah. However, it is the solution to things like requiring a large library to interface with a video card. For me, it has uses. Mostly on development time. It takes less time (or money, measured in time) to write an interface for the BIOS than it does to either write a library to interface with all those cards, or buy one from someone else. As of yet, I haven't seen a lib that provides as good a coverage as VESA VBE does. It's slow on some things, but at least it works. > > 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. Yeah. Well, It's kinda like the doscmd people. The concept seems a step back, but it really is a step forward. -- Jonathan Mini (j_mini@efn.org) ... bleakness ... desolation ... plastic forks ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970724004216.19551>