Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!jarthur!nntp-server.caltech.edu!tybalt.caltech.edu!toddpw
From: toddpw@tybalt.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: Hardware Project for II+
Message-ID: <1990Jun6.233639.9731@laguna.ccsf.caltech.edu>
Date: 6 Jun 90 23:36:39 GMT
References: <13128.infoapple.net@pro-generic> <24786@athertn.Atherton.COM>
Sender: news@laguna.ccsf.caltech.edu
Organization: California Institute of Technology
Lines: 61

paul@athertn.Atherton.COM (Paul Sander) writes:

>I also understand that some folks reading this newsgroup have some way of
>storing particular values in the unused locations scattered about the text
>and hires pages, and then watch some unused location in the motherboard's
>I/O page for those particular values.  It seems that these values will get
>latched someplace where a program can see them during the retrace intervals.
>All of this is undocumented by Apple, of course, but I seem to recall quite
>a bit of discussion about this around two years ago.  Can someone elaborate
>on this technique, and is it still used?

I did in an earlier response to the first post, but here goes:

The unused locations are what are known as "screen holes" -- in every display
buffer on ][+ and //e the last eight bytes of every half page are not displayed
on the screen. In Main Text Page 1 the screen holes are reserved for the slots,
and some of the values are defined by Apple for various purposes. Using the
text screen holes is probably not such a hot idea unless you know what you are
doing.

The hires screen holes, however, are truly unused, and the technique involves
storing a unique byte value into the last eight bytes of the video buffer (i.e.
the last screen hole) -- this unique value must not appear anywhere else in the
buffer.

On the ][+ and //e (and even on the GS) reading from a location that does not
_in_the_hardware_ return any data (in the GS there are some unused locations
that always read zero) then whatever was last value on the data bus will still
be floating around and will get read; that last value just so happens to be the
last byte read by the video chips. So if you load the unique value into the
accumulator and do

.loop	CMP unused_I/O_loc
	BNE .loop

then you will essentially wait for VBL, because the last screen hole is read by
the video system just after the end of the last line on the screen, i.e. the
start of VBL. Those eight bytes are never displayed, but they _are_ read by the
video system at that time. (There is, of course, a reason for it. The video
address is also used as a refresh counter and while not every byte is displayed
they must all be read every so often, to keep the DRAMs from losing data.)

This technique is no longer in actual use as far as I know, but it is a rather
fascinating exploitation of the original video system design. There are much
better (read more accurate and less CPU overhead) methods of accomplishing the
same objective in the //e and especially in the GS, and this particular quirk
is one I would not mind Apple dropping support for; they would then have the
freedom to implement the video system using newer technology (horrors! An Apple
II that uses new technology!), namely Video RAMs.

Video RAMs are just one of the newer technologies that can save the Apple II,
if Apple would only admit that the IIGS video system is a kludge (which it is,
but doesn't have to be) and that the Video Overlay Card is an overpriced kludge
(which it is, but doesn't have to be).

Apple has always been so concerned about compatibility -- but the turning point
will be when they finally realize that the few issues which really hold back
development would never be missed by 99.9% of the user base.

Todd Whitesel
toddpw @ tybalt.caltech.edu