Date: Tue, 24 Sep 1996 20:23:15 -0700 (PDT) From: Jonathan Mini <j_mini@efn.org> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: sos@freebsd.org, pialkin@abel.pdmi.ras.ru, emulation@freebsd.org Subject: Re: New doscmd available for testing/munching Message-ID: <Pine.SUN.3.95.960924201603.24560C-100000@garcia.efn.org> In-Reply-To: <Pine.SUN.3.91.960920150137.11965A-100000@garcia.efn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
--------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.95.960924201603.24560C-100000>