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


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