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




On the AVR you have to do some pretty strange tricks to access IDE hard
drives just right.  :)  So, either you make a completely easy fat and have
it work (compatibility with old and new drives) of you receive the data
from the HD as you needed it (mostly western digital and old stuff).

I guess the fs you made and the one I made are very similar.

Grant


>you're missing my point here (a) it's not multi-tasked and (b) it's not a
>FAT16 system, it's exactly the same as the file system i wrote into that
>Hard Disk driver...on the Z80...so it's easy to do. It the same as the
>free-space fragmentation, except it supports chained files...yes, it does
>mean a little more code, but not excessive, and it doesn't mean doing
>something special to handle it either...just have to change the "Next sector
>to fetch" addr when you finish reading a block.
>
>-- Jon Olson
>
>-----Original Message-----
>From: Grant Stockly <gussie@alaska.net>
>To: ti-hardware@lists.ticalc.org <ti-hardware@lists.ticalc.org>
>Date: Friday, November 06, 1998 1:51 AM
>Subject: Re: Toll Booth and junk (was Re(fcc): TI-H: Radio/In...)
>
>
>>
>>>What does everyone seem to think that my filesystem spec is difficult,
>slow,
>>>or both? It's not all that hard to implement, you just step through the
>>>bytes in the bitmap, until you find one that's not 0xff, and then see if
>>x
>>>blocks are free (1 sector chaining would be too slow, we cal all agree on
>>>that). But please, it's really not that hard to do, it requires a few
>extra
>>>bytes in the file header, and an extra flag bit (maybe, you might even
>just
>>>say "if the NextSegment head/cyl/track isn't 0, then assume there's more
>to
>>>this file somewhere else") Overall, if it's fast enough for PC's to access
>>>multi-gig data files hundreds of times a day, i think it's fast enough to
>go
>>>through a 5 meg file at 30K/sec, and as i keep vehemently declaring, it's
>>>NOT hard to implement.
>>
>>Sure, but the AVR is VERY hard to make multitasked programs on. You'd have
>>to have the HD running while the player was sending the data to the MAS to
>>have a full blown FAT16 or any other fat system.
>>
>>The reason I made my own fat was because it worked at the speed needed, and
>>was efficient...
>>
>>Grant
>>


References: