• Please review our updated Terms and Rules here

Unusual PET Dynamic Board "Fault"

Hugo Holden

Veteran Member
Joined
Dec 23, 2015
Messages
4,771
Location
Australia
I bought a dynamic PET board on ebay. It was cosmetically clean looking, which is what I like because, normally, I can fix the hardware issues. Call this board mobo B. But this one had a very odd fault, perhaps better called a "borderline condition".

I got it as a spare for the PET computer I have.

I had already cloned all of the ROMs in my working PET call the board in this PET mobo A.

I had the ROM set sitting there and they were all tested and known to work in this PET computer.

Most of them were the TMS2532 types, because these work as drop in replacements for the 6332 ROMs and they are easy to program with the readily available & cheap GQ-4x programmer.

Except for the Edit ROM and the Character ROM types, these are replaced with a 2716 UV eprom , which is also easy to program in the GQ-4x programmer too.

Therefore, I had a good set of ROM's that I had verified in my working pet computer.

I put mobo B into my PET computer to test it and repair it and this is where the fun began.

I will explain the sequence of events:

Mobo B was malfunctioning. So I inspected the power supply voltages. Initially I found that one of the blue 10uF 25V Tant capacitors filtering the +12V line had shorted out. I replaced all of the blue 10uF 25V tants on the pcb.

After that, as is often the case, with faulty PETs, there was a scrambled screen of characters appeared on the CRT This is the "PET thing" when many things go wrong.

I decided a smart move would be to replace all the ROM's with the duplicate set. The rationale would be; if that cured it, I could simply re-fit the old ones, one at a time, until the fault re-appeared (the best laid plans of Mice & Men in this case).

When I did this, the signs changed. Now, when the computer booted, the screen was blank. Though by turning up the VDU's brightness control, the scanning raster was there, indicating normal H and V drive pulses.

I thought, hmm.... what to do next ? So I started removing the PIA's because its easy as they are also in sockets. As soon as I removed UC7 (the keyboard PIA). Immediately the computer booted to BASIC, but without the cursor. This appears to be normal that if UC7 is not present the cursor vanishes. Later it turned out that both the BASIC 2 ROMs which came on Mobo B were faulty (corrupted) and required replacing and the edit ROM was the wrong type. So the dead parts count at this point was two BASIC ROMs, one PIA and one capacitor. Not bad for a board of this age.

Luckily i had some spare 6520 PIA's on hand (courtesy of my longstanding spare parts disease) I had bought these as spares for my AIM 65 computer.

The cursor re-appeared with a replacement UC7, 6520 PIA, and the computer started running normally....... except for a very odd fault, see attached video link, showing the screen data bouncing around vertically. The display bounced vertically for some seconds immediately after turn on (computer power up), and every time any keyboard key was pressed. But after some minutes this fault completely cleared.


After some time, I determined that if I replaced the 2716 Character ROM I had made, with the original Mos Character ROM, the problem vanished. So, as an experiment, I fitted the 2716 character ROM to the known good mobo A, and found that it worked perfectly in mobo A.

Therefore, I had a situation where the 2716 character ROM, was causing some sort of problem in mobo B and not mobo A. And it was a marginal condition, in that after 10 to 15 minutes after turn on, the problem vanished. What could it be that made mobo B different from mobo A ? But more to the point, how could some quality of the character ROM cause the unusual vertical instability seen on the VDU ?

Luckily, I had been doing some previous research on the /INIT line in the computer. And I had also found, that due to the design of the 9" PET VDU, the slightest disturbance in the timing or amplitude of the Vertical drive signal to the VDU results in a small series of characteristic damped oscillations in the vertical scan. (These can also be readily seen if the V height control is adjusted in the VDU). It is because of a positive feedback loop in the VDU's vertical scan amplifiers, just below the threshold to cause continuous oscillations.

In any case I figured that there was a disturbance in the V drive signal to the VDU, to cause the vertical bouncing (seen in the video)

Initially I confirmed that the 2716 character ROM was causing a disturbance in the /INIT line. It turns out that pin 21 ( CS3) of the character ROM UF10 is not tied directly high, but tied to the /INIT line, which is pulled high by a 1K resistor. Somehow it (the 2716 ROM) was either injecting a transient onto this /INIT line or altering it in some way. On testing, much to my surprise I found that the /INIT line, with the original MOS Character rom sits at close to the 5V rail. With the 2716 though, at least the IC's I have, the /INIT line is dragged down to just under 2 volts, making the INIT line vulnerable to transients. This results in disturbances of the clock pulses to the CPU and the state machine that generates the V drive pulses. This causes the vertical bouncing.

I confirmed this was the case, by shorting out the 1k pullup resistor after the computer had started. Also by an experiment, disconnecting pin 21 of UF10 and tying it directly high, which also cured the problem.

Then I got to wondering about the 1k pullup resistor. I paralleled a 33k resistor with it, reducing the value just a tad to around 970 Ohms, the problem vanished. That is how marginal it was, easily explaining why the 2716 ROM could work apparently normally in one pcb mobo A but not in mobo B. However an experiment shows that when the 2716 is in position UF10, to get the /INIT line, to close to +3V requires that the 1k pullup resistor is changed to a 390 Ohm.

Pin 21 on a 2716 is the Vpp programming voltage input. In read mode it it supposed to be tied to + 5V. However, when it is tied via the 1k pullup resistor it appears capable of dragging the voltage down below 2V.

I found the simplest thing to do on the PET mobo was to merely change the 1k Pullup resistor to on the / INIT line to 820 Ohms and this fixes this unusual problem when the Character ROM is replaced with a 2716. It would be better though to simply wire pin 21 to +5V but that would mean cutting a pcb track that I am not fond of.

Probably it would have been better if Commodore tied pin 21 of UF10 to +5V and not /INIT. For example, no problems occur using the 2716 in the Edit ROM position of UD8, in that case they tied pin 21 directly to +5v.

So, this is a cautionary tale about using a substitute 2716 ROM for the character ROM UF10. It may work fine in some boards, not in others and it pays to check if it (the particular 2716) drags down the voltage on the /INIT line, easily checked with the meter.
 

Attachments

  • CHARROM.jpg
    CHARROM.jpg
    66.8 KB · Views: 8
Last edited:
Hugo,

An excellent write up (as usual) and, bizarrely, something I have come across before!

This is exactly that - when is a chip select line not a chip select line - when it is the Vpp pin!

This fault manifested itself on another PET many years ago and the replacement EPROM was dragging down the pull-up line (that is what the /INIT line actually is if I remember correctly - it is a pull-up resistor).

I pointed this issue out to the OP of the faulty PET. They just bent the pin of the EPROM out and strapped it to VCC - problem solved. Not a 'pretty' solution, but...

In fact, come to think of it, it may even have been the character generator as well?

Dave
 
Interesting... in my other hobby of playing with Arcade PCBs from the 1980s I have seen similar with some ebay ST M2716-1F1 21V devices.

Essentially if you don't pull up pin 21 hard you get spurious results. The solution for me was to lift the leg and wire it to 5V

 
My spare PET board Mobo B still has one remaining intermittent fault, possibly not cured, that I am working on, I'm not sure if it is solved yet. It comes on randomly about 3 to 5 minutes after turn on, but not always.

It is somewhat like the scene from the movie Ghost were the computer starts typing for itself.

Typically the cursor suddenly returns home, on its own. One other peculiarity is that its blinking rate appears to double at times. Then, after this, strings of numbers are typed as though somebody is working the keyboard, somewhat spooky, perhaps the machine is trying to give me next week's Lotto numbers.

Then, occasionally the cursor takes off and creates a diagonal line, like the line of 7's seen in the attached photo. Nearly all the screen data (characters) in the attached photo there were put by the fault, but if you look you could see the remains of the word READY and 10 FOR X = where I was just starting to type in a program and later the cursor returned there and partially over-wrote it. I'm pretty sure at one point I saw the cursor return home when I had the keyboard unplugged, so I don't think it is a keyboard issue.

Since the PIA UC7 was defective and replaced, I tried replacing it again in case I had a defective IC, but it is not that. So I replaced the other 6520 PIA UC6. So far, since doing this, this weird fault has not returned after over an hour...yet. But it could still be there, only time will tell.

Is it even plausible that a defective UC6 could cause this ? If it was plausible I might be more convinced I have fixed it. If it appears to stay fixed I will put the original UC6 PIA back in and see if the fault returns and do this a few times to convince myself it is fixed. It is very tempting to think an intermittent fault is fixed, when it is not, so I take a lot of convincing.

Any suggestions on the possible cause? I'm thinking more likely one of the logic IC's is intermittent, I have seen this before where the output of a TTL IC can come and go randomly, it could be a task to find because the fault is fairly random.
 

Attachments

  • Random.jpg
    Random.jpg
    184.5 KB · Views: 14
I
Hugo

No 3, 6 or 9.

What happens if you do an actual key board input while it is in this mode?

Fred
It works normally. Though that typed in info can get written over later if the cursor returns to those places.

What does No 3,6 or 9 mean ?
 
I will have to check the source code for the BASIC - but it is just possible that the IEEE488 port is active normally. If the IEEE488 PIA (UC6) becomes faulty - this could be the result (but this is only a theory at the moment of course).

>>> What does No 3,6 or 9 mean ?

They were looking at the characters that were generated on the screen and observed that no numbers 3, 6 or 9 appeared.

Dave
 
I will have to check the source code for the BASIC - but it is just possible that the IEEE488 port is active normally. If the IEEE488 PIA (UC6) becomes faulty - this could be the result (but this is only a theory at the moment of course).

>>> What does No 3,6 or 9 mean ?

They were looking at the characters that were generated on the screen and observed that no numbers 3, 6 or 9 appeared.

Dave
Interesting, thanks.

It will be a day or two before I can soak test the PET.

On the other issue with pin 21 of the Character ROM, looking at the pcb it leads to an easy to get at via. so one option would be to de-solder that via and run a small drill through it, only just big enough to remove the plated through hole , then tie pin 21 tp +5v with a small link wire in the socket pins on the rear of the pcb. This way the board could accommodate the original ROM or the 2716. And later, that mod could be reversed if anyone wanted with a tiny link wire to re-establish the plated through hole connection of the via.
 
I have confirmed the intermittent fault "self typing screen characters" is due to a faulty 6520 PIA IC in location UC6.

I did this by running the computer without UC6 in the socket for 4 hours. No problem. I re-fitted the original 6520 IC, problem occurs within 5 minutes.

After this I replaced UC6 with a known good 6520 PIA , 4 hrs soak test no problem.

Returned the defective UC6 to its socket, problem returns in 5 minutes.

So this is a very weird case of UC6, the PIA for the IEEE-488 port, being faulty in a way where it can spontaneously self type screen data.

This may well be one of the most unusual PET computer faults recorded.

It is such an oddball IC fault that I wasn't sure whether to throw this IC away, or not, so I labelled it "Ghost Writer". Normally DUD IC's I mark them immediately with red varnish and throw away later. Suspect IC's a put a dot of yellow varnish on them. It pays to do this sort of thing or you can get mixed up with many on the bench.

I also wanted to try to figure out what it was that caused both of the two BASIC roms on my spare dynamic PET board to be defective. So I put them in the reader. One must be grossly damaged because every cell is FF. The other one has some intact data, but has regularly repeating blocks of byte values 00, that should no be there, I compared the .bin files with the Zimmers.

So now I have a fully working Dynamic board as a spare for my PET computer.

I have attached the photo of what the faulty UC6 (6520 PIA) does to a screen, where it was previously completely plotted with X's.

(I decided to stock up on some PIA IC's, it looks like the 6520 and the Motorola 8520 are getting more rare these days. And if the type/variant was used in the Apple-1 they cost a small fortune).
 

Attachments

  • Ghost3.jpg
    Ghost3.jpg
    157.6 KB · Views: 9
Last edited:
So this is a very weird case of UC6, the PIA for the IEEE-488 port, being faulty in a way where it can spontaneously self type screen data.

This may well be one of the most unusual PET computer faults recorded.
Well Done!
I have never observed an I/O chip outputting data on bus without being chip selected. It was somehow interfering with the screen refresh cycles.
Also another 6520 substitute is the Motorola 6821.

How did the idea to remove the the IEEE PIA pop into your mind?

I am awarding you a another prestigious PET Detective Award!
 
>>> How did the idea to remove the the IEEE PIA pop into your mind?

Post #7...

I have seen a similar thing before - but I am still not sure why it occurs.

Dave
 
>>> How did the idea to remove the the IEEE PIA pop into your mind?

Post #7...

I have seen a similar thing before - but I am still not sure why it occurs.

Dave
I missed your mention of a possible issue with the IEEE 6520. I wonder how the 6520 can output data on the wrong phase of the Phase 2 clock??

Anyway, yet another PET Detective Award goes to our daver2. I'm loosing count of how many you won!
 
We'll share it. I put forward the theory, and Hugo worked through the problem in practice.

I have just come back from a walk in the rain. It is the UK after all!

One theory I have is that the IEEE PIA chip select logic is broken. Let's say an active high chip select line has somehow gone faulty internally and that specific line is permanently enabled, irrespective of the address line state to which it is wired. Is there a combination of addresses whereby both the IEEE PIA and the keyboard PIA could be enabled at the same time given this fault scenario?

Given this scenario, when BASIC addresses the keyboard PIA and polls the keyboard, it will get corrupted data - and the two PIAs could interact. The IEEE PIA will still (however) be addressed correctly at its own address.

Just a thought. Hugo has quite clearly identified the fault is with the PIA itself.

Dave
 
Well Done!
I have never observed an I/O chip outputting data on bus without being chip selected. It was somehow interfering with the screen refresh cycles.
Also another 6520 substitute is the Motorola 6821.

How did the idea to remove the the IEEE PIA pop into your mind?

I am awarding you a another prestigious PET Detective Award!

In essence I found it by chance and some guesswork. Since one PIA was faulty and there was no boot & no cursor, I wondered about the other, they looked identical and same date code. So to eliminate variables I left UC6 out and also tried other spare IC's in its place.

I could see that UC7 was responsible for the Cursor, because when that was removed, it booted but with no cursor. And the cursor was behaving as though something was interrupting it, its flashing rate became erratic too, so it did wonder if it was being interfered with by the other PIA UC6 or some other IC on the bus. But I was not sure if it was even plausible that the fault could be caused by a defective UC6, which is why I asked the question.

So Daver2 should get the Pet Detective award for this one, for figuring out a mechanism by which this fault could occur and that it was plausible that UC6 could do it. Because with that information , it would have made UC6 a suspect for investigation and led to the same result. A much better method than dumb luck.

It was important to test the machine in 3 ways though, UC6 absent, UC6 present, and replacement UC6. Because it could have been possible that the original UC6 was ok but some associated IC defective/intermittent.

The original defective UC6's problem is definitely thermal , it takes about 5 to 10 minutes for it to heat up before it malfunctions and becomes the "Ghost Writer".

So in summary to repair this Dynamic PET board required:

Both defective BASIC ROMs replaced.
Incorrect Edit ROM replaced (the one in it was for a different keyboard)
Both PIA's replaced.
Shorted Blue Tant capacitor replaced (though I replaced them all, the blue ones, as the others would likely do it too).

I was lucky all the RAM was good and all tests passed on the PETTESTER , but I had spare IC's at the ready. I also could not find a problem when I ran the NOP generator, but I had done that after I loaded the entire new set of ROMs that I knew were ok and worked backwards later, replacing each ROM one at a time which is how I found the defective BASIC ROMs and confirmed the original Kernal ROM and the Character ROMs were good and stable that way. And along the way found that other issue with pin 21 of UF10 (Character ROM) needing to be tied high and not to /INIT, if it is a replacement 2716 type and not the original MOS ROM.

I still wonder what it was though that damaged both the original MOS BASIC ROMs ruining their data content. The board was pulled from a parted out PET. Usually these sorts of mask ROMs are very hardy and I worry about them less than UVeproms. Maybe somebody had damaged them in a ROM reader. When I read the original set of MOS ROMs in my working PET to save the files and create the replacement ROM set, I made a socket adapter which tied the programming pin so that it would be impossible to execute a programming attempt on them with the GQ-4x programmer, just in case I clicked on the program button in error. But I am super cautious and would hate to damage one of those original ROMs.
 
Last edited:
I still wonder what it was though that damaged both the original MOS BASIC ROMs ruining their data content. The board was pulled from a parted out PET. Usually these sorts of mask ROMs are very hardy...
Hugo, yes but we have seen a lot of bad NMOS ROMs in this forum lately. Maybe they are set to expire after 40+ years? <smile>
 
Hugo, yes but we have seen a lot of bad NMOS ROMs in this forum lately. Maybe they are set to expire after 40+ years? <smile>
Still, if that was the case, a pretty good innings. Better no doubt than the flash memory holding the usually non-available proprietary firmware in many appliances with with modern uP's, making their probability of lasting past 40 years, possibly zero or close to it.
 
Since I used up three of the spare ROMs I had made for my working PET to repair the spare Dynamic PET board, I decided I'd better replace those, because I had eaten into the spare parts pack.

I made duplicates again, so that I have the full set of spare ROMs again for the Dynamic PET, ready just in case of another fault finding episode. I think having the full set of known good working ROMs is one of the most powerful tools anyone can have when presented with a faulty PET to problem solve. Also I have Dave's PETTESTER ROM at the ready.

I really have to do a better job of making a NOP generator though, the first one I made was poor construction quality, even though it worked.

In any case I have used builder's aluminium sticky paper as a light shield for the UVeproms and clearly labelled them over that using black on clear labels from a Brother label machine. I labelled them for their pcb locations to avoid any mix ups fitting them to the pcb.

It does pay to accurately label ROMs (or anything where the object has a unique identity). Or later, mix ups will come back to haunt you.

Many years ago at Med School there was an examination station where the Prof of radiology asked the student to report an Xray.

When the student walked in and reported it with something like; AP chest film of a female as breast shadows visible, lung fields clear, mediastinum and Heart look normal. No rib fractures, costodiaphragmatic recesses normal, no fluid , no pneumothorax etc etc, the Prof would say.....are you finished? The student would say yes, it is a normal chest Xray. Then the Prof would say; I'm sorry you have failed.

If the student walked in and said; X-ray report on patient (looking at the film label) Marilyn Monroe (yes it was her film) date of birth etc, the Prof would interrupt and say; you have passed please leave.

For the failed students the Prof explained there is no point in reporting on any lab test, investigation or scan, if you have not correctly identified the patient first. (a very good point because all Hell breaks loose if there is an error there)

Of course many students who failed this test walked away somewhat dejected that they missed the identity of the film. But at least they never forgot the important lesson.
 

Attachments

  • PETROMS.jpg
    PETROMS.jpg
    268.7 KB · Views: 5
Last edited:
Since I used up three of the spare ROMs I had made for my working PET to repair the spare Dynamic PET board, I decided I'd better replace those, because I had eaten into the spare parts pack.

I made duplicates again, so that I have the full set of spare ROMs again for the Dynamic PET, ready just in case of another fault finding episode. I think having the full set of known good working ROMs is one of the most powerful tools anyone can have when presented with a faulty PET to problem solve. Also I have Dave's PETTESTER ROM at the ready.

I really have to do a better job of making a NOP generator though, the first one I made was poor construction quality, even though it worked.

In any case I have used builder's aluminium sticky paper as a light shield for the UVeproms and clearly labelled them over that using black on clear labels from a Brother label machine. I labelled them for their pcb locations to avoid any mix ups fitting them to the pcb.

It does pay to accurately label ROMs (or anything where the object has a unique identity). Or later, mix ups will come back to haunt you.

Many years ago at Med School there was an examination station where the Prof of radiology asked the student to report an Xray.

When the student walked in and reported it with something like; AP chest film of a female as breast shadows visible, lung fields clear, mediastinum and Heart look normal. No rib fractures, costodiaphragmatic recesses normal, no fluid , no pneumothorax etc etc, the Prof would say.....are you finished? The student would say yes, it is a normal chest Xray. Then the prof would say, I'm sorry you have failed.

If the student walked in and said; X-ray report on patient (looking at the film label) Marilyn Monroe (yes it was her film) date of birth etc, the prof would interrupt and say; you have passed please leave.

For the failed students the Prof explained there is no point on reporting on any lab test, investigation or scan, if you have not correctly identified the patient first. (a very good point because all Hell breaks loose if there is an error there)

Of course many students who failed this test walked away somewhat dejected that they missed the identity of the film. But at least they never forgot the important lesson.
Building a NOPPER is a bit of a rite of passage...

Capture6502NOP.PNG

I'm not sure you would approve of this one since it's designed for turned pins... like you I don't really approve of putting round things into sockets (That's why my ROMulan RAMulator and other gadgets use Edge pins instead).

I haven't actually got around to assembling it yet... if you would like to try then I'll happily send you one!
 
Building a NOPPER is a bit of a rite of passage...

View attachment 1241201

I'm not sure you would approve of this one since it's designed for turned pins... like you I don't really approve of putting round things into sockets (That's why my ROMulan RAMulator and other gadgets use Edge pins instead).

I haven't actually got around to assembling it yet... if you would like to try then I'll happily send you one!

Thanks for that offer. I will keep it in mind.

There are some cases where it is ok to fit round pins into sockets, but they must be small diameter round pins about 0.45mm dia, and only into round machine pin sockets.

Winslow Adaptics made some adapters that carried these relatively fine caliber pins, but they seem harder to get now. I once bought a number of adapters for SOIC to DIL that had these very special fine pins. Interestingly they were pressed into the the pcb, not soldered.

If you have a look at the second to last page of this article, it shows the array of Averlogic memory IC's on these adapters, in a Video Freeze Frame machine I once designed (Inspired by an episode of Dr. Who as explained in the text)

 
Back
Top