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 -----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/ -- I am using the free version of SPAMfighter. We are a community of 6 million users fighting spam. SPAMfighter has removed 26930 of my spam emails to date. Get the free SPAMfighter here: http://www.spamfighter.com/len The Professional version does not have this message