From: richard@stat.tamu.edu (richard henderson) Subject: Re: VM86 Date: 1 Sep 1992 13:18:23 GMT
peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
>davidsen@ariel.crd.GE.COM (william E Davidsen) writes:
>>In article <1992Aug29.091200.16019@klaava.Helsinki.FI>, torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
>>| SIGALRM_handler()
>>| {
>>| check the screen memory in the vm86 box, and update the real
>>| screen every now and then. Do any other regular house-keeping
>>| fn's.
>>| }
>> This can get to be fun trying to balance the overhead of fast screen
>>updates with reasonable CPU usage. One technique used (by Locus) is to
>>do a CRC of the screen memory in blocks, and only copy what has changed.
>This might not be worthwhile if the bandwidth between the real screen
>and the screen memory is comparable to the CPU bandwidth. Especially
>beware of using an overly simple checksum function on a bitmapped
>display, as it may not detect changes between different background
>patterns that have the same repetition period. (this problem was seen
>on a screen-sharing program for the Macintosh)
>[although if the real screen is on an ISA-bus card, and screen memory is
>on the motherboard, it could very well be worth the effort.]
>I like Bill Davidsen's idea of using a read-only memory trap to detect
>writes to the screen, though. I wonder if it would be worthwhile to use
>this method to divide the screen up into large chunks (e.g. 4 or 8) and
>then copy only those blocks that have changed (if any) since the last
>timer tick.
> Peter Desnoyers
>--
Unfortunately, if this is intended to be a DOS emulator, you are going to
have to trap the VGA registers that bank the video ram into and out of
the memory map. This could be made easier if sysv shared memory blocks
were in place. Create (1M/64K) shared memory blocks, and when the VGA
registers are twiddled, change the mapping of the memory blocks.
Also, if it were possible to get at the "page dirty" flag, it would be
very easy to tell which 4K chunks have been modified. This without
needing to service interrupts. It seems to me that waiting for the
alarm and checking all 16 pages at the same time would be faster than
having the overhead of a (several?) task-switch to service each interrupt.
richard~