Re: Jedi RAM testing

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@flippers.com
> [mailto:techtoolslist-bounces@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"
_______________________________________________
Techtoolslist mailing list
Techtoolslist@flippers.com
http://seven.pairlist.net/mailman/listinfo/techtoolslist
FTP site is: ftp://ftp.flippers.com/TTL/TestEquipment
Archive site: http://seven.pairlist.net/pipermail/techtoolslist/