DRAM refresh

From: Marko Mäkelä <msmakela_at_gmail.com>
Date: Thu, 13 Oct 2016 08:45:12 +0300
Message-ID: <20161013054512.tuklg6jy4o52632d@x220>
On Wed, Oct 12, 2016 at 10:49:09PM +0100, smf wrote:
>The apple 2 apparently doesn't have dram refresh, it uses the video 
>fetches to refresh the memory. I'm not sure why the c64 is different.

I think that the memory refresh access cycles (5 per scan line) come 
into rescue when the video output is blanked, no sprites are enabled, 
and the CPU is executing in a tight loop, covering only a few addresses 
for a longer period of time. In this configuration, the VIC-II would be 
accessing $3fff all the time, except for the 5 refresh cycles per scan 
line. This is also what happens when the vertical border or the vertical 
blanking is being generated.

If it is not possible to disable the screen output on the Apple II, then 
the regular accesses for the video matrix data could act as memory 
refresh as a side effect.

By the way, VICE should correctly emulate the memory accesses of the 
VIC-II, because it is capable of running the "dadb" test program that I 
wrote over 20 years ago. This program executes requires exact timing, 
because the least significant 4 bits are mostly fetched from the colour 
RAM (mostly from the address $dadb) while the most significant 4 bits 
are 'phantoms' of VIC-II data fetches from DRAM.

Those who are interested could loko at cycle_phi1_fetch() in 
vice/src/viciisc/vicii-cycle.c and vicii_fetch_refresh() in 
vice/src/viciisc/vicii-fetch.c. The DRAM refresh cycles look like reads 
from $3f00 + an 8-bit counter that is decremented on each access.

By the way, how long would the DRAM contents survive without refresh?  
Maybe it is possible to find this out on a C16 or plus/4, by 'halting' 
the TED for some time by constantly resetting one of its horizontal 
counters?

	Marko

       Message was sent through the cbm-hackers mailing list
Received on 2016-10-13 06:00:02

Archive generated by hypermail 2.2.0.