On Oct 24, 1:40 pm, Dave Pollum <vze24...@verizon.net> wrote:
> On Oct 24, 2:15 am, Antti <Antti.Luk...@googlemail.com> wrote:
>
>
>
> > On 24 Okt., 07:50, Peter Alfke <al...@sbcglobal.net> wrote:
>
> > > On Oct 23, 5:27 pm, "David Spencer" <davidmspen...@verizon.net> wrote:
>
> > > > <MikeShepherd...@btinternet.com> wrote in message
>
> > > >news:[email protected]. .
>
> > > > > Although it's not expressed in DRAM specs and you wouldn't want to
> > > > > rely on it, the effect of reducing refresh rate is to increase the
> > > > > access time. I'm not up-to-date with DRAM technology, but my
> > > > > experience with devices 30 years ago was that you could turn off
> > > > > refresh (and all other access) for 10s or more without losing the
> > > > > contents, provided you weren't pushing the device to its access time
> > > > > limits.
>
> > > > > So, it's not impossible that reducing refresh rate would have a use
> > > > > (albeit outside the published device spec). But, as you suggest, it
> > > > > would help if he would just tell us what he's trying to do.
>
> > > > > Mike
>
> > > > Although that may well be the case for asynchronous DRAMs (because the
> > > > reduced charge in the memory cell capacitor would mean that the sense
> > > > amplifier took longer to register the state), this would not be the case for
> > > > SDRAM since this registers the outputs a fixed number of clocks after the
> > > > access starts. If the underlying access time increased by too much then the
> > > > data would just be wrong.
>
> > > For certain addressing patterns, the refresh can be eliminated
> > > alltogether, when the addressing sequence is such that all (used)
> > > memory cells are naturally being read, and thus refreshed, within the
> > > required time.
> > > Peter Alfke- Zitierten Text ausblenden -
>
> > > - Zitierten Text anzeigen -
>
> > Sinclair ZX?
> > at least some old Z80 homecomputers used refresh by video scan
>
> > Antti
>
> If I recall, the Apple II also refreshed its RAM this way, too.
> -Dave Pollum

The TRS-80 Color Computer (Moto 6809 based) refreshed during the
vertical retrace. But there was a bit in the system controller that
could be set to turn it and video access off, while doubling the
processor clock. As long as your Basic code was running, and not
waiting on a keyboard input or other event, the ROM interpreter's RAM
accesses managed to keep the RAM (at least the part of it being used)
refreshed. But if/when the code hit an error (and thus waited for user
response) you could watch the screen go from random pixels to all
white. Once the coding errors were eliminated, it was a reliable way
to double the processing speed when you did not need video.

Ah the good old days... but, I digress.

Andy