Re: ProDOS Plus revisited

[Rubywand <rubywand@swbell.net>]

Supertimer writes ...
> 
> Ok, so the HFS FST on GS/OS will allow the use of
> gigabyte sized hard drives and larger as single partitions.
> 
> However, there was some talk in trying to update the
> ProDOS FST to use volumes larger than 32MB
> because ProDOS has some advantages, such as
> speed.  But any changes would break ProDOS.
> 
> How about not changing it at all.  How about an INIT
> or Finder extension or something that would create
> a VIRTUAL partition, then take each ProDOS volume
> on a partitioned hard disk and show them as FOLDERS?
> 
> This is not as crazy as it seems.  The drawback to
> having, for example, 40 partition icons on the
> desktop (for those with large hard drives but refuse
> to use the HFS FST) is that it clutters.  But think
> about it...we all have at least 40 folders in the root
> directory of many of our partitions.  So why not
> MAP the partitions as FOLDERS in a VIRTUAL
> volume?
> 
> The main drawback I see is that this will only work
> right with an Apple High Speed SCSI card.  The
> RamFAST is limited to 12 partitions accessable
> at any one time and I would think the limit would
> also apply in the virtual volume.


     Changing the way the Finder represents partitions may help when it
comes to a cluttered display. It is not clear that it will help much
otherwise (even if we mod the RamFAST to handle more partitions).

     The easiest ProDOS mod is, probably, to increase the block size.
For example, if we make it 4096 bytes, max volume size goes to 256MB. At
32kB block size we get to 2GB per volume. Unfortunately, as has already
been pointed out, going to a significantly larger block size requires
making lots of adjustments everywhere else. Besides, after all the
bother, we have a max partition size of, say, 2GB, which is not all that
large; and, we are beginning to waste notable chunks of storage; and, we
still have the goofy restrictions on ProDOS file naming.

     Coming up with a speedier, more reliable HFS is another option.
Users could develop disk, etc. utilities to work with HFS, languages
could be modified, etc. and, in time, we would be living in HFS-ville.
_But_, someone needs to come up with a better HFS.

     A major concern with going to HFS is that it is not the OS everyone
else uses. The 'world' uses some form of MS-DOS. If we are going to go
to the time and bother of migrating to a new disk OS, why not just cut
the nonsense and go to MS-DOS? 

     Perhaps the best solution is to re-write ProDOS. For a start, we
could make block-size and max block count assignable depending upon the
medium-- no change for current diskettes, but much larger for hard disk,
Zip disk, etc.. Max entries per directory could be handled in a similar
fashion. Filetype coding could get another byte and max file name length
and allowable characters would have to change for all media. There would
be a new BASIC.SYSTEM, too.

     Bascially, we would have one 16-bit ProDOS which could handle all
ProDOS stuff on the GS, support BASIC commands and provide plenty of
room for growth as both media and files increase in size.



Rubywand