Path: utzoo!attcan!uunet!maverick.ksu.ksu.edu!zaphod.mps.ohio-state.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: <1990May28.105321.27174@laguna.ccsf.caltech.edu>
Date: 28 May 90 10:53:21 GMT
References: <2850@crash.cts.com>
Sender: news@laguna.ccsf.caltech.edu
Organization: California Institute of Technology, Pasadena
Lines: 47

Eh... you don't need any fancy hardware at all. There's a software polling
method that works with a bare motherboard, and many common peripherals can be
pressed into service as interrupt sources if you have some test-clips lying
around (of the kind used to make removable shift key mods, there is a Radio
Schlock part number for them but I forget what it is, I still have plenty of
them in working condition).

You can poll the video data to determine when VBL begins, but you do need to
ensure that the last screen hole of the currently displayed video buffer is a
unique value (say $ab) and that the value appears nowhere else in the buffer.
You can read the last byte read for video by reading any softswitch or unused
location (I like $C040 but any location that doesn't read anything will do, as
long as the effects of that location are inconsequential to your program):

	lda	#$ab	;put your unique value here and in the last screen hole
vblwait	
	cmp	$c040	;or other unused location
	bne	vblwait
	...

You are now synchronized to the start of VBL.

How it works: when you read from a location that doesn't put anything on the
data bus, the last value read for video is still floating around and that's
what gets read (unless you have a really bizarre card plugged in). By putting
a unique value in the last screen hole (it gets read during blanking just
before VBL) you can poll for it using the loop above. Note that in a 1 mhz
machine the loop takes 7 cycles, which means that only 7 consecutive unique
bytes are needed to guarantee synchronization (make sure interrupts are set --
if they aren't then you should be using an interrupt source as the time base)
but I prefer using a full 8 just in case.

A much better solution is to use the 30 hz IRQ from an Apple Cat (very easy,
I wrote a cheap clock driver for it) or to program the timers on a Mockingboard
for regular interrupts. If you really want to get cheesy and have a spare
super serial card lying around, you can use transmit interrupts to get a time
base -- the handler should transmit a garbage character and do its processing.

Even better, test-clip the high-order bit from the video counter (it's a pin on
an LS161 at D-something) to either the modem control inputs of a busy SSC
(the serial chip will interrupt when either modem line changes state so you get
interrupts on both edges of the signal) or to an unused CA input on a
Mockingboard's 6522's (with these you can select which edge of the signal you
want an interrupt on).

Todd Whitesel
toddpw @ tybalt.caltech.edu