Non-working Commodore PET 3016 - Page 72 - UK Vintage Radio Repair and Restoration Discussion Forum

ScottishColin · 8th Apr 2021, 1:11 pm

OK - new EPROM has arrived. I have replaced all other original ROMs and put the new Sloth_Vc EPROM in the adapter previously provided. Plugged it in and I still get zero page error - stopped.

What testing would be next?

Colin.

SiriusHardware · 8th Apr 2021, 1:16 pm

That behaviour is as expected, the new difference is under the bonnet, where the code should now keep on trying the write to zero page / read from zero page operation which failed.

To verify that, look first for continuous waveforms on the read and write enable pins (pins 1 and 19) of the buffer ICs UE9 / UE10 after the 'Stopped' error message has appeared.

ScottishColin · 8th Apr 2021, 2:04 pm

Continuous waveforms on all four pins - see attached.

Colin.

Quote:

Originally Posted by SiriusHardware

That behaviour is as expected, the new difference is under the bonnet, where the code should now keep on trying the write to zero page / read from zero page operation which failed.

To verify that, look first for continuous waveforms on the read and write enable pins (pins 1 and 19) of the buffer ICs UE9 / UE10 after the 'Stopped' error message has appeared.

ortek_service · 8th Apr 2021, 2:41 pm

These all look fine (although a definitive check would be to have pin1 on 1 channel and pin 19 on the other, as you could then see that one is exactly the inverse of the other).

You could try 'scoping all the remaining (other than Power & ground) pins on UE9 & UE10 (16 pins on each) to see if any look on each side of the buffer look substantially different from the majority of the others As when stuck in this loop, with 55's / AA's being written / read (if working), then they should all look very similar - particularly on the 'memory-bus side', although 'CPU Data-bus side ones' will probably look a bit different due to Diagnostic ROM reading etc.

In theory, you only need to probe 4 pins on the 'CPU Data-bus side' and 4 pins on the 'Memory-bus side' data in/out, on each of the UE9 & UE10 IC's as they are joined together in pairs
- but no harm in checking all just in case there's a connection issue on sockets / tracking etc.

This may be easiest to start with, as to work out exactly what's happening involves looking only at these when the signal on the UE9/10 Pin19's is low.

ScottishColin · 8th Apr 2021, 3:20 pm

Here's the comparisons as per your post.

In terms of the rest of your post - do you mean that the equivalent pins of UE9 and UE10 should look the same?

Colin.

Quote:

Originally Posted by ortek_service

These all look fine (although a definitive check would be to have pin1 on 1 channel and pin 19 on the other, as you could then see that one is exactly the inverse of the other).

You could try 'scoping all the remaining (other than Power & ground) pins on UE9 & UE10 (16 pins on each) to see if any look on each side of the buffer look substantially different from the majority of the others As when stuck in this loop, with 55's / AA's being written / read (if working), then they should all look very similar - particularly on the 'memory-bus side', although 'CPU Data-bus side ones' will probably look a bit different due to Diagnostic ROM reading etc.

In theory, you only need to probe 4 pins on the 'CPU Data-bus side' and 4 pins on the 'Memory-bus side' data in/out, on each of the UE9 & UE10 IC's as they are joined together in pairs
- but no harm in checking all just in case there's a connection issue on sockets / tracking etc.

This may be easiest to start with, as to work out exactly what's happening involves looking only at these when the signal on the UE9/10 Pin19's is low.

ScottishColin · 8th Apr 2021, 3:52 pm

OK - assuming that UE9 and UE10 pins should have the same waveforms, see attached. UE9 and UE10 pins 5 & 6, UE10/7 and UE10/13 look odd to me.

Colin.

ScottishColin · 8th Apr 2021, 4:03 pm

OK - rebooted and tested again with differing results. Is it possible that different code is being executed?

On screen I have a slightly different error message

o pak page error - stopped

Colin.

ortek_service · 8th Apr 2021, 4:17 pm

I was only thinking of concentrating on UE9 & UE10 buffers for now
- As you can't directly compare what's there with the other buffers as the RAM access is split into Screen RAM or Main RAM on those (some of who's buffers you've already replaced - migt be useful to remind us which of these have actually now been socketed / replaced / checked OK. And easiest to look at things that are common, being as both RAM areas don't seem to read back correctly)

And best to try and work out if signals on UE9 & UE10 do appear to be all OK first, before moving to other areas - I'll have a look at the ones you've captured.

Regarding the intermittent corruption of the displayed message:
It can't really be different code being executed, but could be corruption / something 'floating a bit on the bus - most likely on screen RAM access
But I think that's probably best looked at later, as it's difficult to pin-point if intermittent and could be related to what's wrong with the RAM accessing.

NivagSwerdna · 8th Apr 2021, 4:49 pm

Long thread... and I have a poor attention span...

Did the 74S74 at H1 get replaced?

ScottishColin · 8th Apr 2021, 5:00 pm

Yes it did.

here's the compete list of replacements so far....

UB2 - new socket new IC
UB3 - new socket new IC
UC3 - new socket new IC
UC4 - new socket
UD7 - new IC
UD9 - new socket
UE7 - new socket new IC
UE8 - new socket new IC
UF7 - new socket new IC
UF8 - new socket new IC
UF9 - new socket new IC
UG5 - new socket new IC
UH1 - new socket new IC
UH3 - new socket new IC
UH6 - new socket new IC

So much for me wanting to retain original parts....although it's fair to say all of the above were tested and failed tests.

Colin.

Quote:

Originally Posted by NivagSwerdna

Long thread... and I have a poor attention span...

Did the 74S74 at H1 get replaced?

ortek_service · 8th Apr 2021, 5:01 pm

Quote:

Originally Posted by ScottishColin

Here's the comparisons as per your post.

In terms of the rest of your post - do you mean that the equivalent pins of UE9 and UE10 should look the same?

Colin.

Thanks for those - even though they show Pin 1 on one IC and Pin 19 on the other other, the two IC's Pin 1's & Pin 19's do connect to each other. So should get the same results (providing there's no broken connections).
And both of these show that either Pin 19's are always inverse of either Pin1's, and so all are connected OK.

Regarding the rest of my post, I really meant (but I hadn't had chance to look at schematic) that all 'Memory bus side data lines' on both IC's should be very similar, when stuck in diagnostic zero-page failure infinite loop. i.e.
UE9 Pins: 18/17, 16/15, 14/13 & 12/11 and UE10 Pins: 18/17, 16/15, 14/13 & 12/11 (where ones connected either side of '/' are joined together so shouldn't matter which one is probed, if PCB tracks are all OK)

The 'CPU Data-bus side' of UE9 & UE10, won't always look quite the same, as there's sometimes reads from the Diagnostic ROM on these (so can only compare exactly when UE9 or UE10 Pin19's signal is Low - for read from RAM)
But for reference, these are:
UE9 Pins: 2/3, 4/5, 6/7 & 8/9 and UE10 Pins: 2/3, 4/5, 6/7 & 8/9 (where ones connected either side of '/' are joined together so shouldn't matter which one is probed, if PCB tracks are all OK)

A >= 3Ch 'scope / v.cheap USB logic-analyzer is ideally what's required to look at the CPU-side signals, as that allows triggering / viewing in the right places.

Mark1960 · 8th Apr 2021, 5:14 pm

Quote:

Originally Posted by ScottishColin

Yes it did.

here's the compete list of replacements so far....

UB2 - new socket new IC
UB3 - new socket new IC
UC3 - new socket new IC
UC4 - new socket
UD7 - new IC
UD9 - new socket
UE7 - new socket new IC
UE8 - new socket new IC
UF7 - new socket new IC
UF8 - new socket new IC
UF9 - new socket new IC
UG5 - new socket new IC
UH3 - new socket new IC
UH6 - new socket new IC

So much for me wanting to retain original parts....although it's fair to say all of the above were tested and failed tests.

Colin.

Quote:

Originally Posted by NivagSwerdna

Long thread... and I have a poor attention span...

Did the 74S74 at H1 get replaced?

List doesn’t include UH1

ortek_service · 8th Apr 2021, 5:19 pm

Quote:

Originally Posted by ScottishColin

OK - assuming that UE9 and UE10 pins should have the same waveforms, see attached. UE9 and UE10 pins 5 & 6, UE10/7 and UE10/13 look odd to me.

Colin.

Yes, I've just had a glance through these and found a few lines with either no activity (so stuck high / low) and some with a lower amplitude - so a bus conflict or a a very weak output drive.

I'll have a bit more detailed look, to see exactly which ones these correspond to.

But I am thinking we should be able to find what might be happening here.

ScottishColin · 8th Apr 2021, 5:19 pm

Does now - just edited it as I realised my error.

Colin.

Quote:

Originally Posted by Mark1960

Quote:

Originally Posted by ScottishColin

Yes it did.

here's the compete list of replacements so far....

UB2 - new socket new IC
UB3 - new socket new IC
UC3 - new socket new IC
UC4 - new socket
UD7 - new IC
UD9 - new socket
UE7 - new socket new IC
UE8 - new socket new IC
UF7 - new socket new IC
UF8 - new socket new IC
UF9 - new socket new IC
UG5 - new socket new IC
UH3 - new socket new IC
UH6 - new socket new IC

So much for me wanting to retain original parts....although it's fair to say all of the above were tested and failed tests.

Colin.

Quote:

Originally Posted by NivagSwerdna

Long thread... and I have a poor attention span...

Did the 74S74 at H1 get replaced?

List doesn’t include UH1

ScottishColin · 8th Apr 2021, 5:20 pm

The second set of traces look a lot more healthy though...

Colin.

Quote:

Originally Posted by ortek_service

Quote:

Originally Posted by ScottishColin

OK - assuming that UE9 and UE10 pins should have the same waveforms, see attached. UE9 and UE10 pins 5 & 6, UE10/7 and UE10/13 look odd to me.

Colin.

Yes, I've just had a glance through these and found a few lines with either no activity (so stuck high / low) and some with a lower amplitude - so a bus conflict or a a very weak output drive.

I'll have a bit more detailed look, to see exactly which ones these correspond to.

But I am thinking we should be able to find what might be happening here.

ortek_service · 8th Apr 2021, 5:29 pm

Quote:

Originally Posted by ScottishColin

The second set of traces look a lot more healthy though...

Colin.

Quote:

Originally Posted by ortek_service

Quote:

Originally Posted by ScottishColin

OK - assuming that UE9 and UE10 pins should have the same waveforms, see attached. UE9 and UE10 pins 5 & 6, UE10/7 and UE10/13 look odd to me.

Colin.

Yes, I've just had a glance through these and found a few lines with either no activity (so stuck high / low) and some with a lower amplitude - so a bus conflict or a a very weak output drive.

I'll have a bit more detailed look, to see exactly which ones these correspond to.

But I am thinking we should be able to find what might be happening here.

I thought the second set were when you got a slightly-corrupted Error message? - In which case, it's odd they were better
I wouldn't really expect any difference, if the diagnostic firmware was stuck in the same endless loop executing the same write / read which I presume will always be at first RAM location (but that or readback value mismatches are not currently attempted to be written to screen)

PJL · 8th Apr 2021, 5:29 pm

The 1st test shows UE9/5 and UE10/5 as both being continuous 0. If the program were running correctly this should not be possible as the data being written is A5/5A so all CPU data pins should be changing.

The 2nd test looks very unhappy with lots of noise. UE9/5 now fluctuates but UE10/5 shows possible bus contention. The bus contention also seems evident in UE10/3.

Is it worth looking at the PSU and any rail decoupling capacitors as a possible source of intermittent behaviour? I am not sure we can trust the results of the test program as it stands.

Mark1960 · 8th Apr 2021, 5:37 pm

Looking at plots in #1426 and #1427, I think there was some confusion with instructions on what to check.

Only pins 1 and 19 are the same between UE9 and UE10.

Some of the plots for UE10 pins look bad, showing bad logic levels. I think it would be good to check further as it might only be UE10 that needs to be replaced.

I’ll list the pairs of pins to compare in the hope we avoid confusion this time.

UE10-3, UE10-18
UE10-5, UE10-16
UE10-7, UE10-14
UE10-9, UE10-12

UE9-3, UE9-18
UE9-5, UE9-16
UE9-7, UE9-14
UE9-9, UE9-12

If you could put in pdf that is easier to review.

After we see those plots, if there are still problems on UE10 pins, we can compare those bad pins with pins 1 and 19 to confirm if the buffer is the cause, I’ll describe in more details when we see the plots for the above pairs.

ScottishColin · 8th Apr 2021, 6:11 pm

Ah - I guessed wrong. Apologies.

See attached PDF for results.

Colin.

Quote:

Originally Posted by Mark1960

Looking at plots in #1426 and #1427, I think there was some confusion with instructions on what to check.

Only pins 1 and 19 are the same between UE9 and UE10.

Some of the plots for UE10 pins look bad, showing bad logic levels. I think it would be good to check further as it might only be UE10 that needs to be replaced.

I’ll list the pairs of pins to compare in the hope we avoid confusion this time.

UE10-3, UE10-18
UE10-5, UE10-16
UE10-7, UE10-14
UE10-9, UE10-12

UE9-3, UE9-18
UE9-5, UE9-16
UE9-7, UE9-14
UE9-9, UE9-12

If you could put in pdf that is easier to review.

After we see those plots, if there are still problems on UE10 pins, we can compare those bad pins with pins 1 and 19 to confirm if the buffer is the cause, I’ll describe in more details when we see the plots for the above pairs.

Mark1960 · 8th Apr 2021, 6:28 pm

So UE9 looks ok, but UE10 looks bad on pins 3 and 5.

Just to be certain compare the following pairs.

UE10-3, UE10-19
UE10-5, UE10-19

If the incorrect levels on pin 3 and 5 match the time pin 19 is low then this confirms UE10 is at fault and not some other chip in the system.

8th Apr 2021, 1:11 pm	#1421
ScottishColin Octode Join Date: May 2012 Location: Perth, Scotland Posts: 1,804	Re: Non-working Commodore PET 3016 OK - new EPROM has arrived. I have replaced all other original ROMs and put the new Sloth_Vc EPROM in the adapter previously provided. Plugged it in and I still get zero page error - stopped. What testing would be next? Colin.

8th Apr 2021, 1:16 pm	#1422
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,556	Re: Non-working Commodore PET 3016 That behaviour is as expected, the new difference is under the bonnet, where the code should now keep on trying the write to zero page / read from zero page operation which failed. To verify that, look first for continuous waveforms on the read and write enable pins (pins 1 and 19) of the buffer ICs UE9 / UE10 after the 'Stopped' error message has appeared.

8th Apr 2021, 2:41 pm	#1424
ortek_service Octode Join Date: May 2018 Location: Northampton, Northamptonshire, UK. Posts: 1,440	Re: Non-working Commodore PET 3016 These all look fine (although a definitive check would be to have pin1 on 1 channel and pin 19 on the other, as you could then see that one is exactly the inverse of the other). You could try 'scoping all the remaining (other than Power & ground) pins on UE9 & UE10 (16 pins on each) to see if any look on each side of the buffer look substantially different from the majority of the others As when stuck in this loop, with 55's / AA's being written / read (if working), then they should all look very similar - particularly on the 'memory-bus side', although 'CPU Data-bus side ones' will probably look a bit different due to Diagnostic ROM reading etc. In theory, you only need to probe 4 pins on the 'CPU Data-bus side' and 4 pins on the 'Memory-bus side' data in/out, on each of the UE9 & UE10 IC's as they are joined together in pairs - but no harm in checking all just in case there's a connection issue on sockets / tracking etc. This may be easiest to start with, as to work out exactly what's happening involves looking only at these when the signal on the UE9/10 Pin19's is low. Last edited by ortek_service; 8th Apr 2021 at 2:59 pm.

8th Apr 2021, 4:17 pm	#1428
ortek_service Octode Join Date: May 2018 Location: Northampton, Northamptonshire, UK. Posts: 1,440	Re: Non-working Commodore PET 3016 I was only thinking of concentrating on UE9 & UE10 buffers for now - As you can't directly compare what's there with the other buffers as the RAM access is split into Screen RAM or Main RAM on those (some of who's buffers you've already replaced - migt be useful to remind us which of these have actually now been socketed / replaced / checked OK. And easiest to look at things that are common, being as both RAM areas don't seem to read back correctly) And best to try and work out if signals on UE9 & UE10 do appear to be all OK first, before moving to other areas - I'll have a look at the ones you've captured. Regarding the intermittent corruption of the displayed message: It can't really be different code being executed, but could be corruption / something 'floating a bit on the bus - most likely on screen RAM access But I think that's probably best looked at later, as it's difficult to pin-point if intermittent and could be related to what's wrong with the RAM accessing.

8th Apr 2021, 4:49 pm	#1429
NivagSwerdna Triode Join Date: Feb 2021 Location: Kingston upon Thames, Greater London, UK. Posts: 11	Re: Non-working Commodore PET 3016 Long thread... and I have a poor attention span... Did the 74S74 at H1 get replaced?

8th Apr 2021, 5:29 pm	#1437
PJL Dekatron Join Date: Sep 2005 Location: Seaford, East Sussex, UK. Posts: 5,997	Re: Non-working Commodore PET 3016 The 1st test shows UE9/5 and UE10/5 as both being continuous 0. If the program were running correctly this should not be possible as the data being written is A5/5A so all CPU data pins should be changing. The 2nd test looks very unhappy with lots of noise. UE9/5 now fluctuates but UE10/5 shows possible bus contention. The bus contention also seems evident in UE10/3. Is it worth looking at the PSU and any rail decoupling capacitors as a possible source of intermittent behaviour? I am not sure we can trust the results of the test program as it stands.

8th Apr 2021, 5:37 pm	#1438
Mark1960 Octode Join Date: Mar 2020 Location: Kitchener, Ontario, Canada Posts: 1,294	Re: Non-working Commodore PET 3016 Looking at plots in #1426 and #1427, I think there was some confusion with instructions on what to check. Only pins 1 and 19 are the same between UE9 and UE10. Some of the plots for UE10 pins look bad, showing bad logic levels. I think it would be good to check further as it might only be UE10 that needs to be replaced. I’ll list the pairs of pins to compare in the hope we avoid confusion this time. UE10-3, UE10-18 UE10-5, UE10-16 UE10-7, UE10-14 UE10-9, UE10-12 UE9-3, UE9-18 UE9-5, UE9-16 UE9-7, UE9-14 UE9-9, UE9-12 If you could put in pdf that is easier to review. After we see those plots, if there are still problems on UE10 pins, we can compare those bad pins with pins 1 and 19 to confirm if the buffer is the cause, I’ll describe in more details when we see the plots for the above pairs.

8th Apr 2021, 6:28 pm	#1440
Mark1960 Octode Join Date: Mar 2020 Location: Kitchener, Ontario, Canada Posts: 1,294	Re: Non-working Commodore PET 3016 So UE9 looks ok, but UE10 looks bad on pins 3 and 5. Just to be certain compare the following pairs. UE10-3, UE10-19 UE10-5, UE10-19 If the incorrect levels on pin 3 and 5 match the time pin 19 is low then this confirms UE10 is at fault and not some other chip in the system.