Sounds like great fun!

Since the time to transfer a frame is certainly known as soon
as it is captured (even if it is, say, run-length compressed),
the frame rate can be made adaptive to the content.  In other
words, if it can run faster, it does.

As David pointed out, the IIc is quite capable of 115kbps with just
a single extra POKE for configuration.

And what you propose is *very* much like video streaming from a disk
file, but with a serial link instead and possibley some decompression
code.

Not if it saves more data transfer time than it costs in processor
time.  That's the tradeoff to examine, and it, of course, depends
critically on the actual serial data transfer rate.  At 115kbps, it
may be necessary to forego decompression just to maintain the UART
transfer rate.  For example, interrupt processing of UART data is
not the way to go at this rate--just simple polling and data storage.

There will be time in the loop to detect a simple protocol escape...
I'd recommend using it to trigger page-flipping at end of page and
any other things you might want to add.  If you want to add keyboard
sensing, then that will cost another 6 cycles per received character
to test and a loss of some incoming characters when a keypress is
sensed and acted upon.  A back of the envelope estimate indicates
that this will fit into the receive loop at 115kbps (~78 cycles/char).

The basic loop looks like it's about 30 cycles with a simple escape
test, so it shouldn't be critical as long as one byte value can be
dedicated to the escape function.  And even in this case, a second
consecutive "escape" could result in a return to the storage loop
to store the "escape" byte:

loop   lda  UAstat,x   ; UART have char?
        and  #mask      ; Mask status
        bxx  loop       ; -No, wait.
        lda  UAdata,x   ; -Yes, get char.
        cmp  #escape    ; Cmd escape?
        beq  cmd        ; -Yes, do it.
        sta  (zp),y     ; -No, store it
        iny             ;   and increment
        bne  nocar      ;    store address.
        inc  zp+1
nocar  lda  kbd        ; Key pressed?
        bpl  loop       ; -No.
        ...             ; -Yes, process key.
        jmp  loop       ; Return to loop, having missed x chars.
                          <Since the sending machine cannot anticipate
                           this, it will be necessary to either "flush"
                           the in-process page, for which sync has been
                           lost, or keep accurate track of how many
                           characters were lost and resume the loop with
                           Y and (zp) incremented accordingly (to just
                           re-use the previous valued for the skipped
                           bytes.>

cmd    <receive another character as above>
        <switch on char value to cmd routine>
        <each cmd routine misses x chars, where x could be
         zero for very simple commands, like page flips>

When you decide to switch to hi-res, you'll be filling the hi-res
buffer while continuing to display the last full lo-res buffer, I
presume.  So if you don't finish transferring the full hi-res
screen, the partial frame transfer would never be visible.

Those can all be done, but will necessarily require either a "pause"
in data transmission, or, perhaps better, a pre-computed number of nulls
inserted in the stream after a protocol command to allow for processing
time on the Apple side.  Each "long" command could finish in a routine
to receive bytes until a "data restart" byte is received, which would
then return to the main loop.

For highest speed, the protocol will need to be pretty "fragile",
with recovery from a data transmission error essentially awaiting
the next re-syncing event, but it should be fine for a local serial
link.  Command decoding may need to include some redundancy to prevent
wild transfers of control (I would favor a direct vector through a
table with, perhaps, a requirement that the command byte be sent
twice, in both true and compliment form to add some robustness.)

I hope you give it a shot--it would be fun, and might open the
door to other "streaming video" activities.

-michael

NadaPong: Network game demo for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."