home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / sci / electron / 19329 < prev    next >
Encoding:
Text File  |  1992-11-21  |  1.6 KB  |  32 lines

  1. Newsgroups: sci.electronics
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!torn!utzoo!henry
  3. From: henry@zoo.toronto.edu (Henry Spencer)
  4. Subject: Re: Help with refresh/record scheme needed!
  5. Message-ID: <By35HH.9qo@zoo.toronto.edu>
  6. Date: Sat, 21 Nov 1992 21:39:15 GMT
  7. References: <> <92322.002218EAO102@psuvm.psu.edu> <2b0a0a91.de77@grace.cri.nz>
  8. Organization: U of Toronto Zoology
  9. Lines: 21
  10.  
  11. In article <2b0a0a91.de77@grace.cri.nz> srgxnbs@grace.cri.nz writes:
  12. >Its a long time since I played with DRAMS, but I would think that with 
  13. >a bit of judicious programming you may be able to avoid a refresh 
  14. >circuit. As long as you access all rows (columns?) within 4 ms the ram 
  15. >gets refreshed, so while you're recording you'll be refreshing anyway, 
  16. >ditto for playback. The rest of the time you could possibly arrange an 
  17. >interrupt routine every 4 mS to just read the necessary number of 
  18. >addresses if you can't build it into your program. If this is all B.S. 
  19. >then someone please say so :)
  20.  
  21. No, it's a legitimate although tricky approach.  The very first Sun systems
  22. used software refresh.  If you were really clever, you could hand-craft an
  23. interrupt routine that did the refresh while also accomplishing something
  24. useful (a friend of mine wrote a mouse-tracking refresh routine).
  25.  
  26. The trouble is, if that interrupt routine gets lost or has a bug, your
  27. memory contents can evaporate.  Debugging such systems gets exciting.
  28. Later-model Suns had hardware refresh.
  29. -- 
  30. MS-DOS is the OS/360 of the 1980s.      | Henry Spencer @ U of Toronto Zoology
  31.               -Hal W. Hardenbergh (1985)|  henry@zoo.toronto.edu  utzoo!henry
  32.