From owner-freebsd-emulation Thu Sep 26 14:38:37 1996 Return-Path: owner-emulation Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA29553 for emulation-outgoing; Thu, 26 Sep 1996 14:38:37 -0700 (PDT) Received: from haus.efn.org ([198.68.17.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA29517 for ; Thu, 26 Sep 1996 14:38:32 -0700 (PDT) Received: from garcia.efn.org (j_mini@garcia.efn.org [198.68.17.5]) by haus.efn.org (8.7.5/8.7.3) with ESMTP id OAA00882; Thu, 26 Sep 1996 14:42:08 -0700 (PDT) Received: from localhost (j_mini@localhost) by garcia.efn.org (8.7.4/8.7.2) with SMTP id OAA00401; Thu, 26 Sep 1996 14:38:22 -0700 (PDT) X-Authentication-Warning: garcia.efn.org: j_mini owned process doing -bs Date: Thu, 26 Sep 1996 14:38:22 -0700 (PDT) From: Jonathan Mini To: Michael Smith cc: emulation@freebsd.org Subject: Re: New doscmd available for testing/munching In-Reply-To: <199609250349.NAA07258@genesis.atrad.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-emulation@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 25 Sep 1996, Michael Smith wrote: > Jonathan Mini stands accused of saying: > > 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. True.. ;) > > - In your DOS process, allocate a region in the task's > > 0xA000-0xBFFF range for a "simulated video card." For niceity, you could > > This is the current plan. Good. As it should be. > > - When a processes accesses the video buffer in it's task area, > > either cause a flag to be set, or something like that, and update the > > "real" video memory... This has several advantages : > This is very tough. You don't want to take the penalty for a trap Ok,Ok,Ok... my mistake.... I wrote that down wrong.. I realise this, I didn't mean a direct copy, or a trap... I mean a "single shot" trap.. i.e. something that happens ONLY ONCE then you know the screen's been modified. Once you know that, what else do you need? You shoudl be able to set that up and disable it without a big performance hit.. I could be wrong. > 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. Write-through access should be possible, of course, you're right. ;) Another alternative is the way DESQview does is in "screen virtualization" mode. Each task has a seperate "video memory" that is updated into it's window on the REAL monitor every timer tick (1/18 sec in DV) a similar approach would be acceptable for this -- something like updating every 25th a sec or so... However, this is only really important when you are creating a windowed interface, which we aren't. ;) Jon Mini, j_mini@efn.org, mini@4j.lane.edu GAMMA Development Team -------------------------------------------------------------------------- "I think I can, I think I can, I think I can...." little.blue.engine:Reality Protection Fault. (core dumped) --------------------------------------------------------------------------