[Techtoolslist] Jedi RAM testing

[John Robertson]

Danny Pearson wrote:

> Hi all, I finally managed to find an hour or two to do some more on this

> based on the good suggestions I got and I think it's pretty complete, either

> way with a new baby about to arrive I think it's all I can do on this for

> now.   I've uploaded the script (Jedi.9lc) to the /incoming directory on the

> FTP server.   I'd appreciate if someone could give it a once over (a test

> would be great) and check that I've got the right IC's for each designated

> test.  

>

> Thanks to James at QuarterArcade for the great script generator that

> provided most of the structure for this script.

>

> Cheers,

>

> Dan

>   


I have put this file (Jedi.9lc) in the Fluke directory on TTL.

Thanks Dan!

John :-#)#

> -----Original Message-----

> From: techtoolslist-bounces at flippers.com

> [mailto:techtoolslist-bounces at flippers.com] On Behalf Of John Robertson

> Sent: 03 December 2009 18:06

> To: Technical Tools Mail List

> Subject: Re: [Techtoolslist] Jedi RAM testing

>

> 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"