Commodore PET 4032/8050/3022

[SiriusHardware]

Nice job changing and checking UE3, onwards to UE1:

Check the +5V supply is present across UE1's supply pins (+Ve = 14, GND = 7)
Report the static states or waveform frequencies present on:

UE1 pin 1
UE1 pin 3
UE1 pin 5

UE1 pin 13
UE1 pin 11
UE1 pin 9

If you have waveforms present on pins 5 and 9 of UE1, then go further and scope UD1 pin 10 and state what you find there.

Elsewhere, go to UD5, check the voltage on its supply pins (+Ve = 14, GND = 7) and scope these pins:-

UD5 pin 11
UD5 pin 8

..and report what you find there.

[ortek_service]

Originally Posted by ScottishColin

OK - done some cleaning and re-checking and 3/39 look better now.

Here's the 6502 anomolies:

pin 37 has a good wave form but is a little low on voltage at 4.27V

Pin 2 sits high at 4.77V

Pins 7 and 9 have good waveforms, but are at 3.5V and the frequency on both swicthes between 333 and 500 Mhz.

Others to follw.

Colin.

Bear in mind that 74LS TTL 'High' level only needs to be just over 2V at the input and spec for outputs can be as low as 3.5V (Although the NMOS 6502 should be a bit-higher on its outputs, but not quite very-close to the supply-rails like CMOS often is).
Logic 'Low' tends to be somewhat closer to ground, with 74LS TTL (and NMOS?) outputs able to 'sink' much better than it can source current - Which they need to, as less 'noise-margin' for this, and so must be < 0.8V when low.

At higher-frequencies, the 'scope may also be giving some misleading levels - especially at 16MHz, where loss of odd-harmonics due to sampling-frequency / analogue bandwidth limits, may result in a more -sine-wave' looking reduced-amplitude waveform being observed.
'scope probe ground connection is also more important at higher frequencies,

So whilst you may get a good looking waveform on 1kHz cal output (Connecting a x10 ground lead as well is often necessary, for probe compensation / attenuator to function correctly), probing a much higher-frequency circuit can give ringing on high-levels / 'ground-bounce' on low-levels, if ground connection isn't kept fairly-short.

[ortek_service]

Originally Posted by ScottishColin

Replaced and now getting the correct readings out of UE3, but no chirps or screen activity yet.

UD2/6 and UD2/8 now give 1Mhz readings too.

Onto the next one I guess.

Colin.

Just a thought - Did you replace the 6520 PIA, you found to be faulty?

Whilst these don't have internal timers that the more-sophisticated 6522 'VIA' has (and so a Beeb computer must have system one present), I'm wondering if the ports on it are needed to control internal things and not just external ports?
- I presume your other now-working PET has one you can borrow (assuming it got socketed in that one, along with the many other IC's that got this done).

[SiriusHardware]

The 6520 in question is dedicated to the IEEE port and as such is not essential for the working of the machine but its absence could put the machine into a state where it is expecting 'something' from the 6520. It would be better to have one fitted than not fitted during the occasional optimistic switch-on.

With already two completely unrelated dead ICs in different parts of the machine, I am afraid this one may turn into another uphill slog like Colin's first PET with its inexplicable dead chip count.

[ScottishColin]

I suspect my error in using the wrong time/div settings as per post #170 wasn't helping me with my readings.

I have the probes set to x 10 so I think I'm good there.

Colin.

Originally Posted by ortek_service

Bear in mind that 74LS TTL 'High' level only needs to be just over 2V at the input and spec for outputs can be as low as 3.5V (Although the NMOS 6502 should be a bit-higher on its outputs, but not quite very-close to the supply-rails like CMOS often is).
Logic 'Low' tends to be somewhat closer to ground, with 74LS TTL (and NMOS?) outputs able to 'sink' much better than it can source current - Which they need to, as less 'noise-margin' for this, and so must be < 0.8V when low.

At higher-frequencies, the 'scope may also be giving some misleading levels - especially at 16MHz, where loss of odd-harmonics due to sampling-frequency / analogue bandwidth limits, may result in a more -sine-wave' looking reduced-amplitude waveform being observed.
'scope probe ground connection is also more important at higher frequencies,

So whilst you may get a good looking waveform on 1kHz cal output (Connecting a x10 ground lead as well is often necessary, for probe compensation / attenuator to function correctly), probing a much higher-frequency circuit can give ringing on high-levels / 'ground-bounce' on low-levels, if ground connection isn't kept fairly-short.

[ScottishColin]

I have a 6520 in from my other PET (they were socketed in that one) and 74164N donor chip in UE3 (replacements on order).

The only thing I don't regularly connect is the keyboard (I do every now and then just to see if it makes a difference).

Colin.

Originally Posted by ortek_service

Just a thought - Did you replace the 6520 PIA, you found to be faulty?

Whilst these don't have internal timers that the more-sophisticated 6522 'VIA' has (and so a Beeb computer must have system one present), I'm wondering if the ports on it are needed to control internal things and not just external ports?
- I presume your other now-working PET has one you can borrow (assuming it got socketed in that one, along with the many other IC's that got this done).

[ScottishColin]

More rust, less moss in this one. Let's see if it makes a difference.

Colin.

Originally Posted by SiriusHardware

The 6520 in question is dedicated to the
IEEE port and as such is not essential for the working of the machine but its absence could put the machine into a state where it is expecting 'something' from the 6520. It would be better to have one fitted than not fitted during the occasional optimistic switch-on.

With already two completely unrelated dead ICs in different parts of the machine, I am afraid this one may turn into another uphill slog like Colin's first PET with its inexplicable dead chip count.

[SiriusHardware]

For the most part, luckily, all we need to know is whether a signal is present or absent and whether it is the right frequency. I'm not too worried if we can't get a pretty looking picture of the 16MHz master clock as long as it is reaching the divider chain and the correct (divided) frequencies are coming out of the dividers.

The main problem we have encountered so far is a conflict between the frequency of the signal of interest and the sampling rate of the scope which at certain time / div settings has been too low, and we are aware of that now so hopefully we can work around it.

[ScottishColin]

UE1/14 - 5.02V
UE1/14 - 157mv

UE1 pin 1 - 1Mhz solid
UE1 pin 3 - 1Mhz but it 'blips' to 0 frequently; I can provide a video to help?
UE1 pin 5 - 1Mhz with blip

UE1 pin 13 - 1Mhz solid
UE1 pin 11 - 1 Mhz solid
UE1 pin 9 - 1 1hz solid

UD10 - 1Mhz waveform that then blips to 1.7Mhz

UD5/14 - 5.18V
UD5/7 - 157mv

UD5 pin 11 - 4.55V with no waveform
UD5 pin 8 - 1Mhz with the blip

Are the blips something to worry about? Pins 13/11/9/1 on UE1 give a rock solid 1Mhz

Colin.

Originally Posted by SiriusHardware

Nice job changing and checking UE3, onwards to UE1:

Check the +5V supply is present across UE1's supply pins (+Ve = 14, GND = 7)
Report the static states or waveform frequencies present on:

UE1 pin 1
UE1 pin 3
UE1 pin 5

UE1 pin 13
UE1 pin 11
UE1 pin 9

If you have waveforms present on pins 5 and 9 of UE1, then go further and scope UD1 pin 10 and state what you find there.

Elsewhere, go to UD5, check the voltage on its supply pins (+Ve = 14, GND = 7) and scope these pins:-

UD5 pin 11
UD5 pin 8

..and report what you find there.

[SiriusHardware]

UD10 - 1Mhz waveform that then blips to 1.7Mhz

I'm assuming you meant pin 10 of UD1 here. I'm not too unhappy with what we have so far if we have activity all the way to the output of the UD10 gate. It may require further analysis.

The operation of the gates around UD5 is address-dependent so I think the next thing we need to do is to drop your NOP generator into the CPU socket, and first of all look at these pins again for signs of activity

UD5 pin 11
UD5 pin 8

Then, (with the NOP generator still in place) scope the AB0-AB15 pins of the CPU. You will recall that we should see steady square waves on all of those pins, with AB0 having the highest frequency, with the frequency halving each time as you move from AB0 to AB1, to AB2, to AB3, etc.

If the behaviour on the AB0-AB15 lines is as expected, repeat the same observation on the B0-BA15 lines on the other side of the UD13 and UD14 address line buffers, where the behaviour of the lines should be the same.

[ScottishColin]

I did mean UD1 pin 10.

I'll dig out my NOP generator and report back.

Colin.

[ScottishColin]

I'll be using this as my handmade NOP generator was always 'fun' to work with.

It has LEDs on it - RDY and NMI stay on, RESET starts off unlit but after a couple of seconds, it stays lit.

I'll report back the frequencies.

https://www.laser.com/product_info.p...oducts_id/1981

Colin.

[ScottishColin]

UD5 pins 8 and 11 have no activity at 4.55V

Colin.

[ScottishColin]

All frequencies present and correct on the 6502.

All frequencies present and correct on UD13

UD14 - all present and correct with the exception of pin 17 which should read the same as pin 25 of the CPU and doesn't; no square wave and a reading of 244Mhz.

I have checked and cannot get continuity between pin 25/CPU and pin 17/UD14.

Colin.

[ScottishColin]

I have just recalled that pin 25 was the socket which had the broken 6502 pin in it from post #51. I'm guessing the socket is damaged because I can get continuity under the board.

Replace the 6502 socket?

If so does anyone know where I can get white sockets?

Colin.

[SiriusHardware]

Good work spotting that open circuit on the A15 address line between the CPU and one of the address buffer inputs. After you've fixed that please also check the BA0-BA15 signals on the OTHER (output) side of the UD13 and UD14 buffers as well. We'll look again at UD5 afterwards, since the missing A15 signal may be part of the cause of that.

I can't help you with a source for white sockets but the original Commodore ones have a bad reputation in any case. Yes, replace the socket with a conventional one which will be easier to remove if you ever find a white one to replace it with.

Potential 3D printing project: Replicate the plastic frame of a modern conventional socket in white, and remove the contacts from a black socket and fit them into your 3D printed white frame. You should regard this as a tongue in cheek suggestion because I wouldn't think the sort of plastic which works in 3D printers will be heat resistant enough to survive the heat of being soldered in, but maybe you know differently...

[ScottishColin]

OK - new socket in, continuity OK and all frequencies OK including pin25->UD14 pin 17.

When you say check the BA0-BA15 signals, am I looking for continuity according to the schematics or waveforms?

For example, am I expecting to see waveforms on J9 as per the picture attched?

Colin.

[SiriusHardware]

J9 will be a nice place to pick up the BA0-BA15 signals provided you know which pins of J9 carry which specific signals. The J9 pin numbers are marked on the diagram but it may be less obvious which pins are which when looking at the physical J9 connector. You can instead scope them on the output pins on UD13 and UD14.

UD13: Pins 3, 5, 7, 9, 12, 14, 16, 18, in that order
UD14: Pins 12, 14, 16, 18, 9, 7, 5, 3 in that order

The frequencies on those pins, with the NOP gen fitted, should be identical to the frequencies on the corresponding CPU AB0-AB15 pins. The waveforms should look clean and square.

[ScottishColin]

The only output pin on UD13 that looks right is pin 9. Otherwise there's no waveforms on the other output pins.

UD14 has no waveforms on pin 16 and although the other output pins give me waveforms, they're not nicely square (see attached).

Two new ICs (I have spares here)?

Colin.

[SiriusHardware]

That image actually just looks as though the frequency compensation trimmer on your probe is not correctly adjusted, so just try adjusting that while scoping any of UD16's output pins apart from pin 16 to see if you can get nice 90-degree corners on the square waveforms instead of those overshoot spikes.

As to the rest, if you are sure of your findings then it does sound as though UD13 and UD14 have both failed in different ways. They both have their enable pins strapped in a permanently enabled state so they should just function as always-active buffers.

There is a possibility that some device which sits on the buffered address is so heavily damaged that the buffers can not drive those lines, but failure of the buffers is much more likely so, since you already have some, it would be reasonable to try changing those first. As per your current strategy, try to get the original ICs out in one piece if you can.