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