[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unidisk 3.5 won't write sometimes
- Subject: Re: Unidisk 3.5 won't write sometimes
- From: mjmahon@aol.com (Michael J. Mahon)
- Date: 30 Aug 2004 17:27:12 GMT
- Newsgroups: comp.sys.apple2
- Organization: AOL http://www.aol.com
- References: <iLEYc.13396$D7.8021@news-server.bigpond.net.au>
- Xref: g2news1.google.com comp.sys.apple2:3755
Peter Watson wrote:
>"David Wilson" <david@uow.edu.au> wrote in message
>news:41325d32$1@news.uow.edu.au...
>> >>Jeff Blakeney wrote:
>> >>>ProDOS disks, for some reason I've never quite figured out a
>> >>>satifactory answer for, have a fixed root directory size of 4 blocks.
>>
>> Don't forget that the ProDOS disk format is actually SOS format. So most
>> limitations can be traced back to SOS (this still does not explain why
>> 4 blocks [apart from the observation that having a directory occupying
>only
>> blocks 2..5 allows the bitmap to fit on track zero - so would 2..6]).
>>
>> Does anyone have any SOS documentation that might provide an insight to
>this
>> design decision?
>
>I don't have any documentation, but I do have a few comments.
>
>It's easy to forget in these days of multi-GB hard drives just what was
>available at the time. ProDOS (and presumably SOS before it) were designed
>at a time when a floppy disk held 140KB. Using up 2KB for the root directory
>probably seemed plenty - you would have to work at getting 51 files onto a
>5.25" floppy. And if you did fill it, there were always sub-directories.
>
>Also, (in theory anyway) there was nothing stopping the root directory size
>being increased. Well, nothing apart from developers making unjustified
>assumptions about where the Volume Bit Map started!
>
>Lastly, it's worth pointing out that MS-DOS also had a fixed, fairly small
>root directory size.
>
>On a different note, there's a good reason to avoid putting anything other
>than subdirectories in the root directory of a ProDOS disk. If the root
>directory is damaged, file recovery is *much* easier if the files are in a
>sub-directory!
I agree with all of your points, but perhaps the original design question
still stands: why did the ProDOS (and SOS before them) designers opt
for a (nearly) fixed root directory size, rather than using the link fields to
allow a fully variable size?
I still lean toward the issue of boot code complexity as decisive, since
ProDOS and SOS both implement a rudimentary read-only boot file
system in 512 bytes and look up the OS boot file in the root directory.
Frankly, once the boot code has the ability to seek arbitrarily, there
is not much to be gained by restricting root directory size. Perhaps
the design was done incrementally, and this decision was made prior
to implementing the ability to seek to any track.
-michael
Check out parallel computing for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/