Re: Toll Booth and junk (was Re(fcc): TI-H: Radio/In...)
[Prev][Next][Index][Thread]
Re: Toll Booth and junk (was Re(fcc): TI-H: Radio/In...)
>To: ti-hardware@lists.ticalc.org
>>Allocation table scanning as I outlined should be
>>easy to perform, and would keep down the requirement
>>for free space defragmentation. It also allows for
>>song deletion without taking a big hit in storage
>>space.
>
>Makes it SSSLLLOOOWWW though since the AVR doesn't have swap space for
the
>current sector. :)
I don't know what you mean. I was refering to the AVR just
scanning through the data in the allocation table checking
to find a free slot big enough to store a song in.
This would consist of a seek, read one byte, check the byte,
if it is a 'free slot' byte, seek again, read 8 bytes (two
4 byte values), subtract them, then check that length (the
amount of free space at that location) against the length
of the song to be stored. If the slot is big enough, seek
back to the beginning of the slot, write the header, then
seek to the data area and start writing the data. No big
deal.
>>As I mentioned, defragmentation could be as simple
>>(and time consuming) as a backup and restore, or
>>it could be done periodicly, when fragmented free
>>space reaches a certain percentage (which the player
>>could calculate at the users request, along with
>>largest contigious block and percentage of total
>>space used).
>
>Not possible from the player. It would cost too much if I added
external DRAM.
What isn't possable, moving data around on the HD?
We aren't talking about reading 4MB into memory and
writing it back out again, just reading a sector (or
some part of it), and writing it back out in a new
location, over and over.
How much memory does the AVR have without adding
external DRAM?
DK
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Follow-Ups: