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