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...)
Oh yea... NT hehe... why are you using that _silly_ OS again? I thought
you pittsssburgh/CMU ppl used some form of unix or another...
>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:05:19 -0500
>Reply-To: ti-hardware@lists.ticalc.org
>
>
>I said as a start, those of us in windows nt need SOME kind of
interface for
>transfering things, and i'm sorry to say, but dos programs or even 95
>programs simply won't work. try running a dos or windoes ti transfer
program
>in nt, you'll get a nice ERROR_ACCESS_DENIED return from the inp's and
>outp's that the program uses. Sure, it's slow, but i've been reading up
on
>port I/O in NT, and it looks like parallel is fairly easy (115200 over
>serial would be about 1/4 of the speed that you could get through
>parallel...maybe less)
>
>-- 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:03 PM
>Subject: 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
>>
>
>
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com