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