Date   : Fri, 06 Oct 2006 02:45:29 +0100 (BST)
From   : Greg Cook <debounce@...>
Subject: Re: Compressed ROMFS?

On Mon, 18 Sep 2006 22:04:53 +0100, Sprow <info@...> wrote:

> For Huffman (since the decode table is in ROM) you'd just need one
> additional byte of storage somewhere to remember which bit position
> you were at within the byte (the MOS already sets aside two bytes to
> store the byte offset).
>
> I estimated the decode table would be about 720 bytes of ROM, assuming that
> you could never need more than 256 branches for a 256 character table, with
> each table entry needing a left and right branch. But then you've run out of
> bits to store when you'd hit a leaf, so I rounded up from 512. Thinking
> about it more, the table could itself be compressed since typically branch
> numbers don't vary too much and might only need (say) a 4 bit offset from
> the other branch. 
> With a handful more bytes of RAM the compressed table could be interpretted
> on the fly I guess to save gobbling 720 bytes of RAM.
>
> For RLE, again 1 byte, to remember whether you're currently in an expansion
> or not.
>
> Both decode algorithms are left as an exercise for the reader,
> Sprow.

Silly me, &C0..F are taken by the CFS part of ROMFS.  Does anything use
&3BD?

I've put together a script to make ROMFS images and rather lightly
compress them.  Not compatible with Econet (as I can't rely on the
language to leave the 'user' zero page area alone) but fixable with
reassembly + editing. Sorry!

http://homepages.tesco.net/~rainstorm/#prog.comprom

...But I'm sure someone else can do better!

Greg Cook
debounce@...
http://homepages.tesco.net/~rainstorm/




___________________________________________________________
All New Yahoo! Mail – Tired of Vi@...@! come-ons? Let our SpamGuard protect you.
http://uk.docs.yahoo.com/nowyoucan.html