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...)
god no...we shouldn't have to worry about defragmenting it, especially if
you're keeping it in-circuit...a fairly easy file system consiting of a
bitmap that says which blocks are used would be efficent, easy to program,
and eliminate the need for such software (would would undoubtedly be very
slow since i doubt this takes advantage of PIO/UDMA
-----Original Message-----
From: ns [despuqué] <worldsnow@hotmail.com>
To: ti-hardware@lists.ticalc.org <ti-hardware@lists.ticalc.org>
Date: Wednesday, November 04, 1998 5:14 PM
Subject: 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: