Listen up: 15 fps and slot 3.

[toddpw@pride.ugcs.caltech.edu (Todd P. Whitesel)]

Pardon the redundancy in places, but we've wasted enough bandwidth guessing
and theorizing about these already. I had to post this because somebody let
the "15 fps" figure spook him without any real understanding of what that
number represents (less than most of you probably think; read on).

The SS video shadowing mode has to operate much like the VOC in that it does
not run in sync with the motherboard video. There is no way around this
requirement if you want higher refresh rate video displays, because those
by definition do not scan at the same rate as the GS motherboard video.

How this shadowing works: the video card watches the bus for writes to video
memory. On the //e you can figure everything out by watching the softswitches
but on the IIgs you need the M2B0 pin to identify banks $E0 and $E1 reliably.
On the ROM 01, this pin is only wired up on the slot 3 connector, and on the
ROM 03, it is wired up on every slot _except_ 7. (There's a color reference
signal there already, which dates back to the ][+.) By runing a jumper wire
you can make M2B0 available on any slot except 7 (because of the signal
that's already there).

(While I'm talking about slots, the ZipGS can go in any slot as long as the
CPU cable is long enough to reach. It does not conflict with any firmware,
so you never have to set that slot to Your Card. I have made my own longer
cable -- the parts are all standard IDC connectors, a 40 pin DIP and 40 pin
IDC 2x20 header connector, and 40 pin ribbon cable -- and it works fine in
slots 1-5. I didn't try 6, I have the AudioAnimator there already.)

Once the card has captured this data it has to translate it into its own
video buffer so it can be redisplayed. On the VOC the video buffer is
part of a literal copy of the IIgs motherboard video system (including both
a VGC and Mega II), so a triad of FIFOs and some gate array logic (on one of
the big Xilinx chips) take care of it. On the SS board, Jawaid is trying to
avoid extra costs by using the quick Z80 derivative microcontroller to do
most of the work. This thing has to be keeping up with all the GS's video
writes or else it would lose updated pixels randomly.

This means the SS video buffer _will_ shadow the GS video buffers exactly.
However, you don't automatically get perfect video from this, for the same
reason 3200 pictures and FTA demos didn't look right with the VOC -- they
all use the motherboard video signal as a timing reference, and the card's
own video typically cannot stay in sync with the motherboard.

On the VOC, synchronization can be achieved by genlocking to the motherboard
video output and forfeiting the overlay capability while you do it. To overlay
you cannot stay in sync with the motherboard, because you have to stay in
sync with the incoming video signal instead. The alternative is to rewrite
the graphics programs to be VOC aware.

On the SS board, it should be possible to sync with the motherboard video for
backwards-compatible screen modes, although that may require extra hardware
which will bump up the cost (Jawaid?). However for higher resolution modes you
must generate that mode's timing, so keeping sync with the motherboard video
is impossible. The _apparent_ refresh rate you'll observe will look jumpy
because of the synchronization problem, and will mostly show up as excessive
tearing -- really high performance animation is screwed because if the shift
between the two video signals is just right, you'll draw something and then
erase it before the SS video gets to it again, and never see what you drew.
The faster the SS video refresh rate, the less blatant this will be, but you
would need to run at 120 Hz (!!) to really fix the problem, and it would
still show plenty of tearing.

I honestly do not know where Jawaid is getting that 15 fps figure. It must
be an absolute worst case scenario -- 2 60 hz frames to send up a full SHR
screen image with DMA, then another two frames to guarantee the SS video
displays all of the new image at least once? That is really pessimistic
in terms of other programs, which is what most people are probably thinking
of here. When Jawaid says 15 fps, everybody else thinks "oh my god, it
must look like finder does when I leave Normal Speed turned on in the
control panel". It won't.

This synchronization problem is fundamental to the way these boards have to
work. Apple poured chips onto the VOC and had to charge $400 for it, and
THEY couldn't avoid the problem either. There is only one way to totally
avoid the problem, and that breaks LOTS of software: tamper with the GS
motherboard video so that IT syncs to the new video board instead of the
other way around. I don't think this is a viable option. In fact I'm not
even sure how you might do it without some gory motherboard trace hacking.

Todd Whitesel
toddpw @ ugcs.caltech.edu