Date   : Fri, 06 Oct 2006 21:32:02
From   : Sprow <info@...>
Subject: Re: Compressed ROMFS?

In article <20061006014529.82501.qmail@...>,
   Greg Cook <debounce@...> wrote:
> 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

[workspace]

> 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!

As the ROM filing system is read only, locations &380-&39D should be free
since they're reserved for the BPUT header block. I think your suggested
&3BD will be in use as it's in the "last read block" area.

Nice job on the ROM though. One later thought I had was how to handle
seeking in the ROM, but I guess you just restart the compression algorithm
for each new file,
Sprow.