SAMS card troubles

[+Vorticon]

16 minutes ago, arcadeshopper said:

you could also try matt's tester here: https://github.com/jedimatt42/ti994a-32kmemtest it does sams and tests more extensively than the amstest4 does

 

 

Do you happen to have a built cart image by any chance?

[+arcadeshopper]

16 minutes ago, Vorticon said:

Do you happen to have a built cart image by any chance?

https://github.com/jedimatt42/ti994a-32kmemtest/releases

 

[+Ksarul]

The 612 and the 688 are the two chips that have caused the most problems with the 100 or so boards I've built. BTW, you can use a 25LS2521 in place of the 74LS688, as it is an equivalent replacement (and in my experience, more stable).

[+TheBF]

1 hour ago, Vorticon said:

Great program! You've got to love Forth!

I am seeing some inconsistencies however:

• AMSR4 reports only 512K of RAM (after I reflowed the solder joints, the RAM size went from 1024 to 512 irrespective of the position of the SRAM chips), but SAMSTESTER seems to see all of the memory. The REGTEST passes.
• SAMSTESTER goes only to segment #15. Shouldn't there be a segment #16 to account for 1024K? It starts at segment #1, not #0.
• AMSR4 is locking up at random memory pages. Not so with SAMSTESTER

 

Thanks. I am happy it is has some use to someone.  

 

I call the first 64K segment 0.  I only activate segments 1 .. 15 so not to tromp on the running system by accident.

So its Option Base 0  thinking. (which can get me into trouble sometimes)

 

Not sure about the lock-up.  My method is to fill the entire 64K segment with the pattern byte and also make a reference 4K buffer filled with the same pattern.

Then use a Forth word COMPARE ( addr1,len1,addr2,len2)  on each 4K chunk of the active segment.

 

I will look and see what could hang it up. Might be hard to find without a broken SAMS board.   

 

[+Vorticon]

6 hours ago, Ksarul said:

The 612 and the 688 are the two chips that have caused the most problems with the 100 or so boards I've built. BTW, you can use a 25LS2521 in place of the 74LS688, as it is an equivalent replacement (and in my experience, more stable).

The 688 is one of the chips not in my programmer's library, so I was not able to test it. Best replace it as well I suppose with the 25LS2521.

[+Vorticon]

5 hours ago, TheBF said:

Thanks. I am happy it is has some use to someone.  

 

I call the first 64K segment 0.  I only activate segments 1 .. 15 so not to tromp on the running system by accident.

So its Option Base 0  thinking. (which can get me into trouble sometimes)

 

Not sure about the lock-up.  My method is to fill the entire 64K segment with the pattern byte and also make a reference 4K buffer filled with the same pattern.

Then use a Forth word COMPARE ( addr1,len1,addr2,len2)  on each 4K chunk of the active segment.

 

I will look and see what could hang it up. Might be hard to find without a broken SAMS board.   

 

There definitely seems to be an issue with SAMSTESTER when it comes to detecting the size of the RAM on the SAMS card. Both Matt's Expansion Memory Tester and AMSR4 are reporting 512K, whereas SAMSTESTER is seeing 1024K.

[+TheBF]

3 hours ago, Vorticon said:

There definitely seems to be an issue with SAMSTESTER when it comes to detecting the size of the RAM on the SAMS card. Both Matt's Expansion Memory Tester and AMSR4 are reporting 512K, whereas SAMSTESTER is seeing 1024K.

Ok.  I was playing with it today and trying to do some more testing by putting bad bytes into SAMS and seeing if they were picked up.

It worked at that level.

As I write this I have an idea.  I need to erase my CPU RAM buffer each time before I page in new SAMS page .

 

Hang on I will get you another version.

 

 

 

[+TheBF]

When you turn over rocks you find bugs.

I made some progress but not ready for prime time yet.

I will keep at it tomorrow as time permits. Fortunately you have something that works better now.

Thanks for being the Alpha tester of the tester.

 

 

[+TheBF]

Well.. . it turns out making a SAMS memory test is trickier than I realized.

This version still does not test segment #0 ( the lowest 64K) so it's still not comprehensive but seems show if SAMS if working or not.

 

The method is: 

1. Use >3000 as the SAMS window. The default CPU RAM at >3000 is filled with >BF to identify it.    
2. Keep a 4K buffer at >2000 filled with >AA as a reference
3. In each 4K page copy the reference buffer into SAMS
4. Compare the SAMS page to the reference buffer, report result.
5. Turn off the SAMS mapper
6. Confirm that the default RAM page is >BF to test that pages are swapping in and out
7. Turn on SAMS and re-write the SAMS memory page with >55 (>AA inverted)
8. Compute a simple checksum on the SAMS memory, report result.

I also tested it on real hardware by sending it over RS232 to Camel99 Forth TTY.  Seems to work the same.

On Classic 99 with SAMS disabled, it aborts on the first test because the memory at >3000 does not change when the mapper is turned off.

 

Might be useful now to someone.  It was certainly educational for me.

This version is also smaller because I remove the 4K static buffer in the program space and replaced it with a buffer at >2000..2FFF. 

Spoiler

\ test sams card in 64K segments

NEEDS DUMP    FROM DSK1.TOOLS
NEEDS PAGED   FROM DSK1.SAMSFTH
NEEDS SDUMP   FROM DSK1.SAMSDUMP
NEEDS COMPARE FROM DSK1.COMPARE
NEEDS U.R     FROM DSK1.UDOTR

MARKER /SAMSTEST   \ command to remove everything when you are done.

HEX
7FFF CONSTANT 32K
FFFF CONSTANT 64K
1000 CONSTANT 4K

VARIABLE FATAL
VARIABLE PAT   \ remember the pattern we are using

: ?FATAL ( flag -- ) FATAL @ AND IF CR ." Stopped on failure" ABORT THEN ;

: ?BREAK   ?TERMINAL ABORT" *HALTED*" ;
: ERASE   0 FILL ;

2000 CONSTANT PBUFFER \ reference copy of the pattern we are testing

CODE MOVE16 ( addr1 addr2 len -- ) \ fast move 16bit cells
    C036 , C076 , C104 , 1306 , 0584 ,
    0244 , FFFE , CC31 , 0644 , 15FD ,
    C136 , NEXT,
ENDCODE

: BINARY   2 BASE ! ;

: .BIN     ( c -- )  BASE @ >R  BINARY  8 U.R  R> BASE ! ;
: .HEX     ( c -- )  BASE @ >R  HEX 4 U.R  R> BASE ! ;
: .PATTERN ( c -- )  DUP .HEX  ."  (" .BIN  ." )"   ;
: .ADDR    ( addr) HEX  0 <#  # # # # [CHAR] > HOLD #>  TYPE SPACE ;

: .RESULT  ( ?  ) DUP 0= IF ." PASS" ELSE  ." FAIL"  THEN  ?FATAL ;

: FILLREFBUFF     PBUFFER 4K PAT @  FILL ;

: SETPATTERN ( char -- )
      PAT !
      CR ." Bit Pattern = " PAT @ .BIN
      FILLREFBUFF
      CR ;

: FILLTEST ( SAMSaddr -- ?)
        PAGED  ( swap in the SAMS page)
        3000 @ BFBF = ABORT" Mapper not working" \ test if CPU RAM is there
        PBUFFER OVER 4K MOVE16
        PBUFFER 4K S= ;

: CHKSUM ( addr len -- n)
        0 -ROT BOUNDS  DO I @ + LOOP ;

: ERASETEST ( addr -- ?)
        PAGED DUP 4K 55 FILL  4K CHKSUM 5000 <> ;

: TESTSEG ( seg# -- )
      SEGMENT
      CR ." Pattern= " PAT @ .PATTERN
      CR ." Address    Fill     Rewrite "
      64K 0
      DO
        CR I .ADDR
        5 SPACES I FILLTEST .RESULT
        5 SPACES I ERASETEST .RESULT
        ?BREAK
      4K +LOOP
;

DECIMAL
: SAMSTEST
      PAGE
      CR ." SAMS Card memory test"
      CR ." ---------------------"
      16 1
      DO CR
         CR ." *SEGMENT*" DECIMAL I  3 .R
         CR I TESTSEG
      LOOP ;  ( 58 secs)

HEX AA SETPATTERN

: REPTEST ( SEG# -- )
     SEGMENT
     BEGIN
     PAGE ." SAMS 64K Repeat Test"
     CR   ." --------------------"
     CR ." *SEGMENT*" DECIMAL SEG @ 3 .R
        0 2 AT-XY
         CR SEG @ TESTSEG
         PAT 1+! FILLREFBUFF
         ?BREAK
      AGAIN ;

HEX
: REGTEST ( -- )
      1E00 'R12 !       \ select SAMS card CRU address
      SAMS-OFF          \ mapper off
      0SBO              \ turn on register memory
      4000 PAD 20 MOVE  \ save the registers

      CR ." Should see FFFF"
      4000 20  FF FILL
      4000 20 DUMP

      CR ." Should see AAAA"
      4000 20  AA FILL
      4000 20 DUMP

      CR ." Restoring registers"
      PAD 4000 20 MOVE  \ restore registers
      0SBZ
      SAMS-ON
;

: HELP
  PAGE ." * SAMS 1Mb TESTER Help *"
  CR ." --------------------------"
  CR ." HEX ( xx) SETPATTERN"
  CR ."    sets bit pattern used"
  CR
  CR ." ( seg#) SEGMENT sets segment"
  CR
  CR ." ( seg#) REPTEST Test seg# until BREAK"
  CR
  CR ." SAMSTEST  test all segments"
  CR
  CR ." ( addr len) SDUMP dump SAMS memory"
  CR
  CR ." FATAL ON  breaks on error"
  CR ." FATAL OFF no break on error"
  CR
  CR ." REGTEST "
  CR ." HELP  show this screen"
  CR ." BYE   leave the program"
;

: COLD  WARM
         PAGE ." SAMS Tester V1.6 @theBF 2020"
         CR ." HELP to see commands
         CR ." Initializing..."
         HEX AA SETPATTERN
         SAMS-OFF
         3000 4K BF FILL  \ fill non-sams page with BF
         SAMSINI SAMS-ON
         ABORT ;

 LOCK
 INCLUDE DSK1.SAVESYS
 ' COLD SAVESYS DSK2.SAMSTESTER

 

 

EDIT:  ZIP file removed.  See later posts for corrected version

 

SAMSTEST16.ZIP

[+FALCOR4]

One other tid bit of information that may help.  The top SRAM on the PCB is the lower half of the total memory and the bottom SRAM IC is the upper half of total memory.  If a test program makes it through the first half of memory and then flags errors afterwards then it is usually the bottom memory chip on the PCB.  If the software doesn't function at all or errors out somewhere in the lower half of memory then it may be the top SRAM IC.  In that case you could swap ICs and try again.

[+Vorticon]

36 minutes ago, FALCOR4 said:

One other tid bit of information that may help.  The top SRAM on the PCB is the lower half of the total memory and the bottom SRAM IC is the upper half of total memory.  If a test program makes it through the first half of memory and then flags errors afterwards then it is usually the bottom memory chip on the PCB.  If the software doesn't function at all or errors out somewhere in the lower half of memory then it may be the top SRAM IC.  In that case you could swap ICs and try again.

By top and bottom, do you mean lowest and highest address respectively or the other way around? This is always a source of confusion for me as I don't know what the correct terminology is.

[+Vorticon]

On 12/18/2020 at 7:11 PM, TheBF said:

Well.. . it turns out making a SAMS memory test is trickier than I realized.

This version still does not test segment #0 ( the lowest 64K) so it's still not comprehensive but seems show if SAMS if working or not.

 

 

I tested it out and this time around it does not get past the "Mapper not working?" message.

[+TheBF]

So that means your board is not switching pages in and out at least at address >3000 where I placed the SAMS window.

The was a double check I put in to prove that the hardware was actually doing something.

The test is write AA into a SAMS page. Then turn off the mapper (SBZ 1) and test to see the default >3000 memory page is there.

If I don't see >BFBF at >3000 that is the error.

 

So in hardware terms that might point to the 612 chip but I am out on a limb here. I have only skimmed the schematic on that board.

[atrax27407]

V 1.6 crashes immediately after start on real gear.

[+TheBF]

I only loaded it over  RS232 Forth.  I will transfer it to my floppy drive and give it a run.

Thanks for the feedback.

 

 

[+TheBF]

I hope the third time is the charm.

 

So I forgot that to initialize a real card you have to init both bytes of the SAMS registers. 

 

BUT... if you do that in Classic99 it dies. I believe Classic can use the 2nd byte to compute addresses for bigger cards and so things go wrong.

 

 

I have done my due diligence and loaded this onto my hardware with 2 floppy drives and 1M Sams card.

It seems to work as I expected.

 

There is a lot of re-writing internally to the test programs, factoring out the pieces so I could test them at the real console but the user doesn't see that.

 

Things to know: 

1. I have switched up the program to use mapped pages so it is testing pages 16 to 255. That probably makes more sense to people.
    
2. The SDUMP command is still SEGEMENT based so you set the segment and then you can dump any part of that 64K chunk of SAMS. (Like this:  5 SEGMENT  6FFF 100  SDUMP )
    
3. The test program commands  return to base 10 when they complete. If you used the HEX command and start a program, then BREAK out of the program, the interpreter will remain in HEX.
   Change that with the DECIMAL command if you need to.
    
4. The repeating test program REPTEST now takes a 1st page and a last page as input parameters. Remember they go on the left side of the command.  
   This lets you repeat a test on a section of the board over and over.  Example: HEX 40 50 REPTEST 

 

 

SAMSTESTER.ZIP

[Tursi]

1 hour ago, TheBF said:

BUT... if you do that in Classic99 it dies. I believe Classic can use the 2nd byte to compute addresses for bigger cards and so things go wrong.

 

Apologies, yes, Classic99 has a 32MB AMS card. I know non-standard breaks things, but I always expected one of the two writes in a word to be ignored on real hardware? I don't have a lot of information on the device, is my assumption wrong?

 

[+TheBF]

From what I can see yes.  I init the registers with a single byte and all is good on classic99.

But it doesn't work on a real 1M card.

 

[GDMike]

I ran this and got hung up at>005E., But I rebooted and it was fine afterwards.

Edited December 22, 2020 by GDMike

[+TheBF]

3 hours ago, GDMike said:

I ran this and got hung up at>005E., But I rebooted and it was fine afterwards.

Did it actually stop or did it just report a failure?

[GDMike]

Nahh,no error reported,  it hung froze.

I didn't shut down the SAMs card though beforeI restarted the program.

And after Sam's tester started up, it hit me like my ex wife in a dream, dang I should of shut down the PEB! But was too late the dream was over. And it ran the whole test out just fine.

 

 

[+jedimatt42]

Maybe interestingly...

 

My SAMS decided to hate me yesterday, for cheating on it with my sideport 32k... Now it just won't stay off the databus... However, if I pull the '688 chip out, the mapper can't be activated, and it behaves like a healthy 32K card.

 

I think, this indicates the '688 is faulty. That or the recipient of the comparator output.

[+Vorticon]

10 hours ago, jedimatt42 said:

Maybe interestingly...

 

My SAMS decided to hate me yesterday, for cheating on it with my sideport 32k... Now it just won't stay off the databus... However, if I pull the '688 chip out, the mapper can't be activated, and it behaves like a healthy 32K card.

 

I think, this indicates the '688 is faulty. That or the recipient of the comparator output.

Is your card a Fetzner one or the old generation? I was chatting with Richard Bell about this and he had never seen an old generation card fail, until mine did after 25 years of nearly daily use...

[+Ksarul]

I haven't had any boards of the new generation fail (yet). But I have had to carefully test each one I build to make sure the 688 and the 612 were working as designed, as both of those chips seem to have higher initial failure rates than the other LS chips on the board.  As already noted, I started using 25LS2521s in place of the 74LS688s early on, and I've had no problems with them at all (while about a quarter of the 688s I bought at the beginning failed immediately or during the burn-in).

[+FALCOR4]

On 12/21/2020 at 9:22 PM, Tursi said:

Apologies, yes, Classic99 has a 32MB AMS card. I know non-standard breaks things, but I always expected one of the two writes in a word to be ignored on real hardware? I don't have a lot of information on the device, is my assumption wrong?

 

On the 256k and 1M cards you only need to send one byte in the MSByte of a WORD.  In the 4M and above cards you need to send two bytes in a word; the 1M bank number in the LSByte and the page number in the MSByte.  The LS612 always overwrites the LSByte write with the MSByte write.  On the 4M and above cards the LSByte is latched and presented to the LS612 on the MSByte write cycle.

 

And on the larger cards, you only get the page number, duplicated in the MSByte and LSByte, when you read back a register.  The latch containing the bank number does not read back on the data bus.

SAMS registers explained_Srt_AP edits.rtf