Knut Roll-Lund wrote:
Knut wrote: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."Michael J. Mahon" wrote:Linards Ticmanis wrote:Knut Roll-Lund wrote:Grasping at straws: What if there is an adressing problem that data isoverwritten because of an adress line failure. Would APTEST see that? Isthere a RAM test that would test the address lines?I don't think APTEST would see this at all. The RAM test in APTEST isextremely simple minded: fill all of RAM with Value X, then test if it'sstill 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.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 IThis 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'd be inclined to suspect the decoder chip, or something holding the bank select line one way or the other.
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 okI probably have to break out the logic analyzer, and follow the data from the RAM to the CPU during POKE and PEEK.
A short assembly language loop will run over a hundred times faster. -michael NadaNet file server for Apple II computers! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it's seriously underused."