Clumsy (but pretty!) attempts to map video scanner's memory access

This discussion concentrates on Apple computers that use 60Hz video.

In his 1983 book Understanding The Apple II James Sather published detailed maps of the video memory accessed by the video scanner in the Apple ][ and Apple ][ Plus in order to display hires graphics.  And he published similar tables for the Apple //e in his followup book Understanding the Apple IIe.

The data for the hires graphics screen occupies 8192 bytes of memor, of which 7680 bytes of data are transmitted as pixels and 512 bytes are "hidden" in non-displayed regions.  The video scanner reads 17030 bytes of data from memory during each video frame, so some bytes are accessed more than once...even though they are only displayed one each.

How could I build a map of the hires screen to show how many times each byte is accessed during each frame?

I ran a series of experiments that attempted to count accesses one-column-at-a-time by plotting binary index-numbers in the hires graphics memory, then sampled the "vapor" from the video scanner and kept counts of how often each index appeared.  Each column was sampled until the counters filled, then the program cleared the screen and repeated the procedure for the next column.

capture168.png

When all columns had been sampled, the program displayed a map colored to indicate how many times each byte had been accessed during each frame.

My first results were not very believable, especially the black ones in the two top rows, which implausibly suggests those pixels are displayed but never accessed.

capture161.png

The following picture showed a bias that caused each column to sample only-odd-rows or only-even-rows. 

capture165.png

The next one added an spare index in a different column from the one being sampled.

capture171.png

Next I tried writing the samples directly into an Apple II Memory Expansion Card (aka: 'slinky') and counting them after enumerating 17030 locations in a 17-cycle loop, for a duration of exactly 17 video frames.  I hoped that would eliminate the noise by capturing precisely one sample per position, but it massively intensified the noise.  The memory-scanning patterns are visible through the noise, but it's a real mess!

capture176.png

I went back to the previous method, but eliminated branches within the sampling loop to ensure exactly 23-cycles per sample.  (23 is a primitive root mod 17030)

capture167.png

Finally, it emitted a mostly-plausible map.  Green pixels indicate bytes that are scanned only once per frame, which means the video scanner only reads them while it's actually drawing them on the screen.  Purple bytes are those that are scanned twice, mostly during the horizontal blanking interval.  Orange bytes are accessed three times -- the vertical column between the green and purple regions occurs because the video scanner doesn't increment the first address it reads during the horizontal blanking interval, so bytes in that column get accessed an extra time.  Blue bytes are accessed four times or more during the vertical blanking interval, where the video scanner repeats the same six lines until the next video frame.

capture180.png

There are still a few suspicious details in that vapor map, such as an unexplained gap in the upper line of blue pixels, so I might tinker with it again.