[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Zip GS questions



In article Barry.Rees@prodigy.net writes...

>No, I hadn't tried that. Actually, my initial testing was at 16/64. That
>setup was almost unusable. However, I did cut the cache back to 32k and
>that proved to be 99% stable. But as I mentioned, I was still getting
>random crashes.

    Interesting, I have a 15/64 and what you describe is _exactly_ what
happened in my situtation. When configured to run with 64K of cache, I
experience lock-ups (the mouse cursor still moves but background frozen)
within several minutes after turning on the power. If I disabled half of
my cache, so the board was running as a 15/32, things ran fairly stable,
but I would still on occasion experience random freezes, lock-ups and
crashes. I even tried it at 12.5 MHz (12/64) and the same problem would
persist (I didn't test 8/64 since it made my IIgs feel rather sluggish ;)

    In later months, after going through everything from a Buggie power-
supply to removing and replacing cards, I just gave up. I decided the 
SRAM chips were faulty, or my Apple IIgs or ZipGS board were the cause.
Two weeks ago, however, I found the cause and a solution! The ASIC chip
on the ZipGS was overheating, and so by placing a Pentium heat sink with
attached mini-fan (powered by the motherboard "Fan" connector) over it
had fixed things. I'm running configured as 15/64 now, no problems. As 
well, the random crashes and lock-ups I had experienced with 32K cache 
have cleared up for the most part (sometimes I get $0201 memory errors 
when I launch ProTERM from the Finder, but I think that could be a 
software bug rather than the Zip).

>When I get back to testing, I'll keep in mind the 16k cache that you
>suggested. I'd like to get the 16 MHz setup working because it was
>INCREDIBLY fast. Question: With the (32k x 8) chips installed, can I
>still configure the DIP switches to only use 16k of the 64k installed
>cache?

    From my experience, no. You can only tell the Zip to ignore the
second set of chips (64K/32K or 16K/8K). I may be wrong, but this 
would seem logical and from my own testing, the Zip becomes totally
unusable because it's expecting a different density chip. It's not
a matter of stability, it just won't work period.

Mitchell Spector
spec@vax2.concordia.ca