daver2
10k Member
Yep, I was obviously thinking of the non CRTC machine and forgot to double check the machine I was posting on.
As Homer would say - Dooooo!
Dave
As Homer would say - Dooooo!
Dave
| VCF West | Aug 01 - 02 2025, | CHM, Mountain View, CA |
| VCF Midwest | Sep 13 - 14 2025, | Schaumburg, IL |
| VCF Montreal | Jan 24 - 25, 2026, | RMC Saint Jean, Montreal, Canada |
| VCF SoCal | Feb 14 - 15, 2026, | Hotel Fera, Orange CA |
| VCF Southwest | May 29 - 31, 2026, | Westin Dallas Fort Worth Airport |
| VCF Southeast | June, 2026 | Atlanta, GA |
-
Please review our updated Terms and Rules here
CBM 8032, working but not
- Thread starter BrianG
- Start date
BrianG
Member
Parts ordered!
BrianG
Member
daver2
10k Member
No - that wouldn't have happened anyhow. If there was a risk of letting the black smoke out of the box I would have included a warning in my post.
On the non-CRTC equipped PETs this is one repair technique I use - because the CPU doesn't do anything - so what you see on the screen should be pretty much random characters that are stored in the SRAM chips on power-up. Generally you can see if you have a stuck data bit (to a '1' or '0') because when you look at what characters are displayed you can note down what the HEX code is for the ASCII characters that are displayed and it will jump out that one of the bits is 'stuck'.
Unfortunately, the screen remains black on a CRTC-equipped PET with this technique because that is what happens when the CRTC is powered up. The CPU has to execute instructions to initialise the CRTC and get a display. Unfortunately, it has either cleared the screen at this point - or is just about to. Either way, the CPU (if it went rogue) could initialise the CRTC controller and then write strange patterns to the screen RAM - i.e. you demonstrate nothing…
Programming a new EPROM to let the CPU initialise the CRTC but not clear the video RAM and HALT after it has done that could work - but is a bit extreme for what we are trying to achieve…
I will have a new look at the video schematics and see what I can think of again.
Piggy-backing TTL chips can sometimes work - but in my experience I have little luck with this technique (unlike RAM). I generally prefer to analyse what is going on and try to deduce by logic what is faults.
Dave
On the non-CRTC equipped PETs this is one repair technique I use - because the CPU doesn't do anything - so what you see on the screen should be pretty much random characters that are stored in the SRAM chips on power-up. Generally you can see if you have a stuck data bit (to a '1' or '0') because when you look at what characters are displayed you can note down what the HEX code is for the ASCII characters that are displayed and it will jump out that one of the bits is 'stuck'.
Unfortunately, the screen remains black on a CRTC-equipped PET with this technique because that is what happens when the CRTC is powered up. The CPU has to execute instructions to initialise the CRTC and get a display. Unfortunately, it has either cleared the screen at this point - or is just about to. Either way, the CPU (if it went rogue) could initialise the CRTC controller and then write strange patterns to the screen RAM - i.e. you demonstrate nothing…
Programming a new EPROM to let the CPU initialise the CRTC but not clear the video RAM and HALT after it has done that could work - but is a bit extreme for what we are trying to achieve…
I will have a new look at the video schematics and see what I can think of again.
Piggy-backing TTL chips can sometimes work - but in my experience I have little luck with this technique (unlike RAM). I generally prefer to analyse what is going on and try to deduce by logic what is faults.
Dave
dave_m
Veteran Member
I agree but since the signals seem stuck high, there is a chance of seeing a change. Any change at all would indicate that the part be replaced. After the RAM piggyback tests, I still don't have a feel for the real problem.
I generally don't (if ever) piggyback a logic chip unless I've already narrowed down to it. By then though, I've usually discovered the logic error in the chip. RAM chips are a different story, because the truth table is harder to work out in real time, obviously.
BrianG
Member
Well I got sidetracked for a while, sorry about that. But I'm back and ready to fiddle around again. Soooo....
Looked over this thread, and my sorry photos, which were posted upside-down btw. Quick refresher...
Commodore CBM 8032, on powering up, hear the few beeps, then the screen goes to forward slash, space, forward slash, space, etc., all the way across. Made careful note of the screen with some painters tape, and after piggybacking the UC6 chip, the number of forward slashes doubles on each line, adding a final forward slash to the end of each horizontal row, but none added to the beginning. So all slashes and no spaces.
Piggybacked the UC4 while UC6 is piggybacked, all forward slashes. Piggybacking UC4 without UC6 piggybacked, alternating forward slashes and spaces.
Piggybacking the UB4 only, and every other character, which was a slash, just starts rapidly cycling through who knows what. It's kind of like they are dancing in place. Still has the alternating spaces though.
Piggybacked UB6 while UB4 is still piggybacked, and no change from UB4 only.
Piggybacked UB6 only, and back to alternating forward slash, space, all the way across the screen.
Piggybacked the UB3 only, and all of the slashes become plusses. This is still alternating with spaces.
Piggybacked UB3 and UB4, all slashes, alternating with spaces.
UB3 and UB4 and UB6, all slashes, alternating with spaces.
UB3 and UB6, plus, slash, plus, slash, etc., all the way across the screen.
Any thoughts?
Looked over this thread, and my sorry photos, which were posted upside-down btw. Quick refresher...
Commodore CBM 8032, on powering up, hear the few beeps, then the screen goes to forward slash, space, forward slash, space, etc., all the way across. Made careful note of the screen with some painters tape, and after piggybacking the UC6 chip, the number of forward slashes doubles on each line, adding a final forward slash to the end of each horizontal row, but none added to the beginning. So all slashes and no spaces.
Piggybacked the UC4 while UC6 is piggybacked, all forward slashes. Piggybacking UC4 without UC6 piggybacked, alternating forward slashes and spaces.
Piggybacking the UB4 only, and every other character, which was a slash, just starts rapidly cycling through who knows what. It's kind of like they are dancing in place. Still has the alternating spaces though.
Piggybacked UB6 while UB4 is still piggybacked, and no change from UB4 only.
Piggybacked UB6 only, and back to alternating forward slash, space, all the way across the screen.
Piggybacked the UB3 only, and all of the slashes become plusses. This is still alternating with spaces.
Piggybacked UB3 and UB4, all slashes, alternating with spaces.
UB3 and UB4 and UB6, all slashes, alternating with spaces.
UB3 and UB6, plus, slash, plus, slash, etc., all the way across the screen.
Any thoughts?
dave_m
Veteran Member
Brian,
it's very difficult to piggyback more than one chip at a time and keep good contact on all the pins.
You should install 18 pin sockets on the four video RAM chips locations (UC4,5,6,and 7). If PET is run with no RAM video chips installed, you should get a checkerboard characters on the screen. If you do not get the checkerboard, then RAM is not the problem. An easy test if video RAM on sockets.
it's very difficult to piggyback more than one chip at a time and keep good contact on all the pins.
You should install 18 pin sockets on the four video RAM chips locations (UC4,5,6,and 7). If PET is run with no RAM video chips installed, you should get a checkerboard characters on the screen. If you do not get the checkerboard, then RAM is not the problem. An easy test if video RAM on sockets.
BrianG
Member
@dave_m-
So I gather what you are saying is that the results that I got from piggybacking various combinations of chips makes no sense, likely because the chips were not in good contact with one another? The results were inconclusive, because something was wrong in the process? In the meantime I'll order some sockets and a solder sucker so I can try what you suggest.
Cheers!
So I gather what you are saying is that the results that I got from piggybacking various combinations of chips makes no sense, likely because the chips were not in good contact with one another? The results were inconclusive, because something was wrong in the process? In the meantime I'll order some sockets and a solder sucker so I can try what you suggest.
Cheers!
daver2
10k Member
Welcome back.
I was just re-reading the thread to pick up on where we had got to. No problem with removing the existing video RAM and replacing with sockets. It will help diagnose the next fault in the long run!
Whilst you are waiting I thought you could have a look at a few things to see if we can track the fault down a bit more locally whilst you are waiting for the components to arrive?
A bit of a recap (for my own sanity)...
The PET video consists of 25 lines of 80 characters. The characters on the line are numbered 0, 1, 2, 3, ... , 78 and 79 (i.e. the usual 'start counting from 0').
There are EVEN and ODD memory devices. The EVEN memory devices service character positions 0, 2, 4, ... , 76, and 78; whilst the ODD memory devices service positions 1, 3, 5, ... , 77 and 79.
Within each EVEN and ODD bank, the devices are split up into a high and low nibble.
Hence (on an 8032):
UC4 = EVEN bank LOW nibble.
UC5 = EVEN bank HIGH nibble.
UC6 = ODD bank LOW nibble and
UC7 = ODD bank HIGH nibble.
Now to the the characters [SPACE] and '/'. A [SPACE] = 0x20 (binary 0010 0000) and a '/' character = 0x2F (binary 0010 1111).
I have checked within the source code for BASIC 4 - and the clear screen code executes a BYTE write of $20 to each of the screen locations. On the assumption that the code clears at least one screen character position to a [SPACE] character, it should do them all - as it is the same code...
So, this leads me to one of the following:
1. A video RAM chip is faulty.
2. The WRITE to the video RAM is not occurring correctly.
3. The READ from the video RAM is not occurring correctly.
4. The control signal(s) driving one of the above actions is faulty.
The difference from a [SPACE] to a '/' is the lower nibble is not being set correctly (in fact it is defaulting to binary '1111' which smacks to me as the RAM output is potentially tristate and not driving the video data bus - or the value being written into the video RAM is faulty in a similar manner).
If the HIGH nibble was in error I would expect to see something other than [SPACE] or '/' being written - and the fault seems to be 100% consistent.
This leads me to suspect the problem lies with the LOW nibble circuitry. For the EVEN bank this would be UC4 (video RAM), UB3 (EVEN latch READ) and UB4 (EVEN WRITE); and for the ODD bank this would be UC6 (video RAM), UB8 (ODD latch READ) and UB6 (ODD WRITE).
You really need to narrow it down to the ODD or EVEN bank by ensuring that your painters tape trick is 100% accurate (i.e. is it truly the first character of the line that is a '/' (EVEN bank problem) or the second character of the line - or last if you like) that is a '/' (ODD bank problem).
After you have powered on the PET you could use an oscilloscope, logic probe or multimeter (in that order) to look at the output pins of the four video RAM chips. They should be '0010' for the high nibble and '0000' for the low nibble. I would expect you to see these values on the bank that is OK, bit see '1111' on the bank that is faulty.
If everything looks OK from the RAM - then the CPU wrote the correct values into the RAM (it is just not being displayed correctly). This would indicate the READ latch to be at fault.
If there is a problem from a video RAM chip, then look on pin 10 (READ / not WRITE pin) and ensure it is always '1' (being READ from).
If that is OK - it may be a RAM fault - try the piggyback trick (but double and triple check that all pins are making contact correctly to avoid you following a false trail).
See where that gets you...
Dave
I was just re-reading the thread to pick up on where we had got to. No problem with removing the existing video RAM and replacing with sockets. It will help diagnose the next fault in the long run!
Whilst you are waiting I thought you could have a look at a few things to see if we can track the fault down a bit more locally whilst you are waiting for the components to arrive?
A bit of a recap (for my own sanity)...
The PET video consists of 25 lines of 80 characters. The characters on the line are numbered 0, 1, 2, 3, ... , 78 and 79 (i.e. the usual 'start counting from 0').
There are EVEN and ODD memory devices. The EVEN memory devices service character positions 0, 2, 4, ... , 76, and 78; whilst the ODD memory devices service positions 1, 3, 5, ... , 77 and 79.
Within each EVEN and ODD bank, the devices are split up into a high and low nibble.
Hence (on an 8032):
UC4 = EVEN bank LOW nibble.
UC5 = EVEN bank HIGH nibble.
UC6 = ODD bank LOW nibble and
UC7 = ODD bank HIGH nibble.
Now to the the characters [SPACE] and '/'. A [SPACE] = 0x20 (binary 0010 0000) and a '/' character = 0x2F (binary 0010 1111).
I have checked within the source code for BASIC 4 - and the clear screen code executes a BYTE write of $20 to each of the screen locations. On the assumption that the code clears at least one screen character position to a [SPACE] character, it should do them all - as it is the same code...
So, this leads me to one of the following:
1. A video RAM chip is faulty.
2. The WRITE to the video RAM is not occurring correctly.
3. The READ from the video RAM is not occurring correctly.
4. The control signal(s) driving one of the above actions is faulty.
The difference from a [SPACE] to a '/' is the lower nibble is not being set correctly (in fact it is defaulting to binary '1111' which smacks to me as the RAM output is potentially tristate and not driving the video data bus - or the value being written into the video RAM is faulty in a similar manner).
If the HIGH nibble was in error I would expect to see something other than [SPACE] or '/' being written - and the fault seems to be 100% consistent.
This leads me to suspect the problem lies with the LOW nibble circuitry. For the EVEN bank this would be UC4 (video RAM), UB3 (EVEN latch READ) and UB4 (EVEN WRITE); and for the ODD bank this would be UC6 (video RAM), UB8 (ODD latch READ) and UB6 (ODD WRITE).
You really need to narrow it down to the ODD or EVEN bank by ensuring that your painters tape trick is 100% accurate (i.e. is it truly the first character of the line that is a '/' (EVEN bank problem) or the second character of the line - or last if you like) that is a '/' (ODD bank problem).
After you have powered on the PET you could use an oscilloscope, logic probe or multimeter (in that order) to look at the output pins of the four video RAM chips. They should be '0010' for the high nibble and '0000' for the low nibble. I would expect you to see these values on the bank that is OK, bit see '1111' on the bank that is faulty.
If everything looks OK from the RAM - then the CPU wrote the correct values into the RAM (it is just not being displayed correctly). This would indicate the READ latch to be at fault.
If there is a problem from a video RAM chip, then look on pin 10 (READ / not WRITE pin) and ensure it is always '1' (being READ from).
If that is OK - it may be a RAM fault - try the piggyback trick (but double and triple check that all pins are making contact correctly to avoid you following a false trail).
See where that gets you...
Dave
Last edited: