On 10/13/2016 08:03 PM, smf wrote: > On 13/10/2016 15:28, Gerrit Heitsch wrote: >> How much of it is spent in the upper and lower border and the vertical >> retrace where no memory access happens (not counting an open border >> with sprites)? More than 2 ms? >> >> So in order to make sure that the DRAM is refreshed properly, they >> just implemented a refresh counter which does 5 cycles per scan line. > > I thought upper/lower border was always fetching $3fff? During the side > borders it's fetching sprites, so you can't rely on that for refreshing > > Doing 5 refresh cycles per scanline will take 51 scanlines to read all > 256 addresses. > After 51.2 scanlines the VIC should have read all 256 addresses, just by > character fetches. I doubt they thought they'd better put a separate > dram refresh in case someone figures out how to mess up the character > fetching (duplicating rows/vsp etc). > > There must be another reason. As I wrote, the reason is that you can disable all sprites, disable the display (and with it character fetches). Then put the CPU in a tight loop and you will not have enough memory access to refresh. Even if you couldn't disable display DMA, drawing the upper and lower border would take too much time. Reading $3FFF means it will refresh row $FF, but not the other 255 rows... Gerrit Message was sent through the cbm-hackers mailing listReceived on 2016-10-13 21:00:02
Archive generated by hypermail 2.2.0.