This article is from the Apple II Csa2 FAQ, by Jeff Hurlburt with numerous contributions by others.
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