Re: Vulcan GS/OS Driver

["Michael J. Mahon" <mjmahon@aol.com>]

Steven Hirsch wrote:
> Rusty wrote:
>
> > Also, if any of you happen to know exactly what this driver does, I'd
> > be interested to know. My working theory was that it allows the GS/OS
> > to address the Vulcan in a more efficient / faster manner than is
> > possible by whatever generic block device interface the GS uses by
> > default. However, I have also seen an old post on usenet where someone
> > was saying something vague about the Vulcan GS/OS driver having
> > something to do with caching. Any info will be appreciated.
>
>
> At a minimum it probably supports multi-sector transfers on a single IO 
> call. IIRC, the P8 compatible ROM-based drivers were typically 
> sector-at-a-time.

IIRC, the Vulcan drive(s) were all geometrically addressed, rather than
logically, so the driver had to do some divides to convert the block
addresses to CHS.  A 65816 could do that much faster in 16-bit mode
than in 8-bit mode.  This would also be a prime target for consecutive
block optimizations.

I don't recall how the data registers of the card are laid out, but if
they were consecutive addresses, then a 16-bit load could have speeded
the data move loop as well.  In 8-bit mode, the move "loops" were
significantly unrolled for speed.

Being able to allocate system RAM for caching and for the partition
table, instead of using the bank-switched on-card SRAM, would also
have allowed some speedups in 65816 mode.

I wonder if Bob S-C did the GSOS driver as well as the firmware?

> Directory caching is a possibility as well.

Caching of any kind would be a big win--index blocks come to mind.

-michael

NadaNet file server for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."