                    SYSTEST for Jaguar:
          Functional Description of the Tests
                    
              3-May-94 (Last change to SYSTEST)
              22-Mar-95 (This Document created)


    The SYSTEST Jaguar test cartridge software contains a number 
of hardware diagnostics written about the time when the first 
Jaguar consoles were becoming operational.  Some of the tests 
have proven to be useful for production testing and others have 
become merely historical curiosities.  The purpose of this 
document is to describe the functionality of each test so that 
production engineers can recommend changes, drop obsolete or 
redundant tests and evaluate the need for new tests not 
originally envisioned when SYSTEST was created.

      All production tests (those that are called automatically 
in one of 5 selectable sequences) are numbered from 0-18, 30-32, 
and 40-44.  The gaps in the sequences were to allow additional 
tests to be added later within logical groupings.  The first 
suite (0-29) would be Unattended Motherboard tests, the next 
suite (30-39) would be tests requiring additional hardware 
support from the Test & Diagnostics cart (loop-back connectors, 
ADCs etc.), and the third suite (40-49) would contain tests 
requiring a human operator to pass/nopass them.  Other tests can 
be found in SYSTEST which have no number and are not included in 
the production tests.  These will be identified by their menu 
item description.  All tests were written with the intent to 
minimize reliance on dRAM, so no stack is implimented.

     Now, for the tests:


---Unattended Motherboard Tests---

     0 - dRAM walking one's test
Using the 68000, a longword of 0's is written to $200004 (should 
wrap to $4).  A loop counter of 32 is set and a longword with 
only bit0 set is written to $200000 (should wrap to address 0).  
Then, a longword of 0's is written to $200008 (to "trash the 
bus").  The lower longword is read back and verified, and the 
upper longword (all 0's) is also verified.  The longword with the 
bit set is shifted 1 position left and the loop is repeated til 
all 32 are tried.  Then, the test is repeated except the upper 
longword is used to walk the one's with the lower all 0's, with a 
similiar interleaved write to $20000C to "trash the bus".

     1 - dRAM data test
Using the 68000, 2 longwords (a phrase) are written to dRAM 
repeatedly until a 256k block is filled.  The starting address is 
$200000 and the data pattern is $AAAA5555,$99996666.  Then the 
256k block is read back and verified.  Then the same test is 
repeated, but data pattern used is $5555AAAA,$66669999.
 
     2 - dRAM address test
Using the 68000, 16-bit words are written to fill a 256k byte 
block starting at $200000.  The data pattern used is a sequence 
initialized to $000D and incremented with the constant $0011.  
Then, the block is read back and verified.

     3 - Tom's quick sRAM test
Using the 68000, a pseudo-random sequence of longs is written to 
Tom's sRAM ($F03000-$F03FFF), then read back and verified.  The 
initial datum written is $31785501.  $DA77D4B3 is added at each 
step and the running sum is written incrementally thru sRAM until 
complete.  This test is the same one done at start-up when the 
message "Tom's memory appears OK" is shown (only if all longs 
verify).

     4 - Jerry's quick sRAM test
Using the 68000, the same sequence as described for the Tom's 
quick sRAM test #3 is used for Jerry's sRAM ($F1B000-F1CFFF).

     5 - SoundDies Quikcheck
The 68000 loads a DSP program to test dRAM, and while that is 
running, the 68k scans JOY1 for all possible joystick key 
closures (all are ignored).  The unusual thing about this code is 
that only a very small range of dRAM is tested by the DSP: four 
longwords starting at $1DAAAC.  By trial and error, this address 
space was found to be extremely sensitive to verify errors in 
many machines (especially those exhibiting the celebrated 
Cybermorph "Sound Dies" fault).  My recollection is that the DSP 
code org also had an effect on how likely verify errors would 
occur.  Both the dRAM address range used and the Jerry sRAM 
origin of the DSP code were selected for maximum failure 
potential on machines that I tested.  The DSP code dRAM test does 
a "loadw" from the current dRAM long-aligned pointer, then a 
short delay loop of count 7 is executed, then a "store" of data 
pattern $AAAA5555 to the same dRAM pointer is performed.  After 
all 4 longs are written in this fashion, the data is read back 
and verified.  The data pattern is then complimented and the 
process is repeated 32 times.   The DSP code then executes a self 
shutdown.  When the 68k detects this shutdown, it restarts the 
DSP and the cycle is repeated 4096 times.

     6 - GPU dRAM test ($A..5)
The GPU is loaded with a program that does phrase writes to all 
dRAM and phrase reads to verify.  The dRAM start address is 
$200000 and ends just before $400000.  The two phrases 
alternately written repeatedly are $AAAA55555555AAAA and 
$9999666666669999.  After the first pass, the data is 
complimented and the cycle is repeated.

     7 - GPU dRAM test ($0..F)
This test is the same as the above (test #6) except the two 
phrases used are $0000000000000000 and $FFFFFFFFFFFFFFFF.

     8 - GPU dRAM test (Random)
This test is the same as the above (test #6,#7) except the 1st 
phrase written is $5B4DA486DA77D4B3 and the phrase 
$68F50A10DEF656D5 is repeatedly added to the running sum for each 
following phrase write.  A verify is preformed but no 2nd 
complimented pass is done.

     9 - Blitter Gouroud shading
A phrase-mode Gouroud shaded pattern blit is done to dRAM (at 
$10000) that is 1 line high and 1000 16-bit pixels in width.  The 
68k verifies what was written is correct.  Three blits are 
performed, with 3 differing int/frac values written to b_srcd for 
the 3 blits and 4 different chrominance values written to b_patd 
for each phrase of each blit.  Int/frac values used are 0/$7fff, 
0/$ffff, and 1/$f000.  The verify checks to make sure luminances 
don't wrap to corrupt chrominances.

    10- Tom executes moving module
When run by a production test suite (not an individual menu item 
test), a GPU/DSP compatible program is loaded into the DSP and 
started.  The same program is loaded into the GPU and started.  
When the GPU program finishes, this test is complete (even though 
the DSP is still running).  When test #13 is run by the 
production test suite, it merely waits for the DSP to complete 
the run started at this step.  The GPU/DSP independent, position 
independent program for both GPU/DSP is loaded at the base 
address of the GPU/DSP, and when started, fills all unused on-
chip sRAM with a pseudo-random sequence.  The sequence is read 
back to verify then the cycle is repeated once with the 
compliment of the sequence.  The init value is $31785501 and the 
increment is DA77D4B3.  If no verify error is found, the program 
cleverly moves itself forward in memory by one word and executes 
from its new origin to write/read the pseudo-random sequence 
again.  This is repeated until the program finishes executing out 
of the highest sRAM available (exception: DSP writes/reads all 
its sRAM but only relocates through half its sRAM to save time).
      
     11-Line Buffer RAM
Zero is written to VMODE (to inactivate any ObjProc use of Line 
Buffer Ram), then a pseudo-random sequence of 360 longs is 
written to LBUFA+$8000 and verified at LBUFA.  The same is done 
for LBUFB.  (Data pattern init: $31785501, inc: $DA77D4B3)  
Verify errors are reported, otherwise video is restored and 
"pass" is returned.

     12- Palette RAM
128 longwords of the same pseudo-random sequence (used above in 
test #11) is written and verified at CLUT.

     13- Jerry executes moving module
The results from a test started by test #10 are awaited here.  
Further description is given in test #10.

     14- DSP dRAM test ($A..5)
The 68k loads a DSP program which writes and verifies all dRAM.  
The DSP code does a "loadw" from the current dRAM long-aligned 
pointer, then a short delay loop of count 7 is executed, then a 
"store" of data pattern $AAAA5555 to the same dRAM pointer is 
performed.  After all dRAM longs are written in this fashion, the 
data is read back and verified.  The data pattern is then 
complimented and the process is repeated.

     15- DSP dRAM test ($0..F)
This test is the same as above test #14 but pattern $0000FFFF is 
used instead.

     16- DSP dRAM test (Random)
This test is the same as above test #14 & #15 but instead uses a 
pseudo-random sequence.  Data starts with $5B4DA486, and is 
incremented by $DA77D4B3.

     17- All: Tom, Jerry, 68k, Video
Four processors are run simultaneously to check bus contention 
problems.  This test is probably obsolete since real games do it 
better.  Anyway, the GPU does phrase mode write/reads ala test #7 
except the dRAM range is limited to $90000-$CFFFF.  The DSP 
writes/reads longwords in the dRAM range $D0000-$EFFFF with a 
word read (loadw) preceeding the pattern write (store).  The 
pattern used initially is $FFFF0000.  All dRAM in the range is 
written (with 10 nop's between each write to let others on the 
bus) with the pattern, then all dRAM in the range is verified 
with a loop interlarded with 18 nop's.  The pattern is 
complimented and the process is repeated endlessly.  The 68k does 
a memory check at range $80000-$8FFFF with pattern $0000FFFF.  
The pattern is complimented after each pass.  While all this is 
going on, a display of color bars in 24-bit true-color is keeping 
the object processor busy.  Its image is at $20000 and the 
display list is at $6000.

      18- White dots check (4 secs)
A CRY video display is enabled and a sine-wave tone is played by 
the DSP.  The GPU runs a program that blits 16 tiles of solid 
purple onto the video display memory.  After completion of the 16 
tiles, the GPU reads the bit-map and verifies that it is 
correctly written.  Certain machines when warm will have blit 
errors (especially bit7 stuck high within the word sized pixels), 
and hence show up as white dots.  The test runs repeatedly for 
about 4 seconds and if no verify errors are found, it passes.  
This effect was first noticed in Cybermorph.
  

---Unattended Loopback Tests---

     30- Digital joystick test
With joystick loopback connectors in place, tests every switch 
combination to be scanned by game software and passes if all 
function normally.

     31- Analog joystick
With joystick loopback connectors in place, tests analog joystick 
functionality using Test Cart ADC hardware.  To my  knowlege, 
this test is not valid since the pass/nopass thresholds were 
never calibrated.

      32- Audio FFT test
Four precision sinewave frequencies (200Hz, 1kHz, 5kHz, & 15kHz) 
are sent out the left then right channels and the data is fed 
back in through the I2S for FFT analysis.  The S/S+N ratio is 
checked and must be greater than 58db for all frequencies (except 
15kHz which must be greater than 52db) on both channels.  The 
THD+N is checked and must be greater than 0.2 for all frequencies 
(except 15kHz which must be greater than 0.3) on both channels. 
If these measurements are within the specified thresholds, the 
test passes. 


---Attended Tests---

     40- Color Bars (wait for user)
Eight vertical bars of fully saturated 24-bit true color are 
displayed for visual inspection by the operator.  After a minimum 
of about four seconds, the operator hits a key at the console, or 
presses FireA (if running in a cartridge), or presses J2 
pushbutton (if running on the test Fixture).  This will complete 
the test.

     41- White CRY (wait for user)
A solid white CRY screen is displayed while running the other 
simultaneous tests (as described for item #17).  On some machines 
dark vertical lines would appear.  The simultaneous stuff runs 
for about 5 seconds then just the white screen is left (with 
GPU/DSP idle).  The operator exits in the same way as described 
for item $40.

     42- CRY ColorBand w/1kz tone
Four horizontal bands of primary colors (from left to right, dark 
to light) are displayed, then a 1kHz sinewave tone is played.  
While displayed, a routine is called to convert the original RGB 
image into CRY mode.  This allows the operator to check the CRY 
look-up table ROM in Tom.  If defective, the shading will not be 
smooth.

     43- RGB "Parrots" w/o tone
A JPEG picture of parrots is decompressed on the fly while being 
displayed.  This provides the operator with a reality check of 
the display subsystem by showing a photographic image.

     44- Joystick checker
An image of a Jaguar joypad is displayed.  When any joypad button 
is pressed, the green image corresponding to that button turns 
red.  A button click sound can also be heard.  To exit, hit a key 
on the terminal, or press the # key on the joypad and release.
   

