Date: Thu, 26 Sep 1996 14:38:22 -0700 (PDT) From: Jonathan Mini <j_mini@efn.org> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: emulation@freebsd.org Subject: Re: New doscmd available for testing/munching Message-ID: <Pine.SUN.3.95.960926143358.28799B-100000@garcia.efn.org> In-Reply-To: <199609250349.NAA07258@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
--------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.95.960926143358.28799B-100000>