Re: firmware for the PseudoDisk

[bieling@terra.es]

> Alex Freed wrote:
>
> > But in general every time ProDOS asks for
> > a block, the AVR code should traverse the FAT to get the physical
> > address. In fact there is no space for the FAT either so it will
> > have to be re-read from the card. So the bad news is that FAT makes
> > seek operations much slower. The good news is AVR is running at 16 MHz
> > and SD memory is pretty fast.


Could you "borrow" some SD clusters (marked as free in the FAT) for
your own use, yes ?

Hmm. I'm trying to figure it out :

For every disk image, you need to keep

-a pointer (3 bytes ?) to the FAT_SDBlockNumber that holds the part of
the FAT where is the file's first cluster entry.
-a FirstClusterEntryOffset (1 byte ?) to the image's first cluster
entry (2 bytes) within that FAT_SDBlockNumber.

For a (likely) ClusterSize of 4096, a 32Mb ProDOS image will have
32*1024*1024/4096==8192 cluster entries in the FAT... ?

When looking for any given ProDOSBlockNumber, we know that the cluster
that we are looking for has to be read from the FAT ClusterEntryNumber
== (ProDOSBlockNumber*512)/ClusterSize.

As the file may be fragmented, then we *have to* parse (transverse) the
FAT linked list, from the 1st FAT entry at (FAT_SDBlockNumber,
FirstClusterEntryOffset) up until the ClusterEntryNumber in the FAT.
And, as every SDBlock holds 256 cluster entries, it may happen to be
neccesary to read (and parse) up to 8192/256==32 SDBlocks in the
process, if not more in the event of a very fragmented file and/or very
high block number.

Once the ClusterEntryNumber has been read, we finally know the cluster
that holds the data, and with some more simple math we map it to a
certain SDBlock and read it.

Is that, more or less, the way it is ?

If that was correct, then:

You could use the "borrowed" memory for caching the clusters' relevant
data as it is found by the above process. I mean, start with an empty
(filled with zeroes) table, and go filling it up as the need for a
search (by the above, long process) arises. I mean, always check the
table first, then if you find a 0 in the table you need to do the
search, but starting from the last position filled in the table.

There's no need to build a (big) complete translation table: it will
also speed things up quite a lot if you just keep the relevant data of
certain offsets within the file : for example, at offsets 0, 1/4, 2/4,
3/4 of the file size, so that you can start the search from the closer
known offset, instead of from the begginning of the file. This way more
than one table may easily fit in just one "borrowed" SDBlock.

Regards,
Jorge Chamorro.