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


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
Follow-Ups: