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.