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