From owner-freebsd-emulation Wed Sep 25 04:30:29 1996 Return-Path: owner-emulation Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA05178 for emulation-outgoing; Wed, 25 Sep 1996 04:30:29 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA05143 for ; Wed, 25 Sep 1996 04:30:26 -0700 (PDT) Received: from abel.pdmi.ras.ru by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0v5s9m-0008rTC; Wed, 25 Sep 96 04:29 PDT Received: (from root@localhost) by abel.pdmi.ras.ru (8.7.5/8.7.3) id PAA09645; Wed, 25 Sep 1996 15:22:15 +0400 (MSD) From: Alexey Pialkin Message-Id: <199609251122.PAA09645@abel.pdmi.ras.ru> Subject: Re: New doscmd available for testing/munching To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Wed, 25 Sep 1996 15:22:13 +0400 (MSD) Cc: j_mini@efn.org, emulation@FreeBSD.org In-Reply-To: <199609250349.NAA07258@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Sep 25, 96 01:19:35 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-emulation@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Ummm. I think a new conceptual model is in order... think of doing a > > "double blind" system... i.e. : > > - In doscmd kernel junk, mmap /dev/mem for video memory > > (0xA000-0xBFFF) for use by dos programs witch aren't DOS/BIOS firendly for > > video i/o. (that is, almost everyone) > > Actually, you mmap /dev/vga which roots at the base of video memory. This > is much cleaner, not to mention safer. BTW, why ? > - for directly-mapped consoles, a blind copy on every update is generally > the fastest approach. If you're in a graphic mode then it may be > viable to have an interface to the VM that lets you check whether a > page has been written and thus skip updating it. The cost for a blind > copy of 4K is probably pretty comparable to a system call, but that's > something that would have to be tried. > - for indirect mappings (X or ncurses modes), compare the current memory > aginst the rememebered memory, and redraw the regions that have > changed. The compare here is worthwhile, as the penalty for redraws > is high. BTW, we don't need to compare somthing for ncurses - it makes all automatic & redraw quite nice... At least on my home my new unoptimized ncurses support works much faster than Xs :).. But that's not a surprise :) > However for performance's sake, we want to be able to have the DOS > process directly access the memory on the video card whilst in the > foreground, and then be able to switch away from it and have it > continue to run and access the backing store. I think that it's > possible that madvise() could actually be used for this (reading > between the lines of phk's latest malloc announcement), but JD's the > one to comment there. Interesting. I have missed that. What can madvise do that can help us ? > > > - We can make DOS processes fg abd bg like unix tasks > > without messing up the video. > > This is possible in tty mode, and should be possible in ncurses mode. And it will be possible in virtual console mode. In case of proper implemenation :) Alexey Pialkin