hardware@watmath.UUCP (MFCF Hardware Lab) (06/08/85)
I have written a program in basic, with machine language routines poked in, to
check all the differences on a dos 3.3 disk. I did this to try to save an
adventure character, noting the changes before and after death. I initial
used peek(x) and peek(x+4096) to compare two tracks, but this was slow (1
for 34 tracks). I then checked my IIe reference books, and found the monitor
Verify routine at $FE36. From the instructions, it only prints anything wh
it finds a difference, but when I run my program, no matter where the buffer for
the information is (within both hi-res pages) I get the output:
XFCA: GG (GG)
where X is the page number and GG is a hex digit. This is in the
correct format, but since they are equal, they should not be displayed! The
actual value of GG varies, and I think that it is the read in value, But
still shouldn't be printed! Any ideas as to what is wrong, or what I'm doing
wrong\??
Thanks, Andrew Rahme
hardware@watmathzben@umd5.UUCP (06/10/85)
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