ZipGS Split-Cache tests and a Correction

[Rubywand <rubywand@swbell.net>]

First, the correction:

     The FAQs describes a Split-Cache modification for 64kB and 16kB
version 1.02 ZipGS accelerators. The text description is correct; but,
unfortunately, the "helpful" diagram pic (file R005SPLITC.GIF) has
contained an error.

     The J6 and J7 jumbers are shown going from point 1 to point 2; the
J6 and J7 jumbers should each go from point 1 to point 3. A corrected
R005SPLITC.GIF has been uploaded and should soon replace the bad pic. (I
did the pic; so, the error is mine, not the author of the Split-Cache
Mod article.)


Tests

     The error was detected when (last night) I used the pic as a guide
for trying out the Split-Cache mod. Naturally, it did not work. A check
of the text revealed the screw-up, the jumpers were changed, and the GS
started up.

     As explained in the article, the idea behind the mod is to split
the cache between DATA and CODE. Supposedly, this should allow the ZipGS
to avoid replacing program CODE after a bunch of DATA has been cached or
replacing DATA after a lot of CODE is cached. With 64kB, there would be
32kB for each.

     It sounds like a good idea; so, I tried it on my 10MHz 64kB ZipGS.
The first step was to do several 'Before' timings of typical GS
operations. These included scrolling through a window in the Finder,
scrolling through large files under Appleworks (text screen) and
CoolWriter (super-res screen), doing Find and Find-Replace, super-res
picture Fills under Platinum Paint, and super-res pic to GIF
conversions.

     After the Split-Cache mod, the tests were repeated.

     One surprise is that there was very little difference in timings on
any of the tasks. In most cases, the timings were so close as to be
within the usual error one expects when clicking a stopwatch for
repititions of the same task on the same system.

     The other surprise is that what differences there were tended to
favor the unified 64kB cache over the split cache. Evidently, at least
with 64kB of cache, there are very few situations where Data loads
significantly limit Code space or vice-versa.

     My guess is that ZipGS normally does a pretty good job of
allocating cache and, so, splitting the cache mainly has the effect of
operating with half as much cache. Perhaps, with cache decision-making
oriented toward separate Data and Code RAM, the split-cache setup would
perform better.

     Anyway, it was an interesting experiment; but, afterward, I
restored my ZipGS to its unified 64kB cache.          


 
Rubywand