home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / linux / 9567 < prev    next >
Encoding:
Text File  |  1992-09-01  |  2.7 KB  |  63 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!usc!cs.utexas.edu!tamsun.tamu.edu!richard
  3. From: richard@stat.tamu.edu (richard henderson)
  4. Subject: Re: VM86
  5. Message-ID: <richard.715353503@stat.tamu.edu>
  6. Sender: news@tamsun.tamu.edu (Read News)
  7. Organization: Texas A&M University, College Station
  8. References: <1992Aug29.065940.1256@athena.mit.edu> <1992Aug29.091200.16019@klaava.Helsinki.FI> <1992Aug31.142857.4685@crd.ge.com> <peterd.715289756@pjd.dev.cdx.mot.com>
  9. Date: Tue, 1 Sep 1992 13:18:23 GMT
  10. Lines: 51
  11.  
  12. peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
  13.  
  14. >davidsen@ariel.crd.GE.COM (william E Davidsen) writes:
  15.  
  16. >>In article <1992Aug29.091200.16019@klaava.Helsinki.FI>, torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
  17.  
  18. >>| SIGALRM_handler()
  19. >>| {
  20. >>|     check the screen memory in the vm86 box, and update the real
  21. >>|     screen every now and then. Do any other regular house-keeping
  22. >>|     fn's.
  23. >>| }
  24.  
  25. >>  This can get to be fun trying to balance the overhead of fast screen
  26. >>updates with reasonable CPU usage. One technique used (by Locus) is to
  27. >>do a CRC of the screen memory in blocks, and only copy what has changed.
  28.  
  29. >This might not be worthwhile if the bandwidth between the real screen
  30. >and the screen memory is comparable to the CPU bandwidth. Especially 
  31. >beware of using an overly simple checksum function on a bitmapped 
  32. >display, as it may not detect changes between different background
  33. >patterns that have the same repetition period. (this problem was seen 
  34. >on a screen-sharing program for the Macintosh)
  35.  
  36. >[although if the real screen is on an ISA-bus card, and screen memory is
  37. >on the motherboard, it could very well be worth the effort.]
  38.  
  39. >I like Bill Davidsen's idea of using a read-only memory trap to detect
  40. >writes to the screen, though. I wonder if it would be worthwhile to use
  41. >this method to divide the screen up into large chunks (e.g. 4 or 8) and
  42. >then copy only those blocks that have changed (if any) since the last
  43. >timer tick.
  44.  
  45. >                Peter Desnoyers
  46. >-- 
  47.  
  48. Unfortunately, if this is intended to be a DOS emulator, you are going to 
  49. have to trap the VGA registers that bank the video ram into and out of
  50. the memory map.  This could be made easier if sysv shared memory blocks
  51. were in place.  Create (1M/64K) shared memory blocks, and when the VGA
  52. registers are twiddled, change the mapping of the memory blocks.
  53.  
  54. Also, if it were possible to get at the "page dirty" flag, it would be
  55. very easy to tell which 4K chunks have been modified.  This without
  56. needing to service interrupts.  It seems to me that waiting for the 
  57. alarm and checking all 16 pages at the same time would be faster than
  58. having the overhead of a (several?) task-switch to service each interrupt.
  59.  
  60. richard~
  61. ----
  62. richard@stat.tamu.edu
  63.