Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!uflorida!gatech!gitpyr!dsking
From: dsking@pyr.gatech.EDU ( David King)
Newsgroups: comp.sys.amiga
Subject: Re: problems with using 1.3 FFS with Pacific Peripherals Overdrive
Summary: My solution hampers FFS
Message-ID: <6679@pyr.gatech.EDU>
Date: 30 Oct 88 23:56:59 GMT
References: <41342@linus.UUCP> <3823@ece-csc.UUCP>
Reply-To: dsking@pyr.UUCP ( David King)
Followup-To: comp.sys.amiga
Organization: Georgia Institute of Technology
Lines: 32

In article <3823@ece-csc.UUCP> rss@ece-csc.UUCP (ML) writes:
...
>/* Pacific Peripherals OverDrive Drive definition for ST157N drive */
...
>	MaxTransfer = 1
...
>	Mask = 0x7FFFF
>#
>The "Mask" and "MaxTransfer" fields seem to be the important thing (I'm not
>sure about BufMemTypye either).
>
>Obviously, I haven't put any SFS partition on my drive; I have no need to since
>I don't have the 1.3 ROMS so I can autoboot (do I all need new roms on the
>Paciphic Periph. Overdrive controller to autoboot?)

	Ok, I had this problem a week ago before Pacific Peripherials had their
1.3 Enhancer release so I came up with my own solution.  Jdow (thanks) suggested
a solution which worked.  I added a line MaxTransfer=512 to my mountlist.   By
specifying MaxTransfer=1 you are transfering a maximum of 1 byte 
per transfer.  I tried using a slightly higher vue but it didn't work.
Apparently the overdrive.device has problems with grabbing more than a block at
a time for FFS.  The problem with this is that the only speed advantage that
I get from FFS is in the directory structure (in fact, raw transfer rate is 
slower).  I have not played with the Mask value.  Where did you get that Mask 
value?  
	The present Overdrive can not autoboot presently.  A daughterboard is
needed to autoboot (atleast for mine - purchased in March '88).  

				Good luck,
				- David
---
- David King
  dsking@pyr.gatech.edu