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...)


no...a bitmap would be quite fast actually, it's what some operating systems
(QNX for example) use for free block checking. I do agree that periodic
defragging is good, but having it so that you can't send over any more mp3s
if you don't have a free block large enough to hold them? that's what i
considder silly. Using a bitmap, you would be able to quickly find the free
space needed to store the mp3, and have a few bytes in the header, as well
as a flag bit saying "file fragment, more stored here", and then on the last
fragment have a "final fragment." It's fast, and wouldn't require very much
codespace to implement. It's certainly fast enough to stream audio this way.
(and far faster than the parallel/serial port, so sending data over wouldn't
be hurt at all)

-- Jon Olson

-----Original Message-----
From: Nick S [despuqué] <worldsnow@hotmail.com>
To: ti-hardware@lists.ticalc.org <ti-hardware@lists.ticalc.org>
Date: Wednesday, November 04, 1998 7:57 PM
Subject: Re: Toll Booth and junk (was Re(fcc): TI-H: Radio/In...)


>
>umm... maybe you could /program/ it to do that, but in the real
>hardware, that is silly (best word I could use without offending your
>mother)... the hdd would be slower than slow, I mean it either a) MUST
>be defragged or b) do what dave said and fit mp3's into deleted mp3
>slots...
>
>>From: "Jon Olson" <morph@jmss.com>
>>To: <ti-hardware@lists.ticalc.org>
>>Subject: Re: Toll Booth and junk (was Re(fcc): TI-H: Radio/In...)
>>Date: Wed, 4 Nov 1998 17:15:55 -0500
>>Reply-To: ti-hardware@lists.ticalc.org
>>
>>
>>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
>>>
>>
>>
>
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com
>