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


Just think about the way your current hard disk works. It fragments files.
When you want to store a file, it finds the first free block. It starts
storing data in that block until it runs out of free sectors, then it flags
the file as incomplete, and writes into the header where to find the next
file segment. It finds the next free segment, and repeats until the file is
complete (where it puts "final segment" in the header). Each block has a
header on it, and there is a bitmap on the disk that has a 1 if the block is
used, 0 if it's not. That way, it can quickly find a free sector. Since this
is what most modern operating systems used, it's obviously fast, and
overall, it's not that difficult to implement, and requires very little
memory space, the AVR just has to know where to go, and do it seamlessly
when it has to.

-- 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 8:36 PM
Subject: Re: Toll Booth and junk (was Re(fcc): TI-H: Radio/In...)


>
>That may work... for maybe a little bit, but sooner or later there will
>be too many scattered words and it will have to be defragged... so no
>matter what a defrag is necessary. Also, if you transfer your whole CD,
>vinyl, tape collection to a 7 gig HDD, then if you remove
>ABBA_-_some_song and you remove ZZ_TOP_-_some_song, then if you want to
>put a song on that was bigger than both of those, then it would have to
>go partially into abba and partially into zz_top, so I dunno how that
>would effect it, but unless there is RAM, then it is pretty much
>skrewed... any comments? I may be wrong, but it seems logical...
>
>>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 20:21:41 -0500
>>Reply-To: ti-hardware@lists.ticalc.org
>>
>>
>>yes, i am...spaces that are at least a few sectors long of course, we
>don't
>>want to sacrifice too much space efficiency for speed.
>>
>>-- 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 8:20 PM
>>Subject: Re: Toll Booth and junk (was Re(fcc): TI-H: Radio/In...)
>>
>>
>>>
>>>you are talking about splicing the mpeg file to fit it in certain
>>>spaces, korrect?
>>>
>>>>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 20:01:31 -0500
>>>>Reply-To: ti-hardware@lists.ticalc.org
>>>>
>>>>
>>>>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
>>>>>
>>>>
>>>>
>>>
>>>
>>>______________________________________________________
>>>Get Your Private, Free Email at http://www.hotmail.com
>>>
>>
>>
>
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com
>