Re: ZipGS CDA bug

[Rubywand <rubywand@swbell.net>]

Charlie writes ...
> 
> Hi,
> 
> I was recently looking through the Apple II FAQs that Rubywand posted and I
> realized I might have some information about the ZipGS.
> 
> Its been quite a while since I discovered a potentially disastrous bug in
> the ZipGS CDA V1.2, but here it is:
> 
> On exiting the CDA, a routine is called 
 ....
>   SBC SPEED
>   ASL
>   ASL
>   ASL
>   ASL
>   STAL $00C05D
>   STAL $00C05B
>   BRA :2
>   STA $C05D ;This a mistake!!! It should it be STAL $00C05D.
 ....

> 
> If you trace through the code you will see that there is a short STA
> instruction (no bank byte in operand) where there should be a 
> long STA (bank byte in operand).
> 
> As it stands, if the ZipGS is disabled (speed is 
> zero) when you exit the CDA the routine writes a 
> byte (00) to location $C05D in whatever bank the CDA is
> located instead of bank zero.  This location
> could be inside another program
> (or even the ZipGS CDA) and bad things could happen.
> I patched the routine by putting "NOP" in the offending bytes.
> This at least kept it from doing any harm.
 ....

     Thanks for posting the information and explanation. Although the bug
you've found has already been identified, including an abbreviated form of
your explanation and fix in the FAQs seems like a good idea. There are sure
to be new users who will not know about the bug in some versions of the Zip
CDA and your explanation seems a bit more clear than the one included with
the patch by Greg Templeton.

     Your fix is the same as the one Greg decided upon-- which figures since,
with three bytes to deal with, NOPing out the bad STA looks like the quick,
easy solution.

     As to why the original CDA might want to write to $00/C05D, I don't
know.



Rubywand