PET 2001-8 Stability Issues

[Holmes]

Hello All.

I have a chicklet PET 2001-8, which I got about 6 months ago. I only got around to testing it for real recently, and have discovered some stability issues.

When I first got it, I just tried typing some short BASIC programs, and running them, and it seemed to work fine. The cassette did not work due to a blown drive belt, which I subsequently replaced. I've tried loading programs via the cassette, but have had trouble, and I think it's due to a leaky barrel capacitor near the cassette port inside (can see capacitor residue on the board).

So this is a very early PET, and the earliest I've ever seen. 6550 RAM ICs, and 6540 ROMs. It's also got the original ROMs with the faulty IEEE routines, such that neither my PETdisk nor my PetSD+ work on it.

So anyway, here's the problem. When I type a BASIC program, and muck around on it for about several minutes, the BASIC program garbles up, and the machine locks up (no cursor, no effect from the keyboard). It seems to be related to time, rather than anything else I can see, and I tested this by the following:

1) typed "10 PRINT "@@@@@@@@@@@@@@@@@@"
2) typed "20 GOTO 10"
3) typed "RUN", and it prints off about 40-50 lines, but then it gets garbled by a bunch of "$" signs and "D"s.
4) I hit "RUN STOP", and the cursor returns
5) typed "LIST", and it lists something like this:

1028 SAVE$DDDDDD$$$DD$$$$$$$$$$$$$$$$$$$$$$$$$$

and then it locks up.

When I shut it off for about 30 seconds, then turn it back on, I get the normal start-up screen. When I try the same thing, some variant of it occurs again.

In the above scenario, I didn't make any changes from when the program initially ran, and it just looped, so it can't be something that's changing on the user side (like accessing a certain memory location, etc.)

So does anyone have any ideas on what this is likely due to, just based on this info? I'm thinking it may be due to other bad capacitors, but I wanted to run it by you all. I probably need to recap the whole board, but I was avoiding this because it's such an early model of PET and wanted to keep it original if I could. I'd rather have a working one, though, so I may just break down and do it.

Any help would be greatly appreciated.

 

[dave_m]

You might try a quick look for clean +5V, but since an ASCII @ is 40 hex and a ASCII D is 44hex and a ASCII $ is 24 hex, it may be you have faulty RAM at data bits d2 and d5. 6550 RAMs are almost impossible to get.

Your best bet may be a RAM/ROM replacement board that fits into the CPU socket. They sell for about $75. That way you could run BASIC 1R or BASIC 2 and get your IEEE 488 PETdisk to work properly.

You could leave your original RAM and ROM in place.

EDIT: I forgot about the two video RAM chips. The problem might also be there, but since the PET locks up, it is less likely. Note the RAM/ROM replacement board does not replace the two video RAM chips.

 

[Holmes]

You might try a quick look for clean +5V, but since an ASCII @ is 40 hex and a ASCII D is 44hex and a ASCII $ is 24 hex, it may be you have faulty RAM at data bits d2 and d5. 6550 RAMs are almost impossible to get.

Your best bet may be a RAM/ROM replacement board that fits into the CPU socket. They sell for about $75. That way you could run BASIC 1R or BASIC 2 and get your IEEE 488 PETdisk to work properly.

You could leave your original RAM and ROM in place.

EDIT: I forgot about the two video RAM chips. The problem might also be there, but since the PET locks up, it is less likely. Note the RAM/ROM replacement board does not replace the two video RAM chips.

Dave,

Thank you for your response. I'll check out the 5V line next chance I get.

So if RAM is going bad, can it be good one moment, then bad after a few minutes? I thought if it were bad, it would be bad from the beginning. I guess it could show it's aberrant behavior after it warms up. I'm just trying to understand it more.

Also, if I turn the machine off for 30 seconds, then turn it on again, it's fine for a few minutes. Then the same thing with garbled memory. If the RAM is bad when it warms up, I would think the RAM chips are still warm (only being off for 20-30 seconds), and that the errors would show themselves again right away.

I'm a bit against the RAM/ROM replacement boards, since it seems like you're not using most of the original motherboard and are bypassing it, but as the ICs are very rare there may not be many other options. I did see someone online with modern 6540/6550 replacements (a small PCB with a modern chip in it that matches the footprint of the original ICs). I'd like to try to keep it as original as possible, but again, it doesn't seem like there are many options. Here's a link: http://www.ebay.com/itm/Commodore-P...039895?hash=item3d0a5f8f97:g:V3YAAOSwYmZXL8gO ( listed as "Commodore PET 2001 ROM Chip Adapter (MPS6540 MOS6540 6540)" ).

I'll do another test, and upload some specific screen shots. I never thought of trying to correlate the garbled characters with the memory location bits.

Thanks again!

 

[Holmes]

So I did some specific testing. I ran 3 tests, varying what I printed with each one. In each case, I ran the looping BASIC program, and they generally garbled in 1-2 minutes of looping. It's interesting to see the characters garble up a few iterations before the program crashed. In each case, I attempted to list the program after the program crash, and was able to, but the listing was also garbled.

Test 1: "AAAAA"


Test 2: "CCCC"


Test 3: "ABCDEF"


It looks like the memory garbles until it can't run anymore. It's interesting that test 1 and 3 both report an error in line 9252 when they halt execution, although the text printed was different. Test 2 stopped with no error, just a jump to the "READY" prompt.

I tried to correlate the character codes that were supposed to print, and the ones that actually printed, to find a pattern, but could not.

For instance, in test 3, you will notice the A changes to a D and an F. A is (1000001), and D is (1000100), and F is (1001010). Okay, so A->D is a 2 bit change, but then to F is a 3-bit change.

Also, in test 3, B changes to @, and C also changes to @. B is (1000010), and C is (1000011), and @ is (1000000). So B->@ is a 1 bit change, but C->@ is a 2-bit change.

F also changes to @ (000110 to (1000000), which is a 3-bit change.

So none of the character changes make any sense to me. I was hoping there would be a clear pattern in this, but I couldn't find one.


It does seem like the memory errors seem to grow until the program cannot continue. The program listing after the execution error/halt all look very similar. I wonder if any of those characters have any significance.

I'd love to try to find the memory chip that's causing the error, and then I'd have a place to start.

Please let me know if anyone has any other thoughts on this.

Thanks!

 

[MikeS]

The first step is usually reseating all the chips; I wouldn't actually remove them, just slide them back and forth a bit in their sockets.

Another thing to try (in case it's a bad RAM chip) is to remove the leftmost 6 pairs of chips, just leaving I1&2 and J1&2; if the problem remains, replace those 4 with 4 of the ones you removed (try to keep track of which is which).

Good luck!

 

[dave_m]

Try what Mike suggests especially if the RAM chips are on sockets. If not on sockets, maybe try some 'circuit freeze' to find the heat sensitive parts. Do you have a way to load programs? Running a RAM test may detect a problem chip also, assuming the PET will hang in there long enough to complete a few loops. As all this may take many resets, hook up a pushbutton to ground /RES at J4-pin 27 to avoid power cycles.

 

[Holmes]

The first step is usually reseating all the chips; I wouldn't actually remove them, just slide them back and forth a bit in their sockets.

Another thing to try (in case it's a bad RAM chip) is to remove the leftmost 6 pairs of chips, just leaving I1&2 and J1&2; if the problem remains, replace those 4 with 4 of the ones you removed (try to keep track of which is which).

Good luck!

OK, so by doing this, I'm only testing a subset of the RAM chips at a time. If there's no problem anymore, then the problem must be with one of the RAM chips I removed, so I can swap them back in to the 1 & 2 columns of RAM, until I find the bad ones by my little BASIC test program - is that what this method is doing?

So if I remove 3/4 of the RAM chips, then I'm only running the PET with 2KB, right?

Cool, thanks for the suggestion!

 

[Holmes]

Try what Mike suggests especially if the RAM chips are on sockets. If not on sockets, maybe try some 'circuit freeze' to find the heat sensitive parts. Do you have a way to load programs? Running a RAM test may detect a problem chip also, assuming the PET will hang in there long enough to complete a few loops. As all this may take many resets, hook up a pushbutton to ground /RES at J4-pin 27 to avoid power cycles.

View attachment 34664

Okay. Yes, the RAM chips are socketed.

Unfortunately, I can't get anything loaded, because my built-in cassette doesn't work. I just bought a modern cassette interface kit to interface an MP3 player with the cassette port, but haven't tested it yet. Too bogged down with projects!

I just finished a custom-built PetSD+, which works great on my PET 2001-32N, but too bad I can't use it on this PET!

Good idea about the reset switch - I cringe every time I turn a computer off and on to reset it. I actually had an old one I built for the 2001-32N, but it connects via header pins on the J4 block on that motherboard. This PET only has the card-edge connectors, so I'm foiled there.

I did find a memory test program out there:
http://www.commodore.ca/commodore-manuals/commodore-pet-memory-test/

but I don't think I could type it in quickly enough for it to work on this PET.

If I can get my cassette-MP3 device working, I could type it in on my 2001-32N, and save it to MP3, then load it on this PET's second cassette port - maybe that one's working.

Thanks for the ideas! I'll post back when I have tried some of these suggestions.

 

[dave_m]

So if I remove 3/4 of the RAM chips, then I'm only running the PET with 2KB, right?

Yes, the PET will work fine with 2KB of RAM.

 

[dave_m]

Good idea about the reset switch - I cringe every time I turn a computer off and on to reset it. I actually had an old one I built for the 2001-32N, but it connects via header pins on the J4 block on that motherboard. This PET only has the card-edge connectors, so I'm foiled there.

Just tack solder a wire from the switch to the gold contact at J4-27 or even to the leg of IC D9-pin2. On the J4 connector, the bottom side contacts are the signals (1 thru 40) and the top side contacts are all grounds.

 

[Holmes]

Just tack solder a wire from the switch to the gold contact at J4-27 or even to the leg of IC D9-pin2. On the J4 connector, the bottom side contacts are the signals (1 thru 40) and the top side contacts are all grounds.

OK, cool idea. Actually, I have some mini-grabbers that I can use on the IC pins of D9, so I'll use those for the reset.

Thanks!

---------------------

So I also did a bit more testing this AM.

I reseated all the RAM chips and most of the socketed ICs, and retested with my looping PRINT program, and got similar results as before.

I checked the 5V line on J1, and it appears to be 5V, but it's really noisy with range from +4.75V to +5.3V. Don't know if that's too noisy, but there it is.



So an interesting note, while testing the +5V line of J1, I just left the PET alone - no typing or program. The fiddling with my scope took about 10 minutes. Then I came back to the PET after getting my readings, and the cursor was still active and flashing as normal. I typed "LIST" (no program entered), and got "9252$$$$$$$$$$$$" and string of continuous $'s. I think it was "9252" at the beginning, because I wasn't ready for it, and didn't have my camera ready. Wasn't able to retest this since I had other things I needed to do (life intervenes). That's the same number that the looping BASIC program was aborting on ("SYNTAX ERROR IN 9252").

Anyway, I labelled all my RAM chips, and will proceed with the removal of the upper 3/4 of them, and report back.

 

[KC9UDX]

OK, cool idea. Actually, I have some mini-grabbers that I can use on the IC pins of D9, so I'll use those for the reset.

Thanks!

---------------------

So I also did a bit more testing this AM.

I reseated all the RAM chips and most of the socketed ICs, and retested with my looping PRINT program, and got similar results as before.

I checked the 5V line on J1, and it appears to be 5V, but it's really noisy with range from +4.75V to +5.3V. Don't know if that's too noisy, but there it is.

View attachment 34673

So an interesting note, while testing the +5V line of J1, I just left the PET alone - no typing or program. The fiddling with my scope took about 10 minutes. Then I came back to the PET after getting my readings, and the cursor was still active and flashing as normal. I typed "LIST" (no program entered), and got "9252$$$$$$$$$$$$" and string of continuous $'s. I think it was "9252" at the beginning, because I wasn't ready for it, and didn't have my camera ready. Wasn't able to retest this since I had other things I needed to do (life intervenes). That's the same number that the looping BASIC program was aborting on ("SYNTAX ERROR IN 9252").

Anyway, I labelled all my RAM chips, and will proceed with the removal of the upper 3/4 of them, and report back.

It was 9252, I promise.

'$$' is 9252 in decimal. Your RAM is full of $s, or, your data bus is stuck at 00100100 in just the right spot.

 

[dabone]

I ended up just putting a Petvet in my 2001 with the same motherboard, I got mine working perfectly, but installing the petvet and removing the original ram/roms make it run sooooooo much cooler.
(And you get a basic that supports ieee.)

Those ram chips are very hard to find.

Later,
dabone

 

[Holmes]

It was 9252, I promise.

'$$' is 9252 in decimal. Your RAM is full of $s, or, your data bus is stuck at 00100100 in just the right spot.

OK - cool. That actually makes sense, and helps explain these strange results.

I ended up just putting a Petvet in my 2001 with the same motherboard, I got mine working perfectly, but installing the petvet and removing the original ram/roms make it run sooooooo much cooler.
(And you get a basic that supports ieee.)

Those ram chips are very hard to find.

Later,
dabone

I'm going to try to replace individual RAM chips, depending on how many I have to do. I'd like to keep it as close to original as possible, at least at present.

---------------------------------

Testing Update
===========

So using Mike's and Dave's suggestions I did more testing.

First of all, I hooked up some mini-grabbers on pins 2 and 7 on 74LS04 at D9 for my makeshift RESET switch. Tested it, and it works great.

Then I removed I3-I8 and J3-J8 RAM chips. This left I1, I2, J1, and J2 there for a total of 2KB of RAM.

Then I retested using my simple looping BASIC print program, and as expected, it halted in about 2 minutes, and then attempting to reference the memory by typing a "LIST" command or a new program line for line 10 (such as typing '10 PRINT "SOMETHING ELSE" ') caused the PET to lock-up. When I use my RESET switch, it returns me to the normal startup screen, but any attempt to enter a new BASIC program results in a lock-up immediately. When I turn off and then on again, I can type a new BASIC program, and run it for a few minutes before it halts.

So the problem is still there with only 2KB installed. So this means the problem may be in those 2KB. So I replaced the I1, I2, J1, and J2 chips with I5, I6, I7, and I8. Then I typed in my same BASIC looping print test, and ran it. Guess what? It ran for over 30 minutes with NO problems!

So it seems like I've narrowed this problem down to 4 RAM chips. I'll try to get it down to specific chips in my next testing session. Or I may just put the remaining chips back in, and type in the BASIC RAM test program to find the faulty RAM chips, since now it seems I have some memory to store a program long enough to test the rest of the RAM.

There may be other RAM chips in there that are bad, so I am leaning towards just doing it this way, unless someone else has a better idea. I'll put the original I1, I2, J1, and J2 in the highest RAM positions, since there is definitely a problem chip in there, and this may give me more RAM for the test program.

I'm going to try to use this program:

http://www.commodore.ca/commodore-manuals/commodore-pet-memory-test/

It seems to run in the first 2KB, so that fits my scenario perfectly.

One more thing. I tested my Cassette port-MP3 player card kit, and found that it did not work. It was built as mainly for a C64 cassette port, and I was using a WAV file I created from a PRG using an online tool, since that was the only source for a sound file that I could find. It could be I didn't make the sound file quite right, since there are lots of setting in the program. I will have to work on this a bit more. If I can get this working, it will be a tremendous help in healing this sick PET.

Thanks for the help so far! I'll post with further updates.

 

[Holmes]

So here's another update.

So now I think I have the PET 2001-8 in a state that I can at least run short BASIC programs without running into memory corruption errors. The key now is to get a RAM test program into memory and run it.

I typed the memory test program linked above into my PET 2001-32N, and tested it. Phew, I haven't typed in a full BASIC program in about 35 years! I tested it and it seemed to work. I have an external Commodore Datasette, so I scrounged up a cassette and saved it on there. Tested loading it up, and it worked.

I moved the Datasette over to the PET 2001-8, and tried to load it, and it did not work. I tried multiple times in the external Datasette, and the internal cassette. On the external, it seems to find the program, and says "FOUND MEMTEST", and then "LOADING", but then never ends. On the internal datasette, it is almost the same. It shows "FOUND MEMTEST", and then "LOADING", but then says "?LOAD ERROR", and the program has the first few lines, but the rest is garbled and lists endlessly again, requiring a RESET or cold restart.

So I was then thinking - maybe I ran into another block of bad memory. So the Memory Test program is about 40 lines of code, so I typed in a program consisting of about 30-40 duplicate lines of PRINT "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX", which has about 30 characters in each line. Theoretically, this would take up at least as much RAM as the memory test program. Well I was able to run this program just fine for several minutes, so I guess it can't be another memory problem in the early RAM chips.

Maybe this PET 2001-8 has cassette issues as well. Hmm, looks like I'm running out of options.

I may just have to type the program in on the 2001-8 all over again, and just try it out like that, and fix the datasette problem later.

Let me know if anyone else has any thoughts on this. Thanks!

 

[KC9UDX]

When I had bad RAM, I ran into problems loading small programs from tape, which could be entered by hand just fine.

I don't know if this was because there was bad RAM right on page boundaries, or what the cause was. I don't really know how the tape loading routine works, I wouldn't think it would be that different memory-wise than entering the program by hand; but that's what was happening. Once I replaced the RAM, tape loading became reliable.

One thing that would happen a lot was partial warm boots during loading:

 

[Holmes]

Wow, that's cool. If you didn't have the video of that, I wouldn't have believed you. Who would have thought?

I guess the PET must be using some of the RAM to do its cassette loading, which might explain this. It would be neat to figure out why.

Ok, I'll type in the memory test and see how it does.

Thanks!

 

[KC9UDX]

I do know that cassette operations on the VIC/64 make extensive use of zero page.

Perhaps it's just a matter of zero page being just good enough to boot and run small programs without noticeable error, but not good enough for cassette work. But I'm just guessing.

 

[dave_m]

Cassette #1 temporarily stores input in Tape Buffer #1 at $027A - 0339. Cassette #2 at $033A-03F9, while keyboard input uses the screen RAM. So it possible you still have a problem with the first 1K ($0400) of RAM.

In the old days, short assembly language routines were stored in the Tape Buffer #2 to speed up BASIC programs without disturbing the BASIC area (above $0400). It was considered a fairly safe place to store programs assuming the second cassette was not being used.

 

[KC9UDX]

Yes, thanks for the correction, Dave! I kept thinking the buffer was in zero page, but it is not.

So it would be very worthwhile at this point to test the RAM from $027A..$03F9, and of course like you say, the whole first 1k, at least.

The problem of not being able to properly load files from tape would be explained by bad buffer RAM. The problem I had with execution running amok would not.