From owner-freebsd-emulation Tue Sep 24 20:23:44 1996 Return-Path: owner-emulation Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA28596 for emulation-outgoing; Tue, 24 Sep 1996 20:23:44 -0700 (PDT) Received: from haus.efn.org ([198.68.17.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA28563; Tue, 24 Sep 1996 20:23:40 -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 UAA13348; Tue, 24 Sep 1996 20:27:01 -0700 (PDT) Received: from localhost (j_mini@localhost) by garcia.efn.org (8.7.4/8.7.2) with SMTP id UAA25530; Tue, 24 Sep 1996 20:23:17 -0700 (PDT) X-Authentication-Warning: garcia.efn.org: j_mini owned process doing -bs Date: Tue, 24 Sep 1996 20:23:15 -0700 (PDT) From: Jonathan Mini To: Michael Smith cc: sos@freebsd.org, pialkin@abel.pdmi.ras.ru, emulation@freebsd.org Subject: Re: New doscmd available for testing/munching In-Reply-To: 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 Fri, 20 Sep 1996, Jonathan Mini wrote: > On Fri, 20 Sep 1996, Michael Smith wrote: > > My 'conceptual model' for this went something like : > > - allocate 128K in the emulation process for screen memory. > > - when vt is activated, copy the area that falls under the physical screen > > memory to a temporary store. > > - mmap the screen memory onto your emulation's buffer. > > - copy your temporary store back. > > - when vt is deactivated, reverse the process. > > ... but I really don't know what happens when you mmap() screen memory > > onto a section of your process' space that is already mapped. Or would > > you swap between a mapping to screen memory and a file? Or could you > > map to _both_ screen memory and a file...? 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) - In your DOS process, allocate a region in the task's 0xA000-0xBFFF range for a "simulated video card." For niceity, you could even make emulation code for everything to pretend to be VGA. (like on my unix machine, which is running a MDA/herc card, it'd think it was CGA/EGA/VGA but fail on mode switches to graph mode. (redirect text area to 0xB8000 from 0xB000 .... or even if you wanted to, simulate BOTH cards which would show up as seperate syscons.. whatever)) - 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 : - We can make DOS processes fg abd bg like unix tasks without messing up the video. - Multiple syscons will be happy. - a system like ncurses could concievably allow DOS usage over a terminal. (ok, limited, but nice) Or even X. Would be nice for a Win16/Win32 emulator... it'll come, I'm sure. ...This is the same system for management that DESQview and several other multitaskers use. It's simple, and very efficient. 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) --------------------------------------------------------------------------