03.012 Is there some ZipGSx mod that will improve performance without going to a faster crystal, etc.?
Description
This article is from the Apple II Csa2 FAQ, by Jeff Hurlburt with numerous contributions by others.
03.012 Is there some ZipGSx mod that will improve performance without going to a faster crystal, etc.?
There is; you can do the ZipGSx Split Cache Mod. As your manual explains,
Zip GSX speed comes from having a faster processor which can access code and
data from its high-speed cache RAM. The standard 'GSX has a unified cache,
which means data and code have the possibility of overlapping. If the cache
controller sees a need to bring in a lot of code, it will go to main memory and
bring in up to 64k of code (or 16k in a 16k cache system) and, possibly,
overwrite useful data.
The reverse is also true. If the controller feels that a lot of data needs
to be brought in, it will cache the data, and, possibly, overwrite useful code,
causing another slowdown when the code needs to be fetched again.
With a split cache, the code and data segments no longer overlap. Caching
code cannot overwrite data, caching data cannot overwrite code. The drawback is
that only 32k of data and 32k of code can be cached at once (in a 64k system),
but usually this provides for more speed than being able to cache a 64k mix of
both.
To do the mod, you'll need a ZipGSX version 1.02 with either 16k or 64k
cache on it. If you're not sure exactly what board you have, it's pretty
straightforward to figure things out: open the computer and look at the Zip.
The board revision is silkscreened on just beneath the processor.
The cache size can be determined from the DIP switch settings. However, a
simpler guideline is look at the TAG/DATA sockets and count the number of
chips. If there are only 2 chips, you have either an 8k or a 32k cache. If
there are 4, then you should have 16k or 64k.
To modify your Zip for the Split Cache, you'll need a good hobby knife
that can cut the traces without damaging the board underneath too badly, as
well as two or three small lengths of wire. You will also need a good pencil-
style soldering iron, desoldering pump or braid, and high quality rosin core
(NOT acid core) solder. I use Radio Shack's .032 60/40 rosin core solder.
Kester makes excellent quality solder which is sold at many electronics supply
shops.
There is a potential of damaging expensive and delicate hardware. For
example, when cutting a circuit trace be careful not to cut deeply, lest you
cut a trace in the next layer of the circuit board. If you're not experienced
with cutting traces or soldering on circuit boards, find an old board and take
some time to practice.
The actual mod is very simple. Steps 1-3 and 5 are for all boards. Step 4
is for 16k cache boards only. (Note: The picture in FAQs resource file
R005SPLITC may be helpful for doing these mods.)
1. Locate J6 and J7. They are both blocks of 3 pinholes, which may or may not
have been soldered-in, near the bottom of the board next to connector J1, where
the gray cable attaches.
2. Cut the SMALL trace between pins 2 and 3 of both J6 and J7. This trace is on
the back (solder side) of the board.
3. Solder in a piece of wire between pins 1 and 3, of both J6 and J7. A wire
that has been bent into a U shape before soldering seems to work best, both for
ease of installation and aesthetic value.
4. 16k systems ONLY: (See the "16k" insert on the picture in FAQs resource file
R005SPLITC.) Cut the trace between pins 1 and 2 of J8 on the top side of the
board. (J8 is below the Cache SRAM sockets) Then, solder a piece of wire
between pins 2 and 3 of J8.
5. Set the DIP switches appropriately. The DIP switches needing to be set are
SW1-7 and SW1-8, they control the cache size. SW1-7 should be OFF for 64k, ON
for 16k. SW1-8 should be ON.
Reversing these changes is fairly easy. If you decide that the performance
change was detrimental, simply desolder the wires that you installed, and
solder in wires to replace the traces that were cut.
I found that the split cache sped up my system notably, especially under
the Finder and other desktop applications. Improvement was much less noticeable
under text applications. (I haven't checked affect on compiling speed, yet.)
----------------------------
By: Rubywand
I tried the split-cache mod on my 10MHz/64kB ZipGSx. Before/after timings
were done for several tasks including Scrolls through Finder windows, Scrolls
and Find/Replace through Coolwriter (super-res) and Appleworks (plain text)
documents, and Platinum Paint fills.
Timing differences were very small-- usually within the error normally
experienced when clicking a stopwatch for repetitions of identical events.
Where a difference was observable, it favored the unified 64kB cache.
Evidently, at least on a 64kB board, the ZipGS does a fairly good job of
managing the unified cache. Possibly, the mod comes out ahead in some tasks not
sampled; or, it may work better on 16kB boards.
By: Richard Der
Continue to:
My Books
