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...)
oh of course it needs a file system, I just meant not like HPFS or
FAT... although I think it will be a write once type of thing, or
"concatonate" files on the end... if it gets big enough then there will
definately be relocation software, that is "defrag" sofware.
>From: "David Knaack" <dknaack@hotmail.com>
>To: ti-hardware@lists.ticalc.org
>Subject: Re: Toll Booth and junk (was Re(fcc): TI-H: Radio/In...)
>Date: Wed, 04 Nov 1998 13:47:49 PST
>Reply-To: ti-hardware@lists.ticalc.org
>
>
>>From: "ns [despuqué]" <worldsnow@hotmail.com>
>>It isn't necessary to have a file system, unless you want to remove
the
>>HDD from the mp3 player and mount it directly to a computer...
>
>Depends on what you mean by file system. By file system
>I mean an organizational system by which the player can
>keep track of its MP3 data. I believe that this falls
>under the definition of a "file system" albet a simple one.
>
>I'd set up about the first 50k-100k of the disk as an
>allocation table, containing up to 500 blocks of about
>200 bytes to describe the song info and data start and
>end positions on the disk. This would give you up to
>about 500 songs on the player.
>
>Fragmentation wouldn't be a big deal for most people,
>as I wouldn't expect too much shuffling of songs, but
>the player should try to fit songs into any gaps in the
>system, to keep free space fragmentation to a minimum.
>Deleting a song would be as simple as marking the first
>character in its allocation block with a special character.
>When new songs are to be added the MP3 player would
>simply scan the allocation table for a free block, when
>it found one it would check to see if it had been
>previously used (start and end pointers not null), and
>if so, verify that the space is long enough. If so it
>would use that block, if not it would continue scanning.
>
>With lots of adding and deleting it would eventually be
>necessary to defragment the free space, but that could
>be as simple as writing the entire data structure to the
>computer, formatting the allocation table and writing
>the data back. Might take a while with a gig of data.
>Alternately someone could write a free space defragmenter
>for it (pretty easy, just scan the allocation table for
>gaps between the end pointer of a song and the start of
>the next song, if found, copy the data backwards into
>the gap and reset the start/end pointers, then go to
>the next song.
>
>DK
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com
>
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Follow-Ups: