• Please review our updated Terms and Rules here

Pettester versions and manuals?

Alan,

>>> If the testers we've been discussing indicate a problem with pages 0 and 1 of memory doesn't this point to a problem with a particular RAM chip (or supporting logic chip)? If not, why not or are we really looking at multiple RAM chip failure?

If you have a static RAM PET, then you will most likely have either 6550 or 2114 RAM devices. These are 4-bit wide devices. In this case, a page 0 or page 1 fault could be the result of one (or both) of I8 or J8 (note that the IC references may be specific to one particular PET board).

Dynamic RAM (on the other hand) is generally one 'bit' wide - so there will be eight (8) devices that could contribute to a byte fault.

In the case of a PET with dynamic RAM - you will have either 1 or 2 'banks' (meaning 8 or 16 physical devices). Depending upon whether each device has 8Kbits or 16Kbits will determine the maximum amount of RAM on the PET. Two banks of 16Kbit DRAM devices equates to 32KB.

Some PET memory testers are 'optimised' for a specific PET - so can identify which of the (say) 6550 devices are faulty based upon the address and data returned during the test. My PETTESTER (however) can be run on both static and dynamic RAM machines - so I have resisted the temptation to identify a specific device as faulty (as this will depend upon the PET mainboard itself). I have opted to document how the test works and to present details of how to determine the specific device/devices that could be causing the fault.

Some of the RAM/ROM replacement boards are equipped with multiple tester ROM images - so the user can use the 'right tool for the job'. My tester was optimised for dynamic RAM (this is what the MARCH memory tests were more designed for). But, nonetheless, it can still be used with static RAM.

Dave
 
Thank you for the explanation Dave. I now have a much better feel for the way in which PETTester works with regard to dynamic RAM.

My PET has 6550 static RAM chips only some of which are still functional so in practice I use Nivag's 8k replacement RAM board or his ROMulan PET RAMulator if I want 32k of RAM. Although the ROM/RAM board has PETTester V4 installed I originally used traditional methods to identify the faulty 6550s (six!). Essentially this involved a process of substitution using video RAM. The RAM chips are all socketed on the 320008 motherboard.

Alan
 
Alan,

With a static-RAM PET I would use the PETTESTER as a simple 'go'/'nogo' indicator.

If the RAM passes the test - the RAM is good. If the RAM doesn't pass the test - you would just swap out the associated RAMs for good ones.

Dave
 
daver2 said:
Alan,

With a static-RAM PET I would use the PETTESTER as a simple 'go'/'nogo' indicator.

If the RAM passes the test - the RAM is good. If the RAM doesn't pass the test - you would just swap out the associated RAMs for good ones.

Dave
Click to expand...

Not relevant to this thread but for clarity’s sake it may be worth pointing out that you don’t need spare 6550s in order to identify faulty chips. This is just as well because NOS 6550s aren’t easy to find at a sensible price and they also have a reputation for dying on the shelf. If anyone would like more detail about the process please let me know and I’ll start a new thread in response.

Alan
 
Reviving this old thread (which was mine) as it seems the right place to discuss Pettester.

We (over on the UK vintage wireless forum, (where there is a small vintage computing section) have found this test software (in particular the current V4) absolutely indispensable, so I would first like to take a moment to once again thank Daver2 for making it - it, and its manual really are excellent.

We had a recent case where due to a hardware fault a 4032 was able to write to, but not read from, the screen RAM. The result of this was that the first (screen RAM) test of Pettester showed a perfect 'pass' image because all bytes were being correctly written to the display, and all bytes were being correctly rendered to the screen by the display hardware, but the test was then holding indefinitely on the test screen because behind the scenes, Pettester had detected that at least some of the bytes read back from the screen RAM did not match the bytes originally written.

This told us that there was a problem with the data being read back from the screen, but nothing more specific about the nature of the problem, for example whether only certain locations were affected or whether specific bits were affected. If there is ever a V5 of Pettester, I would like to suggest a refinement to the screen RAM test.

Video RAM test Step 1: Pettester carries out the screen test that it does at the moment, filling the screen with a set selection of characters - basically the character set repeated over and over again. It should, as it does now, hold this display for several seconds. If write to / rendering from the screen memory is working properly, then the result screen will show the character set repeated over and over again, as it does now.

Video RAM test Step 2: (Suggested)
After briefly blanking / clearing the screen to indicate the end of the first phase of the video RAM test, Pettester reads the data from each screen RAM location and writes it back out to the same screen RAM location. If readback from the screen RAM is working perfectly, this will result in a video RAM test screen #2 which looks identical to the first test screen: but if there were read errors when reading from the screen, some or all of the characters on the screen will change. The difference between the PETSCII codes for the original character and the 'changed to' character will show which bits, or whether all bits are affected.

If the second stage test detects differences between the written characters and those read back, go into a holding loop where:
-The character set is written out to the screen RAM, filling it up (as per stage one)
-hold for one second
-the contents of the screen RAM are read back out and written back to the screen RAM (as per stage 2)
-hold for one second
-and repeat.

This will make it easy to look at any given character position on the screen (corresponding to a screen RAM location) and see which two characters it is toggling between - the correct character, and the one resulting from corruption via a faulty read. Looking up the PETSCII character codes for both characters will hopefully make it possible to see whether the problem lies with just a single bit, for example.

Another useful refinement, not related to the screen RAM test, would be to add the start-up 'chirp' which is present on later machines as this would be a useful sign that the machine is running well enough to execute code from onboard ROMs even if the screen has nothing on it and the system RAM is kaputt, due to the fact that Pettester is carefully written to avoid using system RAM, at least in the early stages. Even on PETs which don't have a sounder fitted as standard it would still be a simple matter to look for the 'chirp' output with a scope. I think Daver2 has already considered this feature?
 
Last edited:
Hi @SiriusHardware. I occasionally check over at the UK vintage wireless forum. I am a 'lurker' rather than a participant over there! Yes, I see my PETTESTER gets a thorough testing :)!

I have had a Version 5 in the pipeline for quite a while now. The trouble is, real work keeps getting in the way... I need to retire...

In version 5 I have added a significant delay between the various test screens - so that the human can see what the results are before the tests move on. That should address one of your issues.

I have also added the 'chirp' (if the sounder exists) to the DRAM test. I didn't want to introduce it too early, as it uses the VIA - and this can be a source of an additional failure mode. It 'chirps' after each successful DRAM test cycle pass.

I am happy to add the initial video RAM read/write tests you propose. Someone did suggest an alternative test, but your proposed solution seems more easy to implement. I will try and get around to that fairly quickly.

The thing that is holding up the Version 5 release is that I want to add a better page 0 and 1 RAM test. This test is quite basic as it stands. As a result, some page 0 or 1 RAM errors can 'sneak' through the simple tests and then mess up the subsequent ROM and DRAM testing later (PETTESTER crashes as it needs to make use of page 0 for some RAM locations to teethe DRAM memory and for page 1 for the stack). I think I have found a slightly more extensive test algorithm that I am trying out. Not as good as the MARCH-C algorithm I use for the DRAM test itself, but it should be better than what I have currently used.

My basic problem is running out of ROM space in the 2K. I could extend to 4K - but this would limit the use on some of the earlier versions of the PET - and I don't really want to sacrifice that. I may have to do a bit more code optimisation of what I have written to release a few bytes here and there.

Dave
 
Evening Dave, thanks for the response and for considering the update / upgrade to the video RAM test - I can appreciate that real life tends to get in the way. Thanks for all that you do manage to do, not only with Pettester but with all of the experience and knowledge you bring to the PET repair threads here - which we often refer back to when we are trying to get to the bottom of a problem. When we do come up against something out of the ordinary we sometimes find that something similar has already been seen and solved 'over there' on vcfed.

Cheers!

Sirius.
 
Cheers.

We still get the odd 'doozy' of a problem (we had one not so long ago) - which keeps the interest up!

Dave
 
Hi Dave. You may have seen a thread on vintage-radio.net with a 4016 I have that has been upgraded to 32k.

I've been helped through some page zero issues that stopped PETTESTER running and a new tool has been created to help diagnose page zero problems.

I'm now working my way through upper RAM issues using and comparing different diagnostics and noticed that PETTESTER (along with the Commodore Diagnostic Clip) only thinks the PET has 16k so it never tests upper RAM.

Could you educate me regarding how PETTESTER works out how much RAM it thinks is in a PET and whether there is any way to force it to test the full 32k even though it thinks there's only 16k there?

Thanks very much.

Colin.
 
Hi Colin.

PETTESTER performs a very simple test, starting very low down and working upwards in powers of 2 to sense what memory there could be present by a simple write and readback.

This is so that machines from the humble original 2001 (with partial 6550 RAM) up to 32K can be tested. But it does have the side effect (in the case of (say) an 8032) where a faulty byte in the first byte of the second bank of 16K would cause PETTESTER to only think there was 16K present to test.

There are two ways to approach this...

If the first 16K is OK, you can swap the two banks of 16K over by desoldering one end of the two resistors in series with the /CAS0 and /CAS1 signals and 'swapping the banks over' by crossing the signals such that /CAS0 drives the second bank of 16K and /CAS1 drives the first bank of 16K

Since you have the sources for PETTESTER, bypass my simple memory test and hardcode the amount of memory you 'know' is in your machine.

I have developed PETTESTER to be as 'generic' as I can, so it will work with all models of PET computers and different revisions of the Kernal ROM. However, providing the sources gives you the flexibility to customise it to your specific PET.

Although you have given me an idea for version 5 - to incorporate a macro to permit you to define the actual amount of memory rather than the simple memory test. Version 5 should hopefully have a better test for page 0 and 1 RAM, but I am having difficulty in fitting it all into 2K...

Dave
 
Thanks Dave for the explanation. We're (well, someone with much bigger brains that me) going to take a look and see if we can force the 32K test.

I suspect you're going to have to write a compression routine to get all of v5 into an EPROM....

Colin.
 
>>> I suspect you're going to have to write a compression routine to get all of v5 into an EPROM....

It has already been considered! A virtual machine language...

You should find a label DRAMCHECK: in the source file followed by the comment "Find top of ram. Assume either 4K, 8K, 16K or 32K.".

The code needs changing to:

Code: 
   .
   .
   .
; Find top of ram. Assume either 4K, 8K, 16K or 32K.

lda #$FF ; Must end on a 256-byte boundary.
sta ENDLL
sta ADDRLL

lda #$7F ; Assume 32K (7FFF) as an end address.
sta ENDHH
sta ADDRHH

lda #$32 ; 32K
sta MEMSIZE
sta TEMPA

lda #0 ; Used as a 'dummy index'.
tay

jmp MEMSIZEb

MEMSIZEa:
   .
   .
   .

The remainder of the code (from label MEMSIZEa onwards) can be left in place (even though it is not going to be used).

I can't guarantee that this will work - but you can try it...

Dave.
 
Probably worth pointing out that the patched version in the post linked to in #34 above also has its CRTC initialisation table modified for a 40-column machine, so is only immediately suitable for 32K 40-column machines unless the CRTC initialisation table is reverted back to the Pettester default values.
 
Hi! *slightly shy wave*

My name is Julie, and I'm one of the people Colin is referring to .....

And here, in the spirit of fairness and for GPL compliance, are the changes I made to daver2's PetTester:
Diff: 
--- PETTESTE2KV04.a65    2025-06-03 19:54:12.026772340 +0100
+++ PETTESTE2KV04-JM1.a65    2025-06-03 20:05:24.140965178 +0100
@@ -1030,6 +1030,8 @@
    
     lda    #$00        ; Start of DRAM to test (low byte).
     sta    STARTLL        ; "   "   "   "   "   "   "   "   "
+
+    ; Bodged to force 32K
    
     ; Find top of ram. Assume either 4K, 8K, 16K or 32K.
    
@@ -1037,11 +1039,13 @@
     sta    ENDLL
     sta    ADDRLL
    
-    lda    #$0F        ; Assume 4K (0FFF) to start with.
+    ; lda    #$0F        ; Assume 4K (0FFF) to start with.
+    lda    #$7F        ; Assume 32K (7FFF) to start with.
     sta    ENDHH
     sta    ADDRHH
    
-    lda    #$04        ; 4K
+    ; lda    #$04        ; 4K
+    lda    #$32        ; 32K
     sta    MEMSIZE
     sta    TEMPA
    
@@ -1051,8 +1055,13 @@
 MEMSIZEa:
 
     lda    #tst55
-    sta    (ADDRLL),y
-    cmp    (ADDRLL),y
+    ; sta    (ADDRLL),y
+    nop            ; Occupy same space as deleted instruction
+    nop
+    ; cmp    (ADDRLL),y
+    nop            ; Occupy same space as deleted instruction
+    nop
+    ; Now this will definitely branch
     bne    MEMSIZEb
    
     lda    #tstAA
When I assembled it, it was filling unused space with 00 rather than FF, so I ended up giving Colin a set of patches to make to the binary in a hex editor:
Code: 
Original:
000002d0  85 0b 85 0d a9 0f 85 0c  85 0e a9 04 85 14 85 05  |................|
000002e0  a9 00 a8 a9 55 91 0d d1  0d d0 23 a9 aa 91 0d d1  |....U.....#.....|
Modified:
000002d0  85 0b 85 0d a9 7f 85 0c  85 0e a9 32 85 14 85 05  |...........2....|
                         ##                 ##
000002e0  a9 00 a8 a9 55 ea ea ea  ea d0 23 a9 aa 91 0d d1  |....U.....#.....|
                         ## ## ##  ##

02d5 was 0f -> 7f
02db was 04 -> 32
02e5 was 91 -> ea
02e6 was 0d -> ea
02e7 was d1 -> ea
02e8 was 0e -> ea
And if anyone is interested in the test program I made for Colin, it's here at https://github.com/JulieMontoya/ToePost/tree/mainIt's about the first thing I've written on a PET in about 40 years, and the one before that was just a simple bubble sort for an assignment when I was in secondary (= high) school .....
 
You must log in or register to reply here.
Back
Top