Xref: utzoo comp.windows.ms:11936 comp.sys.ibm.pc.misc:9035
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!uunet!pcad!rob
From: rob@pcad.UUCP (Ralph Brown)
Newsgroups: comp.windows.ms,comp.sys.ibm.pc.misc
Subject: Re: OS/2 2.0 is here!  READ THIS, you'll be impressed
Summary: Video modes are pretty bizzare
Message-ID: <516@pcad.UUCP>
Date: 25 Apr 91 16:17:48 GMT
References: <1991Apr21.135534.724@jarvis.csri.toronto.edu> <6567@bwdls58.bnr.ca>
Followup-To: sen
Organization: Personal CAD Systems, Westford, MA
Lines: 21

In article <6567@bwdls58.bnr.ca>, mlord@bwdls58.bnr.ca (Mark Lord) writes:

> <But trapping individual machine language instructions that access video
> <memory would be incredibly slow no matter how smart you did it.  Windows 3.0
> 
> The "smart" method, used by DesqView-386 and perhaps others, is to simply use
> the 386 virtual memory to remap "normal" memory in place of the task's 
> apparent "video memory", and let it write away at will.  The supervisory code
> periodically refreshes the window on the "real" screen from the virtual windows
> of each such nasty program.

For graphics this doesn't really work since EGA and VGA use 4 (or more for
SVGA) bits per pixel and a simple graphics processor to load the data. Thus
what appears to be a simple memory write to a memory manager is really
more like an IO operation to a device register. It's necessary to know
how the graphics processor is set up to know what is actually being done
with a write to graphics memory. Each memory address is really affecting
several color planes and/or a mask of bits, so just mapping the video
memory into another RAM block won't capture what is happening on the screen.

Ralph