Re: "Star Wars" demo?

[dempson@atlantis.actrix.gen.nz (David Empson)]

In article <31B2EC57.167EB0E7@sci.kun.nl>,
Doede Boomsma  <dboomsma@sci.kun.nl> wrote:
> 
> I know about the 512 bytes block size, but I just HOPED there was a patch
> so that larger blocks would be allowed... :)

The main place where this would cause massive problems is in the
handling of the open file buffers.  Each open file reqires a 1K
buffer, allocated by the application on a 256-byte boundary
(BASIC.SYSTEM handles this for BASIC programs, but programs which call
the MLI directly have to do this themselves). 

This buffer is used by ProDOS to hold one index block and one data
block from the file.  The contents are never touched directly by the
application.

If the block size was increased, these buffers would have to get
bigger, breaking all current applications.

The only possible solution here would be to have some extra buffers
somewhere else, which are completely managed by ProDOS. 

At the very least, this would require that ProDOS makes use of the
SmartPort firmware to access large volumes, requesting multiple
blocks for each transfer.  (ProDOS block drivers are limited to
32MB volumes with 512 byte blocks.)

On an 8-bit Apple II, the SmartPort firmware is only able to access
the main 64K RAM, or other memory which has been bank-switched into
this area.  It would therefore be possible for ProDOS to make use of
auxiliary memory to provide additional buffering.  This would kill all
programs that require 128K of RAM, and would eliminate the /RAM volume.

Another solution might be to use a multi-bank auxiliary RAM card, but
there are no standards for sub-allocating banks within the card to
different software.  ProDOS would have to reserve one 64K bank for use
as buffering memory.

A "slinky" slot-based RAM card would not be an option, because the
memory is not directly addressable in large blocks.

(I haven't addressed the issue of where to put the extra code that
would be needed to manage all this.)


On the IIgs, it is possible to use "extended" SmartPort calls to
directly access the full 16MB address space, so it would be possible,
in theory, to allow access to larger volumes on a IIgs.  One catch is
that the SmartPort firmware for the device must support extended
calls.  This is true for the IIgs built-in SmartPort firmware, the
SuperDrive card, and the Apple SCSI cards.  I don't know about the
RamFast or the various IDE cards.

In any case, you would end up with a IIgs-specific version of
ProDOS-8.  It would make more sense to restrict this extension to
GS/OS, implementing a new FST.

Whether or not this was done, you would end up with a IIgs-specific
file system that could not be accessed by an 8-bit Apple II, a
Macintosh, or any other machine, unless someone wrote import/export
applications for each platform.

It would be a better idea, in my opinion, to improve the HFS FST on
the IIgs.  It works at present, but is horribly slow (especially when
copying large files to floppy).

Alternatively, implement a new FST for the IIgs which supports an
existing file system for another platform, such as HPFS, NTFS or a
Unix-based system.

Any development work on FSTs requires documentation on how to write
them, which does not exist outside Apple.  (Brutal Deluxe claimed they
had disassembled enough of the various FSTs to document the interface,
but they haven't released any such documentation.  I would very much
like to see any such documentation, from any source!)
-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand