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...)
are you sure you are programming toll booths? Thats the SILLIEST (again,
easiest word) thing I've ever heard... do you know how LONG it will take
to do it thru a serial port? People are going to have 7 gig HDD's and
_I_ sure as hell don't want to transfer 7 gigs thru a damn serial
port...
>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 18:18:03 -0500
>Reply-To: ti-hardware@lists.ticalc.org
>
>
>I meant eliminate the need for constant defragmenting for those of us
who
>have large, ever changing mp3 playlists, and no, i didn't read your
post
>because you haden't sent it when i replied :>
>
>(or it haden't gotten from your mail server to the list server, because
i
>get my messages back in <1 minute). anyway, I think we've agreed on
what a
>good way of doing things, now we just need grant to get on-line and
code it
>:>
>
>Also, I've starded work on a nice Windows based program that will talk
via a
>serial port to his device. I haven't checked to see if he's released
the
>protocol to communicate with the player yet, but I'm building a base
shell.
>Because i'm in windows NT, serial i/o is a lot easier tha parallel i/o
(have
>to make ~30 i/o calls to write to the parallel port directly so i've
>heard...think i read that on a page for some TI-85 linking software.
I'll
>look into it more once i start coding the actual implementation.
>
>-- Jon Olson
>
>-----Original Message-----
>From: David Knaack <dknaack@hotmail.com>
>To: ti-hardware@lists.ticalc.org <ti-hardware@lists.ticalc.org>
>Date: Wednesday, November 04, 1998 5:49 PM
>Subject: Re: Toll Booth and junk (was Re(fcc): TI-H: Radio/In...)
>
>
>>
>>>From: "Jon Olson" <morph@jmss.com>
>>>god no...we shouldn't have to worry about defragmenting it
>>
>>LOL
>>
>>Really guys, free space defragmentation is VERY simple!
>>Its just scooting the blocks of data to the lowest free
>>address. There would be a little bit of preliminary
>>shuffling of the allocation table (to move all unused
>>allocation blocks to the end of the table), but thats
>>simple too.
>>
>>>especially if you're keeping it in-circuit...
>>
>>Thats what I would recommend, let the AVR do handle
>>it, unless it gets cramped for program space. In that
>>case just an interface to get the player to dump the
>>allocation table and some commands to tell it to move
>>data around on the disk and write certain bytes would
>>allow a computer program to remotely defragment the drive.
>>
>>>a fairly easy file system consiting of a
>>>bitmap that says which blocks are used would
>>>be efficent, easy to program,
>>
>>Did you read my post? Thats basicly what I said,
>>an allocation table of ~200 byte blocks, each
>>containing song data, start and end blocks, and
>>maybe a data type flag (MP3 or User).
>>
>>>and eliminate
>>>the need for such software (would would undoubtedly be very
>>>slow since i doubt this takes advantage of PIO/UDMA
>>
>>The only way you can eliminate the need for the
>>software is by eliminating the ablity to delete
>>songs. It would really suck to have to clear the
>>drive and redownload everything anytime you started
>>to run out of space.
>>
>>DK
>>
>>______________________________________________________
>>Get Your Private, Free Email at http://www.hotmail.com
>>
>
>
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Follow-Ups: