• Please review our updated Terms and Rules here

Add another PET to the emergency room

T

tezza

Veteran Member
Joined
Oct 1, 2007
Messages
4,731
Location
New Zealand
Boy, no one told me keeping a PET would be so much work.


In another thread I mentioned a PET 3032 board that I thought was working now isn’t. The situation has just got worse. Now my MAIN PET board is also one sick puppy.

It was fine until I started to swap a few chips (CPU and ROM) between it and the faulty board. Now the working board has failed.
On power up instead of the BASIC cursor and message I get these few characters.

pet-symptoms.jpg

The top rows are always the same. The bottom row sometimes has five or so characters and at other times, two or one.
There is no sign of a cursor and blind typing something like “Load” doesn’t move the cassette deck. RAM has been piggybacked. ROM has been checked and is fine. All other socketed chips (6520, 6522, 6502, character gen) have been swapped out. CPU has been tested in another machine.

I’m sure the CPU is working because when I power on when the screen is still warm I can see the garbage screen briefly, which then clears as it should..only to be replaced by the screen above. So I think it’s getting a fair way down the boot pathway.

Anyone seen anything like this before? If not I’ll start the long process of signal tracing. Philip Avery has his scope back so I can’t use that right now (yes, I am working on getting one of my own).

I did notice the Testing ROM. Unfortunately I’ve no good 2732s (or 2532s) left.

These PETS sure are tempramental beasts.

Tez
 
Ouch! I feel your pain. The board in question is the one from me? It was a customer return at one point, but as both me and in particular you have had it working fine for a while, it shouldn't have been defective to start with.

As mentioned in another thread, you should get a Basic prompt with a little flicker if you remove both 6522 and 6520. I don't know what can happen if you have partly or completely bad chips in those sockets. What happens if you remove the 6502 as well, does it remain at the garbage screen?
 
Hi Anders,

Yes, it is the one from you, but that board has worked well up until now. The fault has definitely just developed.

Ok. with the 6522 and 6520 removed I get the same two top lines but then followed with six lines of "::" characters across the screen.

With the CPU out I get the garbage screen.

I did swap out the 6522 and 6520s with the other board to, with no change.

I think it's trying hard to boot and getting part way there.

Tez
 
tezza said:
[It was fine until I started to swap a few chips (CPU and ROM) between it and the faulty board. Now the working board has failed.
Click to expand...
Did the working boards immediately stop working when you put them back into the working PET or did they stop working after a few startups? What's with all the PETs going bad recently?
 
Clearly the pure malignant evil of my 4032 has been unleashed on the PET world simply by speaking of it...

Since it started after you swapped ROMs and you get a normal garbage screen when you pull the CPU I'd suggest starting with checking all the lines to the ROM sockets. (And also check to make sure the sockets themselves are okay.) I wonder if the dynamic board is prone to cracking traces in that area because in addition to having to fix one myself my 4032 had a previous repair in the ROM area when I got it.
 
carlsson said:
Stupid question, but have you double checked that the ROMs are in the right order as you pulled them out and put them back?
Click to expand...

Nothing is a stupid question but yes, I'm sure they are in the right order. This is the first thing I thought of. I checked and double checked this.

I also swapped in the old PET BASIC 2.0 ROMs and got exactly the same symptoms.

DOS lives on!! said:
Did the working boards immediately stop working when you put them back into the working PET or did they stop working after a few startups? What's with all the PETs going bad recently?
Click to expand...

I wasn't taking notes at the time (I should have) but I THINK it happened when I swapped over the CPU with (what was then) my one non-working board. I was trying to get the non-working board going. It was then the working board packed up too.

BUT, the VERY first time I substituted my newly burned BASIC 4.0 ROMS I got what I THINK was a similar problem (but I can't be sure it was..it may have just been the old garbage screen) . Thinking it was just a bent pin, or maybe the wrong order, I removed them, checked (it was neither of the two) then reinserted. The machine then booted fine. I shrugged off the initial non-boot as some sort of random aberration and wrote that blog article on the upgrade.

Naturally I regret now fiddling around with the working PET. These things are obviously touchy.

Eudimorphodon said:
Since it started after you swapped ROMs and you get a normal garbage screen when you pull the CPU I'd suggest starting with checking all the lines to the ROM sockets. (And also check to make sure the sockets themselves are okay.) I wonder if the dynamic board is prone to cracking traces in that area because in addition to having to fix one myself my 4032 had a previous repair in the ROM area when I got it.
Click to expand...

Yes, I wonder about the sockets myself. Especially when I got a non-boot when I first exchanged these BASIC 4.0s with the 2.0s. The sockets and the solder underneath LOOKs fine even under high magnification but....

If it was a dodgy socket I'd expect a boot occasionally, given that I've adjusted the chips and pressed them down ect. while I've powered on, looking for a possible "connection". Still, the failure was triggered by the pulling/insertion of either the CPU or ROMS. The PET could simply be playing with me of course, and something else (RAM?) may have gone just coincidently.

Malignant evil? Dunno, but PETS seem to be in full revot at the moment!

Tez
 
tezza said:
Naturally I regret now fiddling around with the working PET. These things are obviously touchy.
Click to expand...
That's the only way you learn. I once swapped RAM from a nonworking 5160 to a working 5160. It made the working one not show anything on the monitor at all, I thought I had blown it. Even when I took the faulty RAM out, it still didn't work!! Turns out, when I was swapping RAM, the edge of one of the RAM sticks accidentally hit a dip switch on the video card.
 
As an aside my second PET 3032 board shows the classic garbage screen. However there are blinking characters in there so I think the clock is working anyway.

This second board had been in storage and was working when it went in there, apart from a tiny bit of video snow (maybe a dodgy 2114). Now it doesn't work at all *sigh*

It seems PETS not only show adversion to handling, they don't like being neglected either! :)

I haven't explored the issue on this other board yet. I know the ROMS, CPU, 6520s and 6522s are ok.

Tez
 
tezza said:
If not I’ll start the long process of signal tracing. Philip Avery has his scope back so I can’t use that right now
Click to expand...

Tez, while waiting for Philip's scope, measure the bias voltages at one of the dynamic RAM chips. Make sure there is a good +5, -5, and +12.

When the scope arrives, check each pin of the ROMs looking for a suspicious signal. hopefully the CPU is running in some loop so there will be some normal activity.

I dread the day this happens to my PET. no screen and no real clue as to what's wrong. Plus I have very few parts on sockets and I don't have your persistence. :)

You seem to have a good number of chip on sockets which is a help.
-Dave
 
When looking for continuity problems with the ROMs I'd suggest checking by using the legs of the socketed ROM as test points. The board trace on my 4032 was legitimately bad (since it failed testing between the solder points for the sockets), but the "no keyboard response" problem I had that was due to the system missing the 60hz interrupt was caused by the socket for the associated 6520 being "iffy". (It wasn't making contact on the associated interrupt pin unless the 6520 was snugged down into place *tightly*, which I did while the board was removed from the case so I wouldn't put undue flex on it.)

I know it's a lot of points to test, but since most (everything but the chip select?) of the pins of the 4k ROMs are essentially wired in parallel you can pretty easily place one end of your multimeter on pins on the leftmost socket and then walk the other end of the row testing the matching pin. (Most of the lines match on the 2k EDIT ROM as well.) If they all check out then I'd check out the chip select lines before bothering with continuity on the data line to the CPU and address lines to the 74LS244 address buffers. Since your computer is clearing the screen I'd guess it's at least running *some* of the Kernel ROM, so I doubt the problem is an "upstream" data/address line break.

If you can get your hands on an appropriate EPROM to burn I'd humbly suggest the PETTESTER ROM I attached to my thread of DOOM might be useful. :^/
 
tezza said:
...Naturally I regret now fiddling around with the working PET. These things are obviously touchy.
Click to expand...
Well, that's a bit of a generalization; my PETs have been subjected to considerable abuse, experimentation and neglect in their 30-odd years and have not had any problems other than a bad cap in a monitor, the crappy sockets in the 2001s (cured with Stabilant-22), one failed 6540 ROM and (mainly) the consequences of my own carelessness. Keep in mind that you're only reading about problems here, not the many PETs happily purring away out there ;-)

Small comfort though; hope all your problems are simple ones !
 
Ok, after raiding the junk components box I found a 2732 EPROM. This was erased, reprogrammed with the PETTESTER ROM binary and an adaptor socket made up so the PET thinks it's a 2532.

It seems the PET is breathing and alive even through comatosed. What I'm seeing is a full character set, which then cycles to a screen full of "g"s, then back again. I'm picking this is what it's suppose to do. Thanks for writing this Eudimorphodon. Would this suggest there should be enough good RAM for at least a successful boot?

I checked those ROM lines. All good and connected through just like they should be.

I also checked the 4116 RAM voltages as suggested by Dave. Also fine.

It certainly seems like the machine is getting stuck somewhere in the bootup sequence. My initial suspicion was on my own recently-burned EPROMS except.

1. The machine worked with those ROMS initially
2. I've checked and rechecked them against the binary images in the Willem and they are fine
3. The BASIC 2 ROMS (which I've also checked out as good) show exactly the same symptom. This would indicate the problem has nothing to do with the code inside the ROMS as BASIC 2 is different from BASIC 4.
4. I'm sure I've got them in the right order.

I'm not sure how much time I can spend on the PET this weekend, but I'll beever away at it when I get the chance.

Tez
 
One more result. Just before heading in I tested the SN 74154 decoder at the end of the ROM bank with a multimeter just to see if anything was stuck on high or low. It seems to conform to its truth table. I conclude it's probably ok.

Tez
 
tezza said:
It seems the PET is breathing and alive even through comatosed. What I'm seeing is a full character set, which then cycles to a screen full of "g"s, then back again. I'm picking this is what it's suppose to do. Thanks for writing this Eudimorphodon. Would this suggest there should be enough good RAM for at least a successful boot?
Click to expand...

The screen full of "g"'s tells you that the first 1000 bytes of RAM passed a simple "fingers and toes" memory test. (It only writes a single pattern of bits. I've been meaning to clean up the source for that ROM and make it try two "even/odd" patterns instead) so it doesn't absolutely rule out a bad RAM chip, but it should indicate the RAM subsystem is basically working. (You'd see "b"'s for any bad bytes.)

When I get a chance I'll try to finish my code cleanup and post an image with a more definitive RAM test. I've also been thinking it might be interesting to hack the delay loop section (There's that two-second-ish delay between the character set and the RAM test cycle) so it definitively exercises all address and data lines while it spins through the loop. As it is it just reads chunks of data from VRAM as it's wasting time.
 
Like I suggested before I think it would be really useful if that test EPROM contained a routine to sum up checksums of all the ROMs; that would really help a lot by confirming that they and their respective address and data signals are OK.
 
Thanks for those comments guys.

Just for fun, I tried the PETTESTER in the second non-working board. This time nothing happened. All I got was the classic garbage screen which would indicate something far more fundamental with this one.

Anyway, gotta go otherwise divorce might be on the cards :)

Tez
 
tezza said:
Philip Avery has his scope back so I can’t use that right now (yes, I am working on getting one of my own).
Click to expand...

Oh dear Tez - more PET trouble. I was going to suggest checking ROMS in the Willem programmer as faulty ROMS feature highly in PET troubles! But you've already done that.

The scope: Yes I'm using it to sort out our monitors. (Tez & I have 3 identical "green screen" monitors of circa 1980 Hong Kong manufacture. Cheesey construction they have, a circuit diagram we don't. However one of the three works, so I'm able to make comparative measurements.)

Philip
 
MikeS said:
Like I suggested before I think it would be really useful if that test EPROM contained a routine to sum up checksums of all the ROMs; that would really help a lot by confirming that they and their respective address and data signals are OK.
Click to expand...


Yeah, I was thinking of that too. The coding limit I'm bumping up against in the current version is I can't think of a useful checksum routine that can work without using RAM. Of course, I guess the simple solution would be to test the zero page and if it checks out branch to extended tests. I think I should be able to code that...
 
You must log in or register to reply here.
Back
Top