Many of you know that I have struggled for days to understand very, very odd
problems with my system that seemed to plague only my Focus Drive - the same
applications run from floppy did not produce these seemingly random errors,
failures, and drops to the monitor.

After nearly 72 straight hours of research, I think I have discovered the
cause and solution.

I believe, based on a great deal of observation, that the Focus Drive has
on-board RAM that it utilizes as a local disk cache.  This card-based cache
RAM is only enabled when the FocusDriver is installed, resulting in the
significant speed increase Focus Drive users have seen.

However, if you use the GS/OS Memory Control Panel to specify a disk cache
for the system to use, there appears to be some sort of collision between
this cache and the on-board cache, resulting in corrupted writes (NOT reads)
to the Focus Drive, regardless of filesystem type.  In addition, utilizing a
GS/OS disk cache when running FocusDriver actually seems to result in a
noticable _decrease_ in speed.

It is not clear to me at this time if this problem is only triggered in
conjunction with a Sirius RAM card, or if it affects all Focus Drive users.

My recommendation is to *completely* disable the GS/OS disk cache - my tests
have shown that even the 32K GS/OS default cache can very quickly cause
write corruption.

Again, this ONLY affects Focus Drive users who are using the FocusDriver in
conjunction with *any* sized GS/OS disk cache.  If you are not using
FocusDriver, a GS/OS disk cache is not only safe, but recommended - however,
unless the drive activity indicator really bothers you, you're much more
likely to get better performance from FocusDriver than you are the system
disk cache.

The easiest confirmation of the problem I have discovered to date is to copy
either a) HyperCard GS and the home stack from its program disk or b)
AppleWorks GS from its program disk to any Focus Drive partition (with
FocusDriver loaded and a non-zero GS/OS disk cache), triggering the
corruption state.  To verify corruption, either a) launch AppleWorks, and if
you're lucky enough to actually get to the opening screen, go into the
Spreadsheet function and try entering some numbers in cells - they'll likely
all register as zero shortly before a program crash, or b) launch HyperCard,
which will either 1) crash to the monitor during start, 2) crash when you
cancel the name registration, or 3) hang or crash the system on program exit
from File/Exit.  I've noticed the write corruption seems to occur only in
files that exceed the size of the GS/OS disk cache - very small files are
unaffected.  However, I can regularly corrupt 2MG images copied over
AppleTalk with any size disk cache enabled.

If someone can find fault with, or completely fail to reproduce this problem
on a ROM 03 system equipped with both a FocusDrive and a Sirius RAM card (or
if you *can* reproduce it without the Sirius RAM card), I'd love to hear
about it.  I don't want to unnecessarily frighten people, but my frustration
level has reached enough of a peak to want to get the word out on this as
soon as possible - I'd rather warn you and be wrong than not warn you and be
right.

I do not believe at this time that this problem affects Apple IIe/Focus
Drive owners, since I am unaware of any system "soft cache" utilized in
ProDOS (the operating system, not the filesystem).

Rubywand, since you worked on the updated Focus CDEV, your comments are
especially welcome, since you may have some better familiarity with
specifically how the FocusDriver works (and if there is a mythical physical
RAM cache on the FocusDrive card that it activates).

Thanks for reading,
Rodney