Conference hydra::amiga_v1

Here is a memory test program that came over the USENET this summer.
It is hardwired to test a one meg expansion, but should be easy to
change.  I have not built the 1 meg memory expansion board that was
mentioned in this series of mailings, so I cannot vouch for the
usability of this memory tester.
    
Hope this helps,
Jim

Newsgroups: net.micro.amiga
Path: decwrl!decvax!bellcore!petrus!scherzo!allegra!princeton!caip!seismo!umcp-cs!cvl!umd5!louie
Subject: Memory/clock expansion for the Amiga (8/9 - memtest.c)
Posted: 11 Jun 86 20:12:14 GMT
Organization: U of Md, CSC, College Park, Md
 
Posted: Wed Jun 11 16:12:14 1986
 
 
main(argc,argv)
    long argc;
    char *argv[];
{
    unsigned short *adr;
    int i,j,k,n;
    adr=0x0400000;
    for(i=0;i<0x010000;i++)
    {
        for(j=0x000000;j<0x080000;j++)
        {
            adr[j]=j+i+j>>12;
        }
        for(j=0x000000;j<0x080000;j++)
        {
           k=adr[j];
           n=(j+i+j>>12)&0x0ffff;
           if((n!=k)&&(argc>1))
         printf("wrote %4x read %4x diff %4x at addr %6x\n",n,k,n^k,&adr[j]);
        }
    }
}
 
 
-- 
Louis A. Mamakos WA3YMH   University of Maryland, Computer Science Center
 Internet: [email protected]
 UUCP: {seismo!umcp-cs, ihnp4!rlgvax}!cvl!umd5!louie

    Thanks, but I don't have a C compiler.

    len.
    

Re .2:

If you have a reading knowledge of C, you could translate the program into
Basic.  Using PEEKs and POKEs (or PEEKLs and POKELs).

Plan on watching a few good TV shows while the Basic program runs, though.

    Hadn't noticed PEEKs and POKEs in AmigaBasic, but I'll look for
    them now.  And I can translate C to Basic, so maybe this will suffice.
    Only need to run it once, and overnight is perfectly acceptable.
    Thanks for the suggestion.
    
    In anticipation, what do I do if my memory checks out OK?
    
    len.
    

    I'm now convinced there's something wrong with my Amiga, and I
    wonder if anybody has any ideas about what it might be.
    
    I wrote a Basic program to do a diffusion limited aggregation
    simulation, based on the article in the latest Scientific American.
    There's a bug in the program that allows particles to "tunnel"
    through existing masses (I just compute the endpoint of each random
    walk step, and check its adjacent pixels for occupancy, rather
    than follow the particle as it moves along the step to see if it
    runs into anything along the way), so the simulation doesn't produce
    the shapes it should, but it produces interesting aggregations anyway.
    I check for occupancy of adjacent cells by using the POINT function.
    On an 8 hour run (which is about how long it takes to random walk
    enough points into adjacency to make a substantial aggregation),
    I get about a dozen spurious hits, i.e., pixels that the POINT function
    should return "background" color for (color 0), but for which it
    instead returns some nonzero value.  The points are onscreen, so
    the value returned "can't" be -1, and besides, the test is made
    for > 0, rather than not equal to zero.  If the POINT function isn't
    returning garbage occasionally (I'm working on a way to check this),
    then some of my IFs must be failing to work correctly.
    
    Any ideas, suggestions, observations, etc.?  Other than "call Commodore
    service"? 
    
    len.