Date: Mon, 1 Sep 1997 02:42:17 -0700 From: Jonathan Mini <j_mini@efn.org> To: Mike Smith <mike@smith.net.au> Cc: Jonathan Lemon <jlemon@americantv.com>, =?iso-8859-1?Q?S=F8ren_Schmidt?= <sos@sos.freebsd.dk>, karpen@ocean.campus.luth.se, hfwirth@ping.at, emulation@FreeBSD.ORG Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) Message-ID: <19970901024217.20763@micron.efn.org> In-Reply-To: <199709010441.OAA00750@word.smith.net.au>; from Mike Smith on Mon, Sep 01, 1997 at 02:11:57PM %2B0930 References: <19970831211438.52861@micron.efn.org> <199709010441.OAA00750@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith stands accused of saying : > > > ie. create a context, initialise it for code insertion, insert code to > > > set %cx to 0x35, insert code to call INT 0x10 major function 0x55 minor > > > function 0x01, insert code to terminate the context, and then run the > > > code in it. It might be desirable to supply some form of time limit in > > > the run_context function to trap runaway invocations; that's probably > > > fluff though. Being able to run it in parallel, and query it for > > > status rather than blocking until it completes would be _very_ useful, > > > as I'm sure you can imagine 8) > > > > Hmm. What I had in mind was something similar to a micro-kernel approach, > > where a vm86 context would be created, the proper memory addesses mapped into > > it, and then a piece of real mode code would be copies (or mapped) into the > > context, and the kernel would manage several pages of code to do various > > things. IMO, this seems to be more efficient than above, > > The approach I proposed certainly doesn't preclude copying your own > slab of code into the vm86 context; I was just proposing that in > addition to that, there should be some macros which know how to append > trivial code fragments in order to make writing and reading such > callers easier. True. Guess I wasn't thinking. > > however, unless > > FreeBSD gets a version of gcc to output real mode code, my method dies in > > flames. (I have access to several real mode compilers, but they are all > > comemrcial) > > ports/devel/bcc Cool. :) > > I know that a real mode version of gcc is possible -- Minix uses gcc, and it > > runs under Real mode. (Minix/386 doesn't, but the XT version does) > > You are mistaken. The Minix cc for the x86 is *not* gcc. gcc is > available for the 68k and i386 Minices however. Oh. I seem to rember discussion about it, perhaps this was discussion over Minix/i386. > > > I would be inclined to try to support more than one vm86 thread at > > > once, with the possibility of asynch execution and notification (or > > > even just blatant status polling). > > > > I would like to have that supprot also, but rember that the BIOS > > specification is not re-entrant, and I know of a lot of BIOSes (and BIOS > > emulators) that will crash if reentrance is attempted. > > It certainly makes no sense to attempt to reenter the video BIOS, but > in at least the trivial sense there is nothing stopping me calling, > say, an ESCD function in one virtual x86 context while the video BIOS > is being called in another; remember that they are operating in > distinct virtual contexts, where the only risk of conflict is in the > I/O domain. Umm. I hope you are rembering about memory-address registers? :) Another thing is that we are talking about two distinctly different cases. I keep thinking about BIOS simulators, which are (in general) evil. In the case of "why can't I call the BIOS on the video card when I am using the BIOS on my SCSI controller?" and the answer is "no reason at all." My problem is : "why can't I call the disk simulator's BIOS when I am using the video simulator's BIOS at the same time?" and there are too many reasons why not. (things like asking for a keypress and askingfor disk i/o simultaneously will crash Win95) My problem however, isn't your problem. :) -- Jonathan Mini (j_mini@efn.org) Ingenious Productions Software Development P.O. Box 5693 Eugene, Or 97405
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970901024217.20763>