Non-working Commodore PET 3016

[Mark1960]

Originally Posted by ScottishColin

All RAM chips are soldered to the motherbard.

I’m just guessing, but I think if it is one of the KIL opcodes then its more likely to be a rom fault than a ram fault. My guess is based on the basic interpreter as machine code in rom is going to be reading the basic instructions only as data from ram. Unless a Ram chip is putting bad data on the bus at the wrong time which is still a possibility.

Still early in the investigation yet, but I think I’d like to see garbage on the display before you think about buying replacement roms, even if it was certain to be the roms.

[SiriusHardware]

The CPU databus also has a buffer between it and the rest of the PET, so that is another potential point at which incoming data from the ROMS / RAMS could be going awry.

[ScottishColin]

I need three hands for the job, so I'm in the middle of negotiations.

In the meantime, I was wondering if it is worth me methodically adding pins one at a time to the socket to see which pin or pins affects the waves on 9/10/11?

[julie_m]

Absent any better suggestion, you could try connecting up just one address pin that goes to UB3 first and checking for proper behaviour; then a pin that goes to UC3. If one of these chips is faulty and the fault is affecting all the buffers within it, you'll see it straight away. If only one buffer is faulty, or more than one but you missed them all, you will have to keep adding pins until you find one that messes up the processor.

Besides the obvious issues with wear and tear on sockets (which can be mitigated to some extent by reconnecting pins in batches at a time and taking careful notes; you can stop straight away as soon as something breaks it), there is another slight nagging doubt in my mind: if the fault is that several buffers are imposing short circuits on the address lines, and during testing only one pin is being short-circuited as opposed to several, then that one pin will be carrying the full fault current as opposed to it being shared among multiple outputs.

Obviously it's your call. The above single-pin overload scenario is pretty unlikely, but every insertion and removal carries the same risk of damaging something. And if you do break off a pin or rip up a PCB track? None of the ICs are such complete unobtainium that you can't use a modern replacement which will be functionally identical, and it's only a double-sided, through-hole motherboard. It can be field-repaired if needs be.


If you make up a stacked-sockets adaptor with D0, D2 and D4 of the 6502 wired to 0V with low-value resistors (anything 470 ohms to 4.7K will be fine; the data pins are two-way, and wire links could cause problems if it tried to drive any of them high) and leave the other data pins unconnected, the processor ought to see 11101010 in every memory location it tries to read, which will be treated as NOP.

[SiriusHardware]

We have a theory that the CPU may be reading one of several 'illegal' opcodes from the system databus which are able to put the CPU into a 'trance' state in which it appears inactive.

Although it is also possible that a databus line stuck high or low could cause a similar problem, random or progressive reconnection of the data bus lines won't really help us much, although I can see where you are coming from. There would be no harm in trying it, though.

Edit: Crossed with Julie. Colin has already reconnected all of the address lines to the address buffers and the CPU still runs, albeit with the databus lines still disconnected. We're now asking him to scope the address lines before and after the buffers to verify that the buffers are actually functioning as buffers.

[ScottishColin]

OK - just done my process of elimination testing.

If any or all of pins 30, 31 and 32 are present in the 6502 socket, I do not get a reading from pins 9,10 and 11.

If they are absent, I get clear readings.

I'll go and do the comparative testing as per post 355 later on this afternoon/evening and let you know.

Colin.

[julie_m]

If I am reading the diagram right, they are the twos, fours and eights bits of the data bus. Now I happen to know that xxxxxx01 on the 6502 is always a valid instruction, xxxxxx10 is most often a killer instruction which will leave the machine requiring a reset and xxxxxx11 is always survivable -- some of them are even half-useful. So if it breaks with pin 32 connected and pin 33 unconnected, that suggests the problem is something other than encountering a killer instruction; maybe something else is trying to drive D1-D3 at the same time.

The data lines extend tantalisingly off the top of the schematic I've been looking at, probably to some two-way buffers (74LS245?) along with the read/write line on pin 34 to set the direction. Could be worth a look there next .....

[SiriusHardware]

Julie, the full diagram of the CPU section is here:-

http://www.zimmers.net/anonftp/pub/c...N/320349-1.gif

The diagrams for the rest of the circuit / machine are here:-

http://www.zimmers.net/anonftp/pub/c...ers/pet/2001N/

Rather than 1 74LS245 (which would be reasonable to expect) the machine instead uses another pair of 244s as data bus buffers. However (in contrast to what I said in #362) these buffers only buffer the data bus feed to certain areas including the expansion port and circuit diagram sheets 5 and 8. The CPU data bus connections to other parts of the machine (circuit diagram sheets 2,3,4) appear to be direct.

[julie_m]

Thanks for that! I see how they've used the 244. It's basically two four-bit tristate buffers that can be connected either as eight-bit one-way or four-bit two-way. Odd way of doing it when there's already a chip to do the work of two, but maybe four 244s were cheaper than two and a 245, or they just wanted to avoid proliferation of SKUs for the sake of process reliability.

Have we already got resistance readings for pins 26-32 with red probe to pin in question and black probe to 0V, and again with black probe to PIQ and red to +5V, power off in all cases?

[SiriusHardware]

Not yet, I try not to bury Colin under an avalanche of things to do. Still waiting for Colin and his pet octopus to give us the results of the input to output checks on the address buffers. Checking for oddness on the data bus buffers, as you suggest, is the next logical step.

[ScottishColin]

OK - done. I attach a link showing the Channel1/channel2 readings for the address lines/UB3-UC3 testing.

Couple of points to note:

1. The legs on UB2 and UC3 were hard to get readings from - I had to scrape a bit. I guess the only way to confirm all is really OK is to take readings from underneath the motherboard and I didn't do that. They all got a reading eventually.

2. Nearly all readings looked like you said they would - the same shape waves, but the 6502 waves were consistently longer than the UB3/UC3 waves (see document)

3. The only one that looked in any way inconsistent to me was 6502 pin 19, UB3 pin 16 - again, see the document for the graph.

Beer.

https://drive.google.com/file/d/1UrR...ew?usp=sharing


EDIT: Please note only the following pins were connected in the socket:

1, 2, 4, 6, 8-25, 37,38, 40

[SiriusHardware]

As you say the pin 19 / pin 16 readout looks interesting, you can now see the value of scoping both at once because you can immediately see the difference between those , whereas on all the rest you can immediately see the similarity.

I take it the green traces are the ones taken from UB3 / UC3 and the yellow ones are from the 6502? If so you may have made a valuable discovery as it looks like there is a problem on the buffered side of address line A10.

[ScottishColin]

Confirmed that yellow were 6502 and green UC3/UB3

[ScottishColin]

Is it time to buy 2 x SN74LS244N and sockets to replace them?

[SiriusHardware]

Maybe. I think Tim and Slothie both said that there is anecdotal evidence to suggest that those buffers commonly fail. (And at the moment it would only be UB3 which you would replace, as all the address signals which pass through UC3 look normal).

Unfortunately the fact that you seem to have an anomaly on the buffered A10 line (UB3 pin 16) doesn't necessarily mean that the fault is with pin 16 of UB3, it could just as easily be caused by a fault on any of the other devices which are connected to the 'BA10' line on circuit sheets 4 and 5. I'll leave it to you to follow that line and see how many devices it goes to.

[Mark1960]

I think only A8 looks correct on the buffered side. All the other buffered address lines don’t seem to be pulling down correctly. A10 is different failing to pull high.

As A12 to A15 don’t go directly to memory the common factor seems to be the buffers themselves.

[Timbucus]

Looking at those traces it could be that the 244 is just having its output shorted by the 153 (E5) any of the ROMS or the 7425 (B2) but, it is driving just incredibly low which I know is a failure mode that Jerry has experienced a lot - and it needs a large fan out as it is driving more chips than the others. I don't suppose any of the 244's are socketed are they? So they can just be swapped over. I had a similar problem on my Triton (which does exactly the same with two 244's on the address bus incidentally) although in my instance it was on the inbound Keyboard which is also a 244.

[ScottishColin]

Originally Posted by Timbucus

Looking at those traces it could be that the 244 is just having its output shorted by the 153 (E5) any of the ROMS or the 7425 (B2) but, it is driving just incredibly low which I know is a failure mode that Jerry has experienced a lot - and it needs a large fan out as it is driving more chips than the others. I don't suppose any of the 244's are socketed are they? So they can just be swapped over. I had a similar problem on my Triton (which does exactly the same with two 244's on the address bus incidentally) although in my instance it was on the inbound Keyboard which is also a 244.

No - they're both soldered to the motherboard, but I'm getting more confident at de-soldering and putting in sockets now.

[SiriusHardware]

No, they aren't in sockets.

I did see that the levels were different on the other 15 address lines but when they are all the same and one is definitely wrong I would tend to give the other 15 the benefit of the doubt, at least initially.

Shall we ask Colin to socket and replace those buffers, then? Bearing in mind that he seems to have a lot of difficulty desoldering - I suspect because all the solder is oxidised because it has been damp at some point - how about he orders two ICs and two sockets but only replaces UB3 initially and then compares the levels on the replaced UB3 with the still original UC3?

[Timbucus]

Originally Posted by Mark1960

I think only A8 looks correct on the buffered side. All the other buffered address lines don’t seem to be pulling down correctly. A10 is different failing to pull high.

As A12 to A15 don’t go directly to memory the common factor seems to be the buffers themselves.

I thought that at first and then thought what are the chances of both chips having exactly the same fault - that looks like there is under a volt so probably below the TTL 0 threshold anyway - the lack of high drive on A10 will definitely cause a major problem.

So I think fitting a socket and another socket with that leg removed with a new chip will be the next step as a minimum - we can prove then where the lack of drive is coming from. I would not do both buffers as yet unless this step improves the pull down which Mark is concerned about.

In this instance I would be tempted to snip the actual chip pin and bend it up as it is coming out anyway and retest the A10 drive levels on the buffer output.