Does the Apple II's non-linear frame buffer layout help DRAM refresh?

Question

The Apple II uses non-linear frame buffers for text and graphics. Rather than storing each line in sequence at

lines  0-23: $400, $428, $450, $480,¹ ..., $7D0

it stores them at

lines  0- 7:  $400, $480, $500, $580, ..., $780
lines  8-15:  $428, $4A8, $528, $5A8, ..., $7A8
lines 16-23:  $450, $4D0, $550, $5D0, ..., $7D0

In other words, if you write linearly to the frame buffer, your data will appear first on the top line of the screen, then on a line a third of the way down, then on a line two thirds of the way down, then on the second line of the screen, and so on.²

In the answers and comments for What is DRAM refresh and why is the weird Apple II video memory layout affected by it?, there is extensive debate about whether this non-linear arrangement has anything to do with DRAM refresh. One answer says probably or yes, two say no, and one has no comment on the issue; comments on all answers that take a position argue it back and forth.

It doesn't look as if a clear answer to this is coming out of that question (which is asking about a lot more than the layout, anyway) so I'm creating this question to try to get a definitive answer on just this issue.

If the frame buffer were linear, would there be any way software could do something such that any DRAM row could be made to refresh less often than it would with the current non-linear frame buffer? If so, what would that way be?

Answers should either:

1. Clearly describe a program that on a linear frame buffer, but not on the current layout, would cause some DRAM rows to be refreshed at significantly longer intervals than they would be in usual operation; or
2. Explain why it's not possible to produce such a program.

---

^{¹ You might note that each third row in memory is 8 bytes longer than the other two, $30 instead of $28 bytes. Three rows of 40 characters (or 40 groups of 7 pixels plus a color bit in hires) sums to 120 bytes of storage; the extra 8 are padding to make the next row line up nicely. This is not just aesthetic, but helps with the hardware design.)}

^{² The addresses above are for the first page of text and low-res graphics; the high-res frame buffer starting at $2000 is the same arrangement with eight times as many rows. The Apple II Technical Reference Manual includes more detailed diagrams giving maps of the text, low-resolution graphics and high resolution graphics frame buffers.)}

Answer 1

On the Apple II, the values of address bits 0-4 and 7-9 during each part of a frame are independent of the graphics mode. Those eight bits are used to control the DRAM row address, and need to cycle through all possible bit patterns four times per frame (excluding bit 9, the remaining bits need to cycle through all bit patterns eight times per frame).

If e.g. the row addresses that connect to bits 7-9 incremented every scan line in hi-res mode, instead of incrementing every eight scan lines regardless of graphics mode, but the within each group of 64 scan lines, the first, ninth, eigteenth, etc. lines would generate the same addresses in both modes, then the maximum time between refresh for any particular address would be increased from 24 scan lines to 31 when using 7-bit row addresses, and from 56 to 63 when using 8-bit row addresses. I think that might push timings slightly beyond spec, but probably not enough to matter. A more interesting issue, however, would be ensuring that a mode switch can't occur while a row address is being generated. If the signals on the row wires change just as the DRAM chip is sampling them, this can cause arbitrary corruption of the data on both the old and new rows. This can actually happen on the Commodore 64 in some scenarios. While such possible timing issues could have been guarded against even if row addresses were dependent upon display modes, ensuring that timing margins will always be met even in such cases is harder than simply having the row value be independent of display mode.