Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utcs!utfyzx!oscvax!rico
From: rico@oscvax.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: Juggler Workings
Message-ID: <469@oscvax.UUCP>
Date: Fri, 9-Jan-87 14:24:14 EST
Article-I.D.: oscvax.469
Posted: Fri Jan  9 14:24:14 1987
Date-Received: Sat, 10-Jan-87 02:46:09 EST
References: <345@neoucom.UUCP> <1284@cadovax.UUCP>
Reply-To: rico@oscvax.UUCP (Rico Mariani)
Distribution: na
Organization: Ontario Science Centre, Toronto
Lines: 23
Summary: HAM display should make decompression slower but it's still fast

In article <1284@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes:
> [edited]
>The startup message on the Juggler program implies that the individual
>frames take up 10k and are decompressed on the fly.  If this is true,
>is the compression/decompression mechanism proprietary or can we be
>let in on this little trick? 
>				....

Something just dawned on me that makes me even more impressed with the
Juggler program's decompressing.  All of the decompressing is happening
while a HAM picture is being displayed.  Think about that for a minute,
HAM pictures have 6 (count'em) bit planes!  There isn't very much memory
bandwidth left when using 6 bitplanes.  In fact, if I remember
correctly, the CPU can only run during horizontal and vertical retrace. 
Now that uncompressing thing must really be doing something slick (or
something dirty -- or is that the same thing :-) ).

The canonical compression method (xor frame n with frame n+1 and run
length encode the "difference") probably isn't good enough for this. 

	So tell us how you did it already... the suspense is killing me!

		-Rico