Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site umd5.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!decvax!genrad!grkermi!panda!talcott!harvard!seismo!umcp-cs!cvl!umd5!zben
From: zben@umd5.UUCP
Newsgroups: net.micro.apple
Subject: Re: Verify bug in IIe???
Message-ID: <566@umd5.UUCP>
Date: Mon, 10-Jun-85 13:45:31 EDT
Article-I.D.: umd5.566
Posted: Mon Jun 10 13:45:31 1985
Date-Received: Sat, 15-Jun-85 07:06:59 EDT
References: <14937@watmath.UUCP>
Reply-To: zben@umd5.UUCP (Ben Cranston)
Distribution: net
Organization: U of Md, CSC, College Park, Md
Lines: 25
Summary: Sounds like hardware

I looked at the routine, is pretty straightforward.  I can't see how you 
could possibly be botching the stores to A1, A2, or A4 to get the behaviour
you describe.  One possibility is that the 6502 is stuck in decimal mode,
but I didn't think that affected the CMP instruction, which the code uses
to do the compare.

The only way I can see that you would get a display with two EQUAL numbers
would be if the two reads from memory, the one in the compare sequence and
the one that picked up the value for display, were getting different data!
This would be a hardware problem.  If it is always at xFCA as you describe
it would sure fit some kind of coupling between address and data lines,
either on the motherboard or in one of your memory chips.

The FIRST thing to do would be to pack up all your stuff onto a disk and go
visit a friend with another ][e and see if the problem happens there too.
If so, it is probably NOT a hardware bug.  If it works fine over there,
though, your ][e is sick and needs to go to the chip doctor...

You could always reseat the memory chips (in fact ALL socketed chips), that
will fix a multitude of weird errors like this.

Good luck

-- 
Ben Cranston  ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben  zben@umd2.ARPA