This commit is contained in:
Andy McFadden 2015-08-04 17:16:58 -07:00
commit 01dcee3b6a
1 changed files with 26 additions and 15 deletions

View File

@ -82,16 +82,17 @@ of sample files, are provided on the [attached disk images](fhpack_disks.zip)
There are six disk images. The first three hold the slide show demo:
* LZ4FHDemo.do (/LZ4FH, 140KB) - Source and object code for the
* `LZ4FHDemo.do` (/LZ4FH, 140KB) - Source and object code for the
uncompression routines, plus a few test images and the Applesoft
"SLIDESHOW" program.
* UncompressedSlides.do (/SLIDESHOW, 140KB) - A set of 16 uncompressed
* `UncompressedSlides.do` (/SLIDESHOW, 140KB) - A set of 16 uncompressed
hi-res images.
* CompressedSlides.do (/SLIDESHOW, 140KB) - A set of 42 compressed
* `CompressedSlides.do` (/SLIDESHOW, 140KB) - A set of 42 compressed
hi-res images.
To view the demo, put the LZ4FHDemo image in slot 6 drive 1, and one
of the slide disks in slot 6 drive 2. Boot the disk and "-SLIDESHOW".
To [view the demo](https://www.youtube.com/watch?v=sNBSd1oGGaU),
put the LZ4FHDemo image in slot 6 drive 1, and one
of the "slide" disks in slot 6 drive 2. Boot the disk and "-SLIDESHOW".
Just hit return at the prompt to accept the default prefix.
The slideshow program will scan the specified directory and identify files
@ -105,12 +106,14 @@ uncompress it than it is to load an uncompressed image.)
There is a second demo, called "HYPERSLIDE", which shows off the raw
performance by eliminating the disk accesses. A set of 15 images is loaded
into memory -- overwriting BASIC.System -- and presented as a slide show
as quickly as possible. The demo and selected images are on this disk:
into just 24KB of memory -- overwriting BASIC.System -- and presented as a
slide show as quickly as possible. The demo and selected images are on
this disk:
* HyperSlide.po (/HYPERSLIDE, 140KB)
* `HyperSlide.po` (/HYPERSLIDE, 140KB)
To run the demo, put the disk image in slot 6 drive 1, boot the disk,
To [run the demo](https://www.youtube.com/watch?v=Wwg84nIkRZU), put
the disk image in slot 6 drive 1, boot the disk,
and "-HYPERSLIDE". If you are running on a IIgs, you may want to try it
with the 65816 uncompressor, which is much faster than the 6502 version.
If you want to compute frame timings, you can set an iteration count,
@ -119,10 +122,10 @@ and the slide show will beep at the start and end.
A larger set of images is available on a pair of 800KB disks. One disk
has the compressed form, the other the uncompressed form:
* UncompressedImages.po (/IMAGES, 800KB)
* CompressedImages.po (/IMAGES.LZ4H, 800KB)
* `UncompressedImages.po` (/IMAGES, 800KB)
* `CompressedImages.po` (/IMAGES.LZ4H, 800KB)
It's worth noting that the images on CompressedSlides.do take up about
It's worth noting that the images on `CompressedSlides.do` take up about
135KB of disk space, but are about 104KB combined. The rest of the space
is used up by filesystem overhead. Storing them in a ShrinkIt archive
would be more efficient, but would also make them far more difficult
@ -142,8 +145,8 @@ about 3.7 fps, with very little variation between files. The decode
time is dominated by byte copies, and we're always copying 8KB, so the
consistency is expected.
HyperSlide still has some overhead from Applesoft BASIC. The "blitz
test", included on the LZ4FH demo disk, generates machine language
HyperSlide incurs a fair bit of overhead from Applesoft BASIC. The
"blitz test", included on the LZ4FH demo disk, generates machine language
calls that uncompress the same image 100x, eliminating all overhead
(and simulating what HyperSlide could do if it weren't written in
BASIC). The speed improves to 5.6 fps.
@ -161,7 +164,8 @@ $02FC and $02FE. In the current implementation, the output buffer must
be $2000 or $4000 (the two hi-res pages).
Packed images use the FOT ($08) file type, with an auxtype of $8066
(0x66 is ASCII 'f').
(0x66 is ASCII 'f'). These files can be viewed with
[CiderPress](http://a2ciderpress.com) v4.0.1 and later.
## Experimental Results ##
@ -268,3 +272,10 @@ Note: test/nomatch is not compressible by LZ4 encoding. fhpack was able
to compress it because it zeroed out the "screen holes". When processed
in hole-preservation mode, test/nomatch expands to 8292 bytes.
LZSS, which was used by HardPressed to get reasonable compression with
fast decode speeds, reduces the corpus to 243991 bytes (36.7%), making it
a viable alternative. It's generally inferior to LZ4 as the maximum
match length and offset are much shorter, but that's not too significant
for hi-res images. Literals are identified with individual flag bits,
rather than as runs of bytes, which reduces performance for long strings
of literals.