Path: news1.icaen!news.uiowa.edu!news1.chicago.iagnet.net!qual.net!iagnet.net!newsfeed.internetmci.com!206.229.87.25!news-peer.sprintlink.net!news-backup-west.sprintlink.net!news-in-west.sprintlink.net!news.sprintlink.net!Sprint!151.164.30.38!newsgate.swbell.net!swbell!not-for-mail From: Rubywand Newsgroups: comp.sys.apple2 Subject: ZipGS Split-Cache tests and a Correction Date: Fri, 27 Mar 1998 06:44:31 -0600 Organization: Southwestern Bell Internet Services, Richardson, TX Lines: 59 Message-ID: <351B9F2F.4FF90EF@swbell.net> Reply-To: rubywand@swbell.net NNTP-Posting-Host: ppp-207-193-9-210.hstntx.swbell.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: (null) 891002405 23373 (None) 207.193.9.210 X-Complaints-To: usenet@nnrp3 X-Mailer: Mozilla 4.04 [en] (Win95; I) Xref: news1.icaen comp.sys.apple2:131717 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