7

The Apple IIe, IIc, IIc plus, and IIgs had ways to detect when the video signal was in the vertical blanking period. These were:

  • Setting a soft-switch in the mouse interface that triggers an interrupt on VBLANK (GS was slightly different)
  • Reading the most significant bit of $C019 (reads 0 on blank, from Apple II video timing)

Was there a way to detect a vertical blank in the Apple III and Apple IIIplus?

Improve this question
9
  • 2
    IIRC there was also a complicated way to do that on the Apple II, using the fact that framebuffer reads were mixed with normal reads and would leave residual charges in some circuitry if you read from the right "empty" addresses. But I've forgotten details.
    – dirkt
    May 19 at 5:12
  • 5
    Found it, this technique is called vapor lock.
    – dirkt
    May 19 at 5:22
  • Don Lancaster is a genius. I wonder what he's been up to.
    – rbanffy
    May 19 at 8:38
  • @dirkt: Vapor lock is complicated, but it allows higher precision than would be possible by simple retrace polling. Using vapor lock, a program that never needs to do more than a couple milliseconds or so of processing per frame could overlay text onto lores graphics almost arbitrarily, with the only limitation being that any horizontal span of text or graphics must be at least four characters/lores pixels wide.
    – supercat
    May 19 at 16:35
  • 3
    @supercat The main problem it solves is that on the Apple II, you cannot do retrace polling. Because there is no register for that. "Higher precision" is irrelevant.
    – dirkt
    May 20 at 9:05

2 Answers 2

Reset to default
8

Yes, it is possible.

I'm annoyingly unable to find a simple technical reference, but from the Apple III SOS source code:

[Page 5]
2EF8:  *
2EF8:  *   6522 REGISTERS
2EF8:  *
...
2EF8:  E.IFR EQU $FEED

[...]

[Page 8]
DF77:AD ED FF      264       LDA   E.IFR
DF7A:29 28         265       AND   #$28          ;GET VBL & BL FLAGS
DF7C:F0 28   DFA6  266       BEQ   VID030
DF7E:8D ED FF      267       STA   E.IFR         ;CLEAR FLAGS
DF81:29 20         268       AND   #$20          ;WHICH FLAG?
DF83:D0 12   DF97  269       BNE   VID010        ;BL

i.e. the vertical blank is wired up to the 6522's CB2 input. See further commentary from the top of Page 8:

SUBROUTINE VIDEO

THIS SUBROUTINE POLLS THE VERTICAL-BLANKING AND COMPOSITE-BLANKING-TIMER FLAGS AND TURNS THE SCREEN OFF AND ON SO THAT ONLY THE MESSAGE WINDOW WILL BE DISPLAYED.

THE E.6522 MUST BE INITIALIZED SO THAT E.CB2 FLAGS THE POSITIVE EDGE OF VBL AND E.T2 COUNTS BL PULSES. THE INTERRUPTS MUST BE MASKED AND THE PROPER COUNT MUST ALREADY BE STORED IN THE LOW ORDER BYTE OF E.T2.

Addendum: per the relevant schematic VBL actually seems to be wired to both CB1 and CB2. The 6522 is depicted in the immediate top left.

Improve this answer
1
  • 1
    It's entirely possible that, since the /// was a big flop, nobody ever tried to make use of this feature (which is useful for games). I was thinking of (mis)using it to produce 384x560 interlaced graphics, since the ///plus has a switch that engages an interlaced video mode that repeats scanlines. But scanlines are repeated only because the page isn't flipped.
    – rbanffy
    May 19 at 20:06
5

According to the Apple III Standard Device Drivers Manual, the .CONSOLE device driver provides a function to wait for vertical blanking. This function could effectively replace the simple VBL polling routines that Apple II developers typically write for games and graphics demos.

You can wait for vertical blanking by sending the ASCII control code SYN (decimal 22, hex $16) to the .CONSOLE driver. This can be used to synchronize video animations, or for general timing (e.g., printing a string of 30 SYN bytes would perform a half-second pause)

From the device driver manual, page 43:

SCREEN SYNCHRONIZATION

Code 22, "SYN" (Synchronous Idle)

Causes the console to delay further processing until the video generator has finished displaying one complete frame on the video display. The video generator produces 60 frames each second; a SYN code can thus cause a delay of up to 1/60 of second.

One application of this control code is in programs that erase and redraw portions of the screen in a fixed cycle, to perform animation or other special effects. Sometimes the difference between the timing of the program's output and the timing of the video generator produces a distracting flicker of the screen. Sending a SYN code to the console as part of the erase/draw cycle will synchronize the program with the video display and reduce or eliminate flickering.

Another use of the SYN code is in timing loops. Since the video generator always produces 60 frames per second regardless of the screen setting, sending a string of 60 SYN codes will cause a delay of one second. You an use this to build fairly accurate timing loops into user programs.

Improve this answer
1
  • This is an amazing piece of Apple /// arcana.
    – rbanffy
    Jun 19 at 18:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .