Vapor bytes and DVR graphics mode

["Joel" <joelbuckley54.nospam.@hotmail.com>]

"Michael J. Mahon" <mjmahon@aol.com> wrote in message
20021024043021.08815.00000724@mb-ba.aol.com">news:20021024043021.08815.00000724@mb-ba.aol.com...
>
> Joel had it exactly right, and it's the same for any undecoded read
> address, whether in RAM space or I/O space:  the last accessed
> video byte is held by the capacitance of the tri-stated bus and is
> read as data.  (For the 8-bit Apples--the IIgs is a different beast.)
>
> This finding was the basis for Dan Lancaster's (and Joel's!) "vapor
> lock" technique--so-called because it locks the Apple's program
> execution to the video generator by reading the "vapor" bytes
> of the video refresh.
>
> If you try reading a non-existent address in the monitor, you will
> see lots of $A0's, since the text screen is mostly blank.
>
> Aside from a very few programs that use this technique to
> synthesize a mixed video "mode" in software, practically
> nothing depends on this effect for correct operation.  (Probably
> just as well, since it would be very inefficient to emulate
> precisely.  ;-)
>
As my fading memory is jogged, besides a light pen,
I believe I may have also used this technique
in a 384 line, double vertical resolution, modification for the Apple ][+