Joshua Bell wrote:Sounds like great fun!
> I have an idea for an "art" project, of sorts - streaming video from a PC
> over serial to an Apple II. The idea is to present the appearance of a very
> "retro client" version of the immersive 3D client/server application my
> company creates on the Apple - just for fun.
> The basic idea is as follows:Since the time to transfer a frame is certainly known as soon
> * Service on the contemporary machine that takes frame-grabs of an
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.
> A lo-res screen is 40x48 or 1920 pixels/frame; 4 bits/pixel = 7680As David pointed out, the IIc is quite capable of 115kbps with just
> bits/frame. At 9600 bps that's about 1Hz refresh, which is a reasonable
> lower bound.
a single extra POKE for configuration.
And what you propose is *very* much like video streaming from a disk
> Notes:Not if it saves more data transfer time than it costs in processor
> * For maximum ease of setup, it would be ideal if the Apple side of the code
> could be bootstrapped like ADT
> * Based on David Schmenk's HBCC game, full-screen updates to the lo-res
> screen while doing lots of other processing seems entirely feasible, so I'm
> assuming that there are CPU cycles available for intra-frame compression and
> even inter-frame compression.
> * As an added feature... if the scene stops changing (to within some
> threshold), the code could switch from streaming a lo-res screen to a hi-res
> screen. This would take ~8 seconds (at 9600bps), but the result would be
> that after the scene becomes static for 8 seconds the image quality would
> increase dramatically, until the next change. To maintain the low latency,
> the hi-res stream would need be interruptable (i.e. if change is detected by
> the encoder, abort the transfer of the hi-res frame and resume lo-res
> frames) requiring a modicum of protocol design. Compression here would also
> be nice, but decompression on the Apple might be a killer.
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...
The basic loop looks like it's about 30 cycles with a simple escape
loop lda UAstat,x ; UART have char?
cmd <receive another character as above>
When you decide to switch to hi-res, you'll be filling the hi-res
> * Obviously, there's the possibility of adding additional bells andThose can all be done, but will necessarily require either a "pause"
> whistles, such as letting the Apple send keystrokes back "upstream" to drive
> the source application, or sidechannel streams e.g. to display text status
> displays on the Apple, trigger beeps, etc.
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",
> I haven't done any work on this and, truth be told, this is likely to be oneI hope you give it a shot--it would be fun, and might open the
> of those projects that never goes anywhere. But I wanted to throw out the
> idea for comments. Is there any other interest in this?
door to other "streaming video" activities.
NadaPong: Network game demo for Apple II computers!
"The wastebasket is our most important design
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.