Non-working Commodore PET 3016

[ScottishColin]

£20.62 shipping...I think Cricklewood will win if they prove to be like for like replacements.

Colin.

Originally Posted by SiriusHardware

If you trust far east sources, there are a few on UTsource at the moment. I have never used this site but I believe Tim(bucus) and Mark1960 are regular users.

https://www.utsource.net/sch/MC3446.html

(Change the currency button at upper right to get the prices in GPB, which probably do not include shipping).

[buggies]

The 'AP version is the only one listed in the Motorola 1982 shortform cat - possibly the P refers to package type?

[SiriusHardware]

The UTsource site does offer several alternative shipping methods / prices - for example Hermes to UK in 5-8 days for about £5-£6 rather than FedEx in half the time and four times the price, but I think Cricklewood are the devil you know and they have served you quite well so far.

[SiriusHardware]

Originally Posted by buggies

possibly the P refers to package type?

P for 'Plastic' as opposed to 'Ceramic' perhaps.

I found an interesting discussion about this very subject - it starts off sounding scarily different but by the end of the thread the conclusion seems to be that they are compatible.

http://cbm-hackers.2304266.n4.nabble...td4661790.html

The suggestion that the 'A' version exludes the internal termination resistors seems unfounded, given that they are shown on Buggies's image from the datasheet for the AP version. I'd still appreciate a show of hands to go with the one from buggies though.

What are the ones actually fitted? MC3446N?

[ScottishColin]

OK - I have ordered. In the meantime, will the PET still work if I remove UA7/UA8 and get the new sockets in ready for the chips? or will that stop something else working?

Colin.

[ScottishColin]

Yep - they are MC3446N

Colin.

Originally Posted by SiriusHardware

P for 'Plastic' as opposed to 'Ceramic' perhaps.

I found an interesting discussion about this very subject - it starts off sounding scarily different but by the end of the thread the conclusion seems to be that they are compatible.

http://cbm-hackers.2304266.n4.nabble...td4661790.html

I'd still appreciate a show of hands to go with the one from buggies though.

What are the ones actually fitted? MC3446N?

[SiriusHardware]

will that stop something else working?

Removal of UA7 / UA8 only, I think probably not, but if you remove UA9 which handles the 'handshaking' signals of the interface it may distract the computer if it thinks something on the IEEE 488 interface is trying to attract its attention.

[ScottishColin]

Last one for tonight - are there any diagnostics I can do on the user port to see if it's working or not?

Thanks.

Colin.

[ScottishColin]

Got it - thanks.

Colin.

Originally Posted by SiriusHardware

Removal of UA7 / UA8 only, I think probably not, but if you remove UA9 which handles the 'handshaking' signals of the interface it may distract the computer if it thinks something on the IEEE 488 interface is trying to attract its attention.

[buggies]

The Motorola 1990 book shows it as a direct replacement...

[SiriusHardware]

I would have thought that somewhere in that hoard of information Owen found, you would find a user port tester program which will probably need a simple loopback connector to work.

Sending values to the user port will involve setting up PORT A of the 6522 to be all outputs (once) by POKEing an appropriate value to the data direction register for PORT A, (POKE 59459,255)? ...then POKEing the values you want to output to the data register for PORT A. (POKE 59471,value)?

This might make for good bedtime reading, although the example for outputting to the port is more complex than it needs to be.

http://cini.classiccmp.org/pdf/kilob...k%20(0379).pdf

[SiriusHardware]

Originally Posted by buggies

The Motorola 1990 book shows it as a direct replacement...

Thanks buggies, that is reassuring as Colin has gone for it anyway.

[ScottishColin]

Ta.

Colin.

Originally Posted by buggies

The Motorola 1990 book shows it as a direct replacement...

[Slothie]

Originally Posted by SiriusHardware

I would have thought that somewhere in that hoard of information Owen found, you would find a user port tester program which will probably need a simple loopback connector to work.

Sending values to the user port will involve setting up PORT A of the 6522 to be all outputs (once) by POKEing an appropriate value to the data direction register for PORT A, (POKE 59459,255)? ...then POKEing the values you want to output to the data register for PORT A. (POKE 59471,value)?

This might make for good bedtime reading, although the example for outputting to the port is more complex than it needs to be.

http://cini.classiccmp.org/pdf/kilob...k%20(0379).pdf

Interesting article - I did double-take when I read the part saying it was from a book being published "on April Fools day" but it looks legit

I can see myself making a "blinkenlights" board when I get my PET going, and the "wobbulator" is clearly the grandfather of the Nintendo D-Pad!

[ortek_service]

Originally Posted by SiriusHardware

Thanks for trying the 6520 swap. It was worth a shot.

If you try the same thing with UC6 pin 11 / UC6 pin 16...

...After 0 is poked
...After 255 is poked

What sort of change do you see on those pins of UC6?

Originally Posted by ScottishColin

UC6/11 and UC6/16 before any POKE - 3.85V

UC6/11 and UC6/16 after POKE 59426,0 - 0.4V

UC6/11 and UC6/16 after POKE 59426,255 - 3.87V

Colin.

I've just been catching-up with this, and at first couldn't understand why there was a 'Logic-High' voltage on the Least & Most significant bits of the port, but these had previously been read-back as 0, when set high.

But after taking another look at the schematic, it seems I accidentally got the ports swapped over. And UC6(6520) Port-A (Pins 2 to 9) is actually the inputs from buffers, with Port-B (Pins 10 to 17) actually the outputs to the buffers.

So what I really meant to suggest was measuring the voltage on UC6(6520) Pin 2 and Pin 9 (With the POKE the same as before to set all of Port B (Outputs) High).

If you haven't removed UA7 & UA8 yet, you could do this just to really confirm 100% that a receiver buffer in each really is faulty (But that does seem most likely, from other people's experience of these).


Whilst searching for equivalents of the MC3446 (Only finding the HP in-house part numbered one - although the SN75136 & SN75138 / AM26S11C maybe similar, also being listed alongside the MC3446 in the TI 1977 Line drivers Databook - but must have been different enough for TI to also make the MC3446 and keep the Motorola part number).

I have now found the full Motorola MC3446(P=Plastic DIL) datasheet in the Motorola Semiconductor-Data-1976 book on bitsavers, so will extract the datasheet for it from the (20MB) full book, being as it wasn't on the usual datasheets websites - Where I'd only found the (later?) Motorola MC3446AP suffix version and the TI MC3446(D,J or N = Different material DIL packages in Jan'77 / Rev.1986 datasheet)


I did also come across the previous thread SiriusHardware mentioned, where there had also been many tests (Inc. ctrl lines?) on the IEEE interface, to establish the MC3446 buffers were faulty. So there may be something useful there, regarding testing that part of it without having to work it all out again: https://www.vintage-radio.net/forum/...163589&page=13

[ortek_service]

Originally Posted by buggies

The Motorola 1990 book shows it as a direct replacement...

Yes, that's quite helpful - Although technically it shows is that the MC3446AP is a direct or similar replacement for the (Texas Instruments only) MC3446N or MC3446J. However TI themselves claim these area a replacement for the original Motorola MC3446P.

I haven't seen anywhere (yet) where Motorola say the MC3446A(P) replaces the original MC3446(P)
- With no mention of difference in the later datasheets.
But I would expect it to be, and now I've found the original datasheets, I've OCR'd that
(along with TI one, tidying it up so pages are straight & cropped), plus played spot-the-difference on these.

Many of these datasheets are rather vague about operating-voltage range (for Motorola ones) or packages suffix differences (for TI one).


I have now found that the specifications for the original Motorola MC3446(P) & the TI MC3446N (or extremely similar with MC3446J & MC3446D very similar) are basically all the same.

Whereas the later (replacement?) MC3446A(P) has a couple of differences:
- It is compliant with later GPIB / IEEE standard dated 1978 (compared to 1975) and still has termination resistors but only shows 'T' on symbol.
- It has a wider operating voltage range of 4.5-5.5V (compared to 4.75-5.25V)
- It has reduced typical hysteresis on the Receiver Inputs Threshold Voltage High to Low Output Logic State, which is now typically 1.0V rather than 0.8V. (However, it seems they forgot to update the hysteresis-loop graph, as this is the same as before!)

Datasheets for all versions are attached.

[ortek_service]

Originally Posted by SiriusHardware

I would have thought that somewhere in that hoard of information Owen found, you would find a user port tester program which will probably need a simple loopback connector to work.

Sending values to the user port will involve setting up PORT A of the 6522 to be all outputs (once) by POKEing an appropriate value to the data direction register for PORT A, (POKE 59459,255)? ...then POKEing the values you want to output to the data register for PORT A. (POKE 59471,value)?

This might make for good bedtime reading, although the example for outputting to the port is more complex than it needs to be.

http://cini.classiccmp.org/pdf/kilob...k%20(0379).pdf

Testing the User Port isn't too much different from the testing that's been done with the 6520 for the IEEE. Except that you have to set the Data Direction Register (59459) first. And you read or write just one (59471) Data Register, that is the same for both directions.

So I think it's easiest to just set all lines as outputs: POKE 59459,255
Set all outputs High: POKE 59471,255
Measure the voltages on connector pins C to L, and check they are all >3.5V
Set all outputs Low: POKE 59471,0
Measure the voltages on connector pins C to L, and check they are all <0.4V

Then type-in & Run the Example 3 program, from that PET User Port Cookbook (I've re-attached an OCR'd version, that still looks OK, but programs haven't OCR'd very well).
Ensure it displays 255 (as all inputs are pulled-high by default, inside 6522 VIA) , then connect connector pins C to L, to ground in-turn, one at a time and you should then see 254, 253, 251, 247, 239, 223, 191 & 127.

There's not really anything to go wrong with the user port, other than the 6522 (which is also used by several other things so has to be mostly-working. Just in case it has some damaged Port A lines, I see that Cricklewood list it at the same £15+VAT as the 6502. However, both are available on the 'bay for around £3(+VAT) each inc. delivery for 1off from China (So a slightly longer weight and probably want to check supplier has sold other OK with good feedback, and been around a while to avoid fakes)

[ortek_service]

Originally Posted by ortek_service

>>
>>
I did also come across the previous thread SiriusHardware mentioned, where there had also been many tests (Inc. ctrl lines?) on the IEEE interface, to establish the MC3446 buffers were faulty. So there may be something useful there, regarding testing that part of it without having to work it all out again: https://www.vintage-radio.net/forum/...163589&page=13

I had a look at this, and it seems there was just resistance measurements made on the IEEE Bus-side of the buffers
- but that had found UA9 (as well as UA7) was faulty.

However, whilst useful to see if internal termination resistors are faulty, that alone may not always find other faults.
So it would have found a fault with one of the UA7 / UA8 buffers, where the output was going higher than expected due to this. But it wouldn't have found faults with a receiver buffer in each of these.

Although could be done on the remaining (untested so far?) UA9 buffer, as a quick-check test for starters.

[SiriusHardware]

In that thread we were working with what the OP had, which was a meter, so he did quite well there really. The idea of doing resistance from all similar pins to a common point is that it will hopefully reveal differences between pins which should all be identical. If the fault is close enough to the pin to cause a readable difference, that can be a valuable clue. If the fault is buried 'in the middle' of the IC then it may not cause a readable difference.

On this machine, I think the obvious problem with the port data bits 0 and 7 and the fact that swapping the 6520s does not fix that is reason enough to replace UA7 and UA8, hopefully that will move things a bit further. I don't think Colin has an actual IEEE-488 device to try on the port at the moment.

[ortek_service]

With this one, it had been found that one IEEE port data line on UA7 / UA8 went to 4.3V rather than 3.3V, when the open-collector output was set high (So voltage is just being set by the built-in termination resistor divider).

So it seemed that by measuring the resistance of the IEEE port lines (especially on the remaining UA9), you'd find out if the internal termination resistors were OK at least (and had also found at that other thread).

But as I'd said, this wouldn't find issues with the read-back buffers, that a couple had been found with the UA7 & UA8 ones here (unless there were some shorts)