On Sat, 26 Feb 2000 18:58:30 GMT, rich12345@my-deja.com wrote:

>Following this message is a post we found here on CSA2 programmer.
>Is it true that C054 is equal to the byte being displayed?

Yes, in a sense.

You can poll pretty much any unmapped video switch ($C050 through
$C057 as well as others) and the result will be a value from somewhere
in video memory.

However, memory isn't just read in a linear fashion, but rather in
the way it is scanlined.

Furthermore, remember that there are bytes in the $2000-3FFF (or
$4000-5FFF) range that do not visibly map to the screen, but these
still show up when polling the video switches. So, for this reason,
it isn't entirely accurate to say that the value is equal to the
byte "being displayed".

You can certainly "tag" the screen memory with a specific sequence
of bytes and then sit in a tight loop waiting for those specific
values to show up and then flip to a different screen mode.

This way, you can actually program "impossible" screen modes, such
as lowres on the top half of the screen and hires on the bottom
half.



Nathan's information below is certainly correct:

>It's complicated, but I hope it helps.  The value at $c054 (and lots of
>the other video switches) are equal to the byte being displayed.  The
>image is refreshed from top to bottom, each line left to right.  At 1 mhz,
>each byte requires 1 cycle to display, and a "linefeed" from right back to
>left and down a line requires 25 cycles --> total for each line = 40+25=65
>cycles.
>
>65*192 = 12,480 cycles to refresh all the screen, but a "form feed" back to
>the top requires an additional 4,550 cycles. (equal to 70 lines) 12,480 + 
>4,550 = 17,030 cycles.  This is linked with the cpu clock, so it is 100%
>accurate with the cpu's cycle time.  When counting cycles, beware of
>the branch across page boundaries!  Your task is difficult, so I wish you
>luck.  If I can be of further help, lemme know.
>
>FISHER2557@ISCSVAX.UNI.EDU
>Nathan Fisher

but in addition to this I thought I'd point out that this is only
true for an NTSC Apple II. For a PAL Apple II the math looks a little
bit different.

For both machines we have that a full scan line is 40 + 25 = 65 cycles
(40 for the visible part, 25 for the horizontal blanking).

As a side note, if you are clever enough to chunk your program in such
a way that it consists of 65 cycle chunks hitting the appropriate
video switches every 65 cycles, you can actually split your screen
vertically -- having, say, lores on the left and hires on the right.

I one wrote a piece of code that with some tricky cycle counting
combined the vertical and horizontal split so that I had a low-res
window bouncing around on a hires screen! Suffice to say it took a
while to get the timings right. But I digress.

So, both NTSC and PAL are take 65 cycles for a scanline.

However, whereas NTSC has floor(525/2) = 262 vertical lines (192
visible, 70 for vertical blanking) for a total of 262*65 = 17030
cycles; PAL has floor(625/2) = 312 vertical lines (192 visible,
120 for vertical blanking) for a total of 312*65 = 20280 cycles.


There was an article in Softtalk (my favourite magazine of all time)
back in 1982 by Bob Bishop that had a full mapping of how how the
video hardware scanned the video ram and how this mapped into the
video switches.

If I remember correctly, there is also a section in Jim Sather's
"Understanding the Apple IIE" (and presumably also in "Understanding
the Apple II") that covers this in some detail. I don't have my
copy at hand right now, so I can't check (I highly recommend this
book for any and all diehard Apple II fanatics out there.)


Finally, I never verified this myself, but I was told that the
"floating bus" of the Apple II and Apple IIE allowing you to snoop
the video bus in this fashion, does not exist on the IIC. This may
or may not be true.


I hope this helps.

Christer Ericson
989 Studios, Santa Monica