Knut wrote:
"Michael J. Mahon" wrote:
Linards Ticmanis wrote:
Knut Roll-Lund wrote:
Grasping at straws: What if there is an adressing problem that data is
overwritten because of an adress line failure. Would APTEST see
that? Is
there a RAM test that would test the address lines?
I don't think APTEST would see this at all. The RAM test in APTEST is
extremely simple minded: fill all of RAM with Value X, then test if
it's
still there. Repeat for next X. This obviously won't find broken or
flaky address lines.
You could try something simple like this (with no DOS loaded):
10 FOR I = 2500 TO 49000 STEP 2
20 PRINT I;
30 POKE I, 85:POKE I+1, 170
40 NEXT I
50 FOR I = 2500 to 49000 STEP 2
60 PRINT I;
70 POKE I, 170:POKE I+1, 85
80 NEXT I
Then see if and at what value of I you get screen corruption.
Or you could take two passes, and store the high/low byte of
the address at each address, then read back and verify.
If any address line is open, stuck, or shorted to another, the
values read back will not match.
Hi, thanks for the answers.
I have designed simple RAM tests through my work (embedded stuff). I
would typically test address lines by using powers of two for each RAM
area (in assembly using registers so the RAM is free) writing and
reading back to see if they would affect each other.
I'm still learning about the Apple2 and especially I don't yet know
where it is allowed to POKE. I could probably interpolate on your
program and use the area 2500 to 49000 to test all the address lines,
test separately within each bank of RAM.
BTW I did have a flaky RAM, at first, but identified it and
fortunately I have some compatible spares. It sometimes got through
the APTEST and sometimes not. I have been moving the RAM chips around
so I'm pretty sure they work now (tested them all in the first bank).
The faulty RAM was originally in the middle bank so DOS3.3 would boot
fine even with it failing.
After changing that RAM the fault that is left is there all the time.
Beautiful boot has never worked nor Wizardry or any other big games I
have tried. Some smaller games work. There was something strange with
the graphics on one lunar lander I tried but the game seemed to work
(the hillsides were corrupted) I have no joystick or paddles for II+
yet so I couldn't test more there.
I have tried beautiful boot in several emulators in II+ mode but this
is not a good test as emulators tend to have lots of extra "hardware".
Should beautiful boot work on my plain II+ 48k machine with only a
DiskII card? Beautiful boot is very typical on floppy images I find on
the net and it seems to use HGR.
I'll try some basic when I get home from work.
ok this one revealed how worthless a test APTEST's ramtest is. I did the
test in 3 batches one for each bank of ram. This is for the second one
and I didn't bother with powers of two.
10 POKE 16384,0
20 FOR I=16385 TO 32767
30 POKE I,255
40 IF PEEK(16384) <> 0 THEN PRINT "FAIL", I;:INPUT A$:POKE 16384,0
50 NEXT I
This one failed immediately with 16385 but closer inspection by peeking
and poking from the command line revealed that none of the addresses in
the middle bank holds any value. That is addresses from 16384 to 32767
won't hold a value. I have checked all the signals and they seems ok, I
do get both RAS and CAS (CAS when I PEEK or POKE). I really wonder how
it is. The RAM seems ok. Can something be clobbering the bus when I
access the D bank of RAM. The data latches are the same as the other
banks so it can't be those...
I think this is the fastest way basic can do POKE and PEEK and C is
never 0 (32786 or 16383 works fine even with me typing the POKE and PEEK
separately on the command line). Poking 255 also fails.
10 A=32767:B=0:POKE A,B:C=PEEK(A):PRINT C
APTEST still reports all ok
I probably have to break out the logic analyzer, and follow the data
from the RAM to the CPU during POKE and PEEK.