MikeS
Veteran Member
Yeah, if that RAM is bad you might as well fix that first anyway.
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
Add another PET to the emergency room
- Thread starter tezza
- Start date
tezza
Veteran Member
Hmmmm.....
Good news but not really. My second board (the one that was in storage) is now working but I have no idea why.
As I mentioned before I gave the second board a run with the PETTESTER. It didn't fire at all. However, while it was in there I did some basic checks on the CPU with my voltmeter. Address lines seemed ok (neither very high or very low), a clock seem to be there (or rather 2V was there) and RESET was at about 4.5V. On pin 7, sometimes it was 0.01 but other times it was anything between 1.0 and 0.01?
Anyway, I thought I'd drop the BASIC 4 ROMS in just to see what happened on the CPU Pin 7. Switched on and VOLIA, a BASIC 4 prompt??
It wasn't prefect. There was the odd character at odd places on the screen but this was the state it was in when Philip Avery and I stopped working on it. At the time Philip felt the trash was probably due to a failing 2114. He'd already changed and socketed one. I clipped the second 2114 off and piggybacked a good one over the pins. The screen is now perfect, so it seems that was the problem. I'm now going to add a socket and the replacement.
I'm not estatic though because I have no idea why the machine has suddenly started to work. I means it can fail again just as easily. Well, at least while it's going I have a good board I can make comparisons with. It might help me fix the faulty one, if it lasts.
Perhaps it is dodgy sockets in this board (in particular a dodgy U9 socket, as the PETTESTER didn't work when there). I didn't check the socket continuity in this board like the other one. If it fails again that's the first place I'll look.
Tez
Good news but not really. My second board (the one that was in storage) is now working but I have no idea why.
As I mentioned before I gave the second board a run with the PETTESTER. It didn't fire at all. However, while it was in there I did some basic checks on the CPU with my voltmeter. Address lines seemed ok (neither very high or very low), a clock seem to be there (or rather 2V was there) and RESET was at about 4.5V. On pin 7, sometimes it was 0.01 but other times it was anything between 1.0 and 0.01?
Anyway, I thought I'd drop the BASIC 4 ROMS in just to see what happened on the CPU Pin 7. Switched on and VOLIA, a BASIC 4 prompt??
It wasn't prefect. There was the odd character at odd places on the screen but this was the state it was in when Philip Avery and I stopped working on it. At the time Philip felt the trash was probably due to a failing 2114. He'd already changed and socketed one. I clipped the second 2114 off and piggybacked a good one over the pins. The screen is now perfect, so it seems that was the problem. I'm now going to add a socket and the replacement.
I'm not estatic though because I have no idea why the machine has suddenly started to work. I means it can fail again just as easily. Well, at least while it's going I have a good board I can make comparisons with. It might help me fix the faulty one, if it lasts.
Perhaps it is dodgy sockets in this board (in particular a dodgy U9 socket, as the PETTESTER didn't work when there). I didn't check the socket continuity in this board like the other one. If it fails again that's the first place I'll look.
Tez
tezza
Veteran Member
Update: Well actually just seeing the boot up splash screen doesn't mean this spare (original) board now works. I replaced the 2114 and the screen is now clear. However, now that it is free of miscellaneous characters I've notice something else. There is no prompt!
In fact, the machine seems to be halted just after the splash screen. The keyboard does nothing and it's not typing "invisible" characters either. Pressing RETURN many times does not scroll the BASIC header off the screen. So, the spare board has a long way to go yet before back to a working state. Do the following observations offer any clues though?
1. With BASIC 4.0 it comes up with the BASIC message (showing full RAM) and READY but no prompt is displayed and the machine seems to lock at this point.
2. With BASIC 2 it doesn't even get that far: - it's a frozen garbage screen
3. With the PETESTER ROM it's also a frozen garbage screen
I've swapped and reswapped these ROMS quite a bit tonight and always with the above results. I'm intrigued to know why the BASIC 4 gets so far yet with BASIC 2 and the PETTESTER things don't even get past first base.
I checked the BASIC 2 ROMS again in the Willem for integrity. They're fine.
Philip Avery is coming over tomorrow with his scope, so we might be able to make some progress with both or either one of the boards.
In fact, the machine seems to be halted just after the splash screen. The keyboard does nothing and it's not typing "invisible" characters either. Pressing RETURN many times does not scroll the BASIC header off the screen. So, the spare board has a long way to go yet before back to a working state. Do the following observations offer any clues though?
1. With BASIC 4.0 it comes up with the BASIC message (showing full RAM) and READY but no prompt is displayed and the machine seems to lock at this point.
2. With BASIC 2 it doesn't even get that far: - it's a frozen garbage screen
3. With the PETESTER ROM it's also a frozen garbage screen
I've swapped and reswapped these ROMS quite a bit tonight and always with the above results. I'm intrigued to know why the BASIC 4 gets so far yet with BASIC 2 and the PETTESTER things don't even get past first base.
I checked the BASIC 2 ROMS again in the Willem for integrity. They're fine.
Philip Avery is coming over tomorrow with his scope, so we might be able to make some progress with both or either one of the boards.
Pet Rescue
Experienced Member
Well Tezza these pets are certainly playing up around the world!! they are probably going on strike due to being brought out of early retirement.:D
I had a VIC 20 lose its cursor and that was down to a duff 6522 VIA could be a starting point on your pet to check this I think its UB12.
I had to give up on one of my pets as it just had too many problems every time I found a faulty item and replaced it another raised it's ugly head. After many hours(months) and pounds it was time to call it a day.
On the basic ROM front for an unknown reason(probably down to age of the components) some programmed EPROM's went bad for no reason while others worked fine!
Keep up the good work it looks like you are on the right track. Hope you get to the bottom of your faults the end looks in sight!!
I had a VIC 20 lose its cursor and that was down to a duff 6522 VIA could be a starting point on your pet to check this I think its UB12.
I had to give up on one of my pets as it just had too many problems every time I found a faulty item and replaced it another raised it's ugly head. After many hours(months) and pounds it was time to call it a day.
On the basic ROM front for an unknown reason(probably down to age of the components) some programmed EPROM's went bad for no reason while others worked fine!
Keep up the good work it looks like you are on the right track. Hope you get to the bottom of your faults the end looks in sight!!
tezza
Veteran Member
I'm not sure the end is in sight quite yet, but thanks for the vote of confidence. I don't think it's the 6522 as I've swapped it out with the other board. It's possible both 6522s could be faulty but unlikely. I might check the associated circuitry though.
Tez
Tez
carlsson
Veteran Member
And as I wrote, a healthy 2001/3000 series PET (probably also true for various 4000 and 8000 series) should boot even when the 6522 and 6520 chips are pulled. It won't be useable but it should boot.
dave_m
Veteran Member
When you get a scope, check for the 60 Hz interrupt. Without it, there is no blinking cursor, keyboard scanning and tape control. The interrupt handler is in the "E" ROM and the source of the interrupt is the C7 PIA. There needs to be a 60 Hz video timing signal into the CB1 input (C7-18 ) to start things off. A transition on that signal is detected by the PIA and it issues an Interrupt Request (/IRQ). Have you got an extra 6520 PIA?
Eudimorphodon
Veteran Member
The ROM weirdness almost HAS to be a funky socket. For the PET tester to run in some capacity almost literally the only parts of the machine that need to work are the CPU, the reset circuit, and enough of the data and address bus circuitry for it to read the kernal ROM socket. BASIC is a lot harder.
For the no keyboard / no prompt problem see my thread of doom page... I dunno, I'm on a mobile device. The problem is probably that you're not getting the 50/60hz interrupt that triggers the keyboard scan. Check the interrupt pin on the CPU for activity, and if it's lacking said interrupt originates at one of the 6520s. On my pet the missing interrupt ended up being a poorly seated chip.
Hey, at least you're getting signs of life.
For the no keyboard / no prompt problem see my thread of doom page... I dunno, I'm on a mobile device. The problem is probably that you're not getting the 50/60hz interrupt that triggers the keyboard scan. Check the interrupt pin on the CPU for activity, and if it's lacking said interrupt originates at one of the 6520s. On my pet the missing interrupt ended up being a poorly seated chip.
Hey, at least you're getting signs of life.
tezza
Veteran Member
Thanks for those tips. Philip Avery will be here in a few hours with his scope so we can check those things out.
I wouldn't expect it to be one of the 6520s simply because I've swapped the set between the two boards and get the same symptom. If it was the 6520 one must have failed on each board. Unlikely, but not impossible. I do have a spare 6522 but not a 6520.
Tez
I wouldn't expect it to be one of the 6520s simply because I've swapped the set between the two boards and get the same symptom. If it was the 6520 one must have failed on each board. Unlikely, but not impossible. I do have a spare 6522 but not a 6520.
Tez
tezza
Veteran Member
Ok, progress report. Here is what Philip Avery and I found. We didn't even need to use the scope!
1. First the spare "original" board, which got to the splash screen (no cursor) with BASIC 4, garbage screen with BASIC 2 and garbage screen with the PET TESTER ROM
The problems have been identified on this board. There were two issues, both of them involving sockets (you guys were right).
(a) The hole for pin 8 on the E000 ROM (UD 8 ) socket was dodgy. With the BASIC 2 ROM, pin 8 was not making contact with the socket. With the BASIC 4 ROM the EPROMS legs were long enough for a connection to be made. This is why BASIC 2 didn't get as far as BASIC 4.
(b) The hole for pin 20 for the 6520 (PIA) at UC7 wasn't making contact with the pin. Hence the chip was't getting power (thanks for the hint here Dave). This is why BASIC 4 didn't have a cursor or keyboard.
(c) The PET TESTER adaptor has quite short pins and the top part of a couple of the pins had jumpers solded to them. It just wasn't getting far enough down in the socket to make contact. (It did on the other board however).
So, Successful diagnosis. We jumpered the pins to where they should go and have a fully working machine. I've got two sockets to replace though.
2. Board number two. The replacement (Anders) board. No garbage but a few graphic characters and a frozen screen. PET TESTER works fine on this board. ROMS definitely OK.
Not so lucky with this one. ROM sockets check out as OK. 6520s removed make no difference. Philip and I measured the signals on the CPU. It was a little strange that all the address lines were high. Here is what we found with a logic probe:
A0-A15 = All high
Sync = low
R/W= H
IRQ = L (but HI when the PIAs are removed)
D0 = L
D1 = H
D2 = H
D3 = L
D4 = L
D5 = H
D6 = H
D7 = H
On the ROMS, the CS on the kernal was L, on the other ROMS it was H.
We are a bit stuck now. Do these readings tell anyone anything?
Tez
1. First the spare "original" board, which got to the splash screen (no cursor) with BASIC 4, garbage screen with BASIC 2 and garbage screen with the PET TESTER ROM
The problems have been identified on this board. There were two issues, both of them involving sockets (you guys were right).
(a) The hole for pin 8 on the E000 ROM (UD 8 ) socket was dodgy. With the BASIC 2 ROM, pin 8 was not making contact with the socket. With the BASIC 4 ROM the EPROMS legs were long enough for a connection to be made. This is why BASIC 2 didn't get as far as BASIC 4.
(b) The hole for pin 20 for the 6520 (PIA) at UC7 wasn't making contact with the pin. Hence the chip was't getting power (thanks for the hint here Dave). This is why BASIC 4 didn't have a cursor or keyboard.
(c) The PET TESTER adaptor has quite short pins and the top part of a couple of the pins had jumpers solded to them. It just wasn't getting far enough down in the socket to make contact. (It did on the other board however).
So, Successful diagnosis. We jumpered the pins to where they should go and have a fully working machine. I've got two sockets to replace though.
2. Board number two. The replacement (Anders) board. No garbage but a few graphic characters and a frozen screen. PET TESTER works fine on this board. ROMS definitely OK.
Not so lucky with this one. ROM sockets check out as OK. 6520s removed make no difference. Philip and I measured the signals on the CPU. It was a little strange that all the address lines were high. Here is what we found with a logic probe:
A0-A15 = All high
Sync = low
R/W= H
IRQ = L (but HI when the PIAs are removed)
D0 = L
D1 = H
D2 = H
D3 = L
D4 = L
D5 = H
D6 = H
D7 = H
On the ROMS, the CS on the kernal was L, on the other ROMS it was H.
We are a bit stuck now. Do these readings tell anyone anything?
Tez
dave_m
Veteran Member
Tez,
I don't know why the machine seems to be struck, but in that state it seems to be reading the very last location of ROM memory. for BASIC 2 ROMs, location $FFFF is $E6.
This suggests it was reading the interrupt vector ($E61B) when it got stuck. Check the PIA C7 again for open signals especially the Phase 2 clock, etc.
tezza
Veteran Member
Thanks for that analysis Dave.
Just for my own educational purposes, you deduced this from the fact that all the address lines were ALL high (hence address $FFFF), yes? And the pair of bytes taken together (1B at FFFE (least significant byte) then E6 at $FFFF (most significant byte)) points to a memory location containing the interrupt vector ($E61B)? Is that how it's figured?
If so, I may be starting to understand this stuff?
Can you just elaborate on what you mean by "open signals" in this context?
The symptom is the same whether there is a chip in C7 or not. From reading back, even if the chip is missing it still should get to the splash screen yes?
Tez
Eudimorphodon
Veteran Member
I'm wondering if it's possible that some combination of stuck address lines could lead to what you're seeing? That's goofy. The PETTESTER code only occupies about the first 520 bytes of the ROM, so... I don't know. It's hard to think of a stuck line that would let the PET properly read the startup vector and jump to the code in that ROM only to fail when the CPU needs to read the vector two bytes higher.
Admittedly I don't know why it'd be freezing on the reset vector without the 6520 present to prod the CPU into reading that location. Is it possible something in the BASIC/Kernel initialization code reads those locations in order to manually jump through the interrupt handler once (which the designers thought might change location?) in order to perform some hardware sanity check?
(Just for the record, PETTESTER disables interrupts in the first byte of code and leaves it off. So if some spurious short is causing the CPU to get stuck handling an interrupt you might not see it with PETTESTER.)
Admittedly I don't know why it'd be freezing on the reset vector without the 6520 present to prod the CPU into reading that location. Is it possible something in the BASIC/Kernel initialization code reads those locations in order to manually jump through the interrupt handler once (which the designers thought might change location?) in order to perform some hardware sanity check?
(Just for the record, PETTESTER disables interrupts in the first byte of code and leaves it off. So if some spurious short is causing the CPU to get stuck handling an interrupt you might not see it with PETTESTER.)
dave_m
Veteran Member
In the 6502 computer, the Interrupt Vector is stored in ROM at FFFE (low byte address) and FFFF (high byte) so when an interrupt occurs, the CPU fetches the vector and loads it into the program counter. Therefore, for the BASIC 2 PET, the start of the interrupt handler routine is at $E61B.
I just meant there might be more bad contacts in the C7 socket causing intermitent or open circuit connections.
Well, there goes that theory, with no C7, there should be no Interrupt Request.
tezza
Veteran Member
Even though I've measured continuity twice, I still suspect a ROM socket on this second board. Consider the evidence.
1. The problem reared its head when I started swapping ROMS
2. When I first exchanged the exisiting BASIC 2 ROMs with my new set of BASIC 4 ROMS, I got a lock up. Reseating cured it. Although I can't remember specifically, it MAY have been the same screen display (I need to take notes of these things when they happen).
3. The PET Tester comes up ok, which means the basic addressing/CPU stuff is working.
4. It's not because of a faulty PIA because the lock up still occurs even when these are gone.
Here is a theory. When I've measured continuity I've done so with the ROMS inserted and measuring off the pins. Perhaps the extra pressure on the pins from the probe makes a connection that is not there when the probe is absent?
Tonight if I get some time I'm going to look at the E000, C000 (and D000) sockets again very closely indeed.
Tez
1. The problem reared its head when I started swapping ROMS
2. When I first exchanged the exisiting BASIC 2 ROMs with my new set of BASIC 4 ROMS, I got a lock up. Reseating cured it. Although I can't remember specifically, it MAY have been the same screen display (I need to take notes of these things when they happen).
3. The PET Tester comes up ok, which means the basic addressing/CPU stuff is working.
4. It's not because of a faulty PIA because the lock up still occurs even when these are gone.
Here is a theory. When I've measured continuity I've done so with the ROMS inserted and measuring off the pins. Perhaps the extra pressure on the pins from the probe makes a connection that is not there when the probe is absent?
Tonight if I get some time I'm going to look at the E000, C000 (and D000) sockets again very closely indeed.
Tez
tezza
Veteran Member
Nope, the ROM sockets check out as ok. It's a mystery.
At least I now have a working PET. I'm back to where I was when I started to fix the spare board except that board IS now fixed and the was-working board is now the non-working one!
Oh well. I'll give it a break for a while. If there is ever a never version of the PET TESTER ROM let me know. I volunteer to be check it out!
Tez
At least I now have a working PET. I'm back to where I was when I started to fix the spare board except that board IS now fixed and the was-working board is now the non-working one!
Oh well. I'll give it a break for a while. If there is ever a never version of the PET TESTER ROM let me know. I volunteer to be check it out!
Tez
Eudimorphodon
Veteran Member
Keep your fingers crossed I haven't made things *worse* by washing my 4032's motherboard. (I'm going to let it dry another couple days before I find out.) How much motivation I'm going to have to persevere on that might have a directly inverse relation to how many sparks I get hit in the face with next time I dive into my poor sick PET. :^/
tezza
Veteran Member
Well, I've fired up a few boards now after washing. No sparks have flown so far.
Yes, just how long one perservers with these problems is sometimes a difficult decision. There is that old saying about flogging a dead horse. The frustrating thing about vintage computers is that we KNOW we CAN fix them. Almost always. Most of us have the skills and can scrounge the parts for somewhere. The problem is finding out WHAT'S wrong. Tough to do, especially when there might be several issues. This is the frustration: Usually an easy fix but difficult to find out just what TO fix.
My PET 3032 is now up and running with the original (was-spare) board. I should be happy. I don't have a second PET case and PSU so there is no reason to have a working second board anyway. But the baffling nature of the problem is really, really bugging me....*mutter, grumble*. I'm now ultra-curious as to what it could be.
A voice inside my head says "Let it go Tez, just let it go..."
Tez
Yes, just how long one perservers with these problems is sometimes a difficult decision. There is that old saying about flogging a dead horse. The frustrating thing about vintage computers is that we KNOW we CAN fix them. Almost always. Most of us have the skills and can scrounge the parts for somewhere. The problem is finding out WHAT'S wrong. Tough to do, especially when there might be several issues. This is the frustration: Usually an easy fix but difficult to find out just what TO fix.
My PET 3032 is now up and running with the original (was-spare) board. I should be happy. I don't have a second PET case and PSU so there is no reason to have a working second board anyway. But the baffling nature of the problem is really, really bugging me....*mutter, grumble*. I'm now ultra-curious as to what it could be.
A voice inside my head says "Let it go Tez, just let it go..."
Tez
tezza
Veteran Member
Ok, solved it!
I was still suspicious of those sockets. After all the problem arose when I swapped out the ROMs and the CPU. Last night I concentrated on the ROM sockets. Tonight, I focussed on the CPU socket. I thought I'd probe the two 74LS244s at the other end of the CPU address lines. I want to see if they connected up ok and that the logic was right. Maybe one of these logic chips had gone bad.
The logic was sensible until I came to Input Pin 11 (A15) on the 74LS255 at B3. It was showing no signal with the logic probe? Huh? I did a connectivity test between this pin and the CPU pin it was suppose to be connected to (pin 25). No connection.
Well, not quite. I found if I pushed the (socketed) CPU pin with the probe into towards the chip itself, there was connectivity. If I relaxed, there was none. Keeping the pressure on the pin with the probe I switched on. There ya go...BASIC splash screen!
Diagnosis!
I thought about replacing the socket but decided against it. Too easy to lift a trace or two. Instead I just soldered a short jumper from the CPU pin to a solder pad on the board which connects to pin 11 of the 74LS244. It looks neat enough.
So there it is. On both boards these latest problems WERE the sockets after all. I've repaired both boards. The PET is chugging along beside me here reading and writing software out to tape (I'm cloning my cassette of programs).
Thanks for the help as always guys. Mystery solved. Now I'm content.
Tez
I was still suspicious of those sockets. After all the problem arose when I swapped out the ROMs and the CPU. Last night I concentrated on the ROM sockets. Tonight, I focussed on the CPU socket. I thought I'd probe the two 74LS244s at the other end of the CPU address lines. I want to see if they connected up ok and that the logic was right. Maybe one of these logic chips had gone bad.
The logic was sensible until I came to Input Pin 11 (A15) on the 74LS255 at B3. It was showing no signal with the logic probe? Huh? I did a connectivity test between this pin and the CPU pin it was suppose to be connected to (pin 25). No connection.
Well, not quite. I found if I pushed the (socketed) CPU pin with the probe into towards the chip itself, there was connectivity. If I relaxed, there was none. Keeping the pressure on the pin with the probe I switched on. There ya go...BASIC splash screen!
Diagnosis!
I thought about replacing the socket but decided against it. Too easy to lift a trace or two. Instead I just soldered a short jumper from the CPU pin to a solder pad on the board which connects to pin 11 of the 74LS244. It looks neat enough.
So there it is. On both boards these latest problems WERE the sockets after all. I've repaired both boards. The PET is chugging along beside me here reading and writing software out to tape (I'm cloning my cassette of programs).
Thanks for the help as always guys. Mystery solved. Now I'm content.
Tez
Nama
Veteran Member
Well done Tezza!