[Techtoolslist] Jedi RAM testing

[John Robertson]

John Robertson wrote:

> Danny Pearson wrote:

>> Hi, I've got a noob question regarding ram testing and using the 

>> 9010.   I'm

>> trying to build a script to do some basic testing on Return of the Jedi

>> using a known working board as a benchmark.  So far I'm just 

>> concentrating

>> on the main CPU, not the sound CPU and I've got the ROM test all 

>> working,

>> now I'm moving on to the RAM.  The schematics for Jedi list a ram 

>> area at

>> 2400-27FF as Scrolling Playfield(high) and this appears to me to only 

>> have 4

>> data bits.   If you run the built in RAM test on the Fluke for this 

>> area it

>> fails, and from what I've managed to glean from the reading I've done 

>> this

>> is as it should be as only 4 bits of data area are returned (a nibble?),

>> whereas I assume the RAM test algorithm uses a whole 8 bits (byte).   

>> I've

>> written the following script to exercise this (and other similar RAM 

>> areas).

>> Can you tell me if I'm on the right lines?   So far I've never done 

>> anything

>> other than the built in 9010 tests so forgive me if this is a stupid

>> question;

>>

>>       REG1 = 2400

>> 1:    !LABEL 1

>>     IF REG1 = 2800 GOTO 3

>>       WRITE @ REG1 = FF

>>       WRITE @ REG1 = AA

>>     READ @ REG1

>>     IF REGE = FA GOTO 2

>>     dpy Failed Response = $1 = $E

>>       aux Failed Response = $1 = $E

>>     GOTO 3

>> 2:    !LABEL 2

>>     aux Success Response = $1 = $E

>>     INC REG1

>>     GOTO 1

>>

>> 3:     !LABEL 3

>>     dpy TEST COMPLETE

>>     aux TEST COMPLETE

>>

>>

>> Cheers,

>>

>> Dan

>>

>>   

> Looks like a good solution to the problems encountered with other 

> 4-bit RAM (2101/5101/etc.) as well. However your test should include 

> (at a minimum) F5 and FA to check that bits aren't locked.

>

> However if you only use FA and F5 then you have no way of finding 

> stuck address nodes.

>

> So it wouldn't hurt to add an offset count  - something like F0, F1, 

> F2, F3, F4, F5, F6, F7...FE, then skip one space and run that again - 

> this is to try and catch data/address rows or columns that are stuck - 

> trying to check that bits in (for example) location 000h are not the 

> same as location 010h which can happen if RAM internal (or external) 

> addressing has problems.

>

> John :-#)#

>


Actually what would work is if you have the data count climb in one 
direction then fall in the other.

Address - Data
000h - F0
001h - F1
002h - F2
...
00Eh - FE
00Fh - FF
010h - FF
011h - FE
012h - FD
...
01Eh - F1
01Fh - F0

I think that would catch stuck address nodes...

John :-#)#

-- 
John's Jukes Ltd. 2343 Main St., Vancouver, BC, Canada V5T 3C9 
Call (604)872-5757 or Fax 872-2010 (Pinballs, Jukes, VideoGames)
                 www.flippers.com 
"Old pinballers never die, they just flip out"