toddpw@tybalt.caltech.edu (Todd P. Whitesel) (10/04/90)
Ok, here is the 3200 color vs. the VOC post that I promised a week and a half ago. Immediately after I mentioned it, our news system started having problems and by the time they were fixed I was too busy packing to go back to school (previously I telnetted in from work). Now, without further adieu: Why the VOC hates 3200 colors and some ideas on how to fix it. First, a quick summary of how 3200 colors works: the IIgs is capable of displaying more than one color palette -- the video hardware supports 16 palettes which may be selected on a line by line basis. Before each line is put on the screen, the video hardware reads a Scanline Control Byte to determine the resolution to use, whether or not to use fill mode (if the resolution is 320), whether or not to interrupt the CPU at the end of the line, and which palette (16 are built in) to use. The menu manager uses extra palettes to get the pure colors in the Apple menu, and sometimes you see a 'rainbow' stripe in the menu bar because of it. Since the hardware reads in each scanline's palette just before the line is displayed, what happens if we watch the video beam and stuff a new palette into memory just before the video hardware reads it? We get a fully independent palette for every scan line, for a total of 200 instead of 16. However, over 80% of the CPU time is spent replacing palettes and the margin for error is farily small. Enter the Video Overlay Card. This card contains a carbon copy of the GS video system with various enhancements added (kludged around the original chipset, actually, although it didn't have to be that way): a second super hires graphics page is available (same addresses, except in bank $e0, for those of you who care) and support for interlaced video and genlocking. Genlocking is the card's reason for living and means that the on-card video system synchronizes its video display to an incoming video signal and then mixes the two to provide the overlay effect which is often used for computer subtitling. Now the important thing to remember is that the video signals we are talking about have horizontal and vertical 'carriage returns' encoded into them -- all TV's and monitors genlock their video beam to the incoming signal and that is how you get a stable picture no matter where the signal came from. When I was a kid I used to wonder how the TV knew when to start drawing the top corner of the image; the answer is it figures it out from the signal itself. The video overlay card's genlock is more complex in that it takes a standalone video generator (the IIgs video system) and tweaks it to make it genlock with an incoming signal. When you have a VOC in your system, you effectively have two IIgs video systems, except the VOC is designed to shadow the IIgs's video buffers so that no special software is needed to run existing programs with a VOC installed. The VOC is primarily designed to slave to the GS's video buffers -- but the video scanning of the two are not guaranteed to have any relationship whatsoever. This means that a 3200 color viewer which is tracking the motherboard video beam location has no idea where on the screen the VOC is currently displaying. This is why 3200 color pictures look wrong on a VOC -- the viewer is stuffing palettes at the right times for the motherboard video generator, but for the VOC picture the palettes are going to be wrong because the VOC is not on the same lines as the motherboard. An easy fix here is to connect the VOC's input to the motherboard compsite out, and set the mix control to all graphics. This is however a hardware solution and it would be far nicer to find something that works even when the VOC is genlocked to an external signal (your VCR, for example). I have hacked the VOC hardware a bit and can manipulate the second SHR buffer and the interlace controls -- it is possible to have normal SHR out the GS monitor port and page 2 SHR out the VOC monitor port simultaneously (can you say two monitors? I knew you could!) but I haven't done anything practical with it yet. (Can anyone tell me how Apple's CloseView works? I know the principle but I am not sure how the actual implementation should be done -- compatibility, ya know.) The VOC Vertical Banking signal can be read from $C0B0, I forget exactly which bit it is -- mail me and I'll dig the notes up. However, I don't know if a satisfactory 3200 viewer can be made with only the VBL signal. Another idea is to poll the VOC VBL and the motherboard video beam position and keep track of the phase difference between the two -- this should be accurate enough to allow good 3200 color display because the VOC and the motherboard are not going to drift very much during the time of one video frame -- unless the VOC is busy re-genlocking and that will cause video glitches on screen anyway so the 3200 color viewer really doesn't need to worry about it except to guard against crashes. To my present knowledge, this is all that can be done, but there are more bits in the VOC registers that I don't understand yet so it may be possible to get the VOC to generate its own interrupts in which case things should become much easier. Also a method of reading the VOC video counters directly would be great but I haven't discovered one yet. Todd Whitesel toddpw @ tybalt.caltech.edu