Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!mips!apple!mattd
From: mattd@Apple.COM (Matt Deatherage)
Newsgroups: comp.sys.apple2
Subject: Re: //c GIF problems
Message-ID: <52438@apple.Apple.COM>
Date: 4 May 91 02:12:31 GMT
References: <1991May3.195637.9581@umiami.ir.miami.edu>
Organization: Apple Computer Inc., Cupertino, CA
Lines: 30

In article <1991May3.195637.9581@umiami.ir.miami.edu> jdeitch@umiami.ir.miami.edu (Jonathan Deitch) writes:
>Ok, I've got a tricky hardware problem that I just can't figure out :
>
>My //c works perfectly fine.  It passes Apple's Apple II Diagnostics v3.0
>without error, even when I set it to loop and let it run for a few hours.
>
>When I run IIGIF v1.0, and start to unpack a GIF picture, it gets a few lines
>into the picture and then the screen clears and "MMU" appears in the middle
>of the screen. [...]

IIGIF does a bad thing.  It hits a $C02x softswitch that does something useful
on a IIgs, but it does this on a IIc and IIe as well.  This doesn't cause
any problems on a IIe (unless you have a cassette player hooked up), but on
the later IIc computers those addresses switch ROM banks, and the second
ROM bank (totally undocumented) should never be switched in when a ROM call
(or a $Cn00 call) is made.

IIGIF doesn't know this, so after it switches the ROM banks it happily jumps
into the middle of the built-in diagnostics when it thinks it's accessing
a Monitor ROM routine.  Ah, well.

If you can find the offending $C02x access in the program you might be able
to take it out.  Otherwise you'll have to get the author to fix his program.

-- 
============================================================================
Matt Deatherage, Developer Technical  | The opinions expressed herein are
Support, Apple Computer, Inc.         | not those of Apple Computer, and
Personal mail only, please.  Thanks.  | shame on you for thinking otherwise.
============================================================================