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

ScottishColin · 2nd Mar 2021, 1:51 pm

Here's a comparison of UD 9/8/7 pins 11 which shows the difference in voltage. UD7 has been recently replaced with a 'new' PROM.

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

Colin.

Quote:

Originally Posted by Mark1960

Which of the proms was already replaced?

Does it show a better high voltage level than the others on DA0 ?

I think you still need to try and identify why DA0 is not showing a good high level. If it turns out to be the buffer its possible this could have caused the failure of UD6.

ScottishColin · 2nd Mar 2021, 2:07 pm

OK. In my latest act of idiocy (I'm blaming lockdown), I have realised that the PROM that was all 00s that I thought was UD6 was in fact the duff UD7 I had already replaced...

It was your sentence reminding me that I had replaced the leg which reminded me to go and look. You were right about not muddling them up.

I put that one back in as UD6 and I get nice square waves from it.

Apologies all.

I seem to have 4 working PROMs again....

Colin.

It was the

Quote:

Originally Posted by SiriusHardware

If it is duff, that's a shame - it was definitely OK when I had it (correct checksum, etc) but they are notoriously fragile. That's the one where the pin had broken off on the corner, isn't it, so maybe it's better in the long run to replace it anyway.

The file you would be looking for for UD6 is the one named thusly:-

basic-2-c000.901465-01.bin2009-08-18

under 'Files' on this page:-

http://www.zimmers.net/anonftp/pub/c...pet/index.html

UD7 which you've already replaced should have been programmed with the file named:-

basic-2-d000.901465-02.bin2009-08-18

If you are wondering how I know which code goes where, look closely at the circuit diagram of the PROMs, which shows the address range occupied by each PROM. UD6 = C000 onwards, UD7 = D000 onwards. Those two hexadecimal addresses are included as part of the file names above.

dave cox · 2nd Mar 2021, 2:11 pm

Thx for link julie_m

dave cox · 2nd Mar 2021, 2:27 pm

I think Mark1960 mentioned a higher sample rate earlier.

To get a reliable indication of the 'level' of a logic signal you need a sample clock, as a minimum, at approx 20X the system clock. On this 1MHz system that means at least 20M sample/second. Your scope will indicate the sample rate on the display somewhere.

Why 20X ?

To satisfy the Nyquist criterion, you need to sample at 2X the frequency you want to observe or you may discover the nasty world of aliases - this will be very misleading! For logic signals, we are looking at square waves and to get a reasonable approximation to a square wave you need to see >= 10 harmonics of the fundamental frequency. For a 1MHz square wave you really need to see up to 10MHz sine-wave and to see a 10MHz sine-wave you need a 20MHz sample rate!

dc

dave cox · 2nd Mar 2021, 2:31 pm

This is what a 10 harmonic square wave looks like ...

(lifted from https://www.prosoundweb.com)

SiriusHardware · 2nd Mar 2021, 4:11 pm

Quote:

Originally Posted by ScottishColin

I seem to have 4 working PROMs again....

Surely a positive development, no matter how you arrived at that point. I don't suppose you know how long the dud UD7 was fitted in UD6 position? Since you got the PROMs back?

It might mean having to go back over a few things we have already checked, that's all. How do you feel about swapping out the data buffers?

SiriusHardware · 2nd Mar 2021, 4:16 pm

If the PROMs have been mixed up since you got them back and since before you got the new UD7, consider trying the computer with all the PROMs in the right places and the CPU inserted directly, just in case it then works.

ScottishColin · 2nd Mar 2021, 4:35 pm

OK - nothing on the screen, but I am now getting square waves on the CPU address lines with the 6502 plugged directly into the socket.

I'm more than happy to replace UE9 and 10 if that may help. I have replacement chips and sockets here.

Should I re-start my testing?

Colin.

Quote:

Originally Posted by SiriusHardware

If the PROMs have been mixed up since you got them back and since before you got the new UD7, consider trying the computer with all the PROMs in the right places and the CPU inserted directly, just in case it then works.

SiriusHardware · 2nd Mar 2021, 5:03 pm

You have CPU activity now even with all ICs plugged in in their correct positions? If so, that's another decent step forward. I'm at work just now, will get back to you later.

Mark1960 · 2nd Mar 2021, 5:25 pm

I think it would be good to check the data lines again with the duff prom replaced, see if DA0 is still showing low logic levels from one or more proms.

You could try first with the 6502 direct connected, but its not running NOP now so the pattern will be different and you might not be getting chip select on every prom now.

ScottishColin · 2nd Mar 2021, 6:15 pm

I wanted to repeat post 650 again with the CPU plugged directly into the socket, but the first pin I tried (pin 9) gave me readings of between 125-333mhz with some different shaped waves to those on post 648.

I can get readings however which I couldn't before.

Colin.

Quote:

Originally Posted by SiriusHardware

You have CPU activity now even with all ICs plugged in in their correct positions? If so, that's another decent step forward. I'm at work just now, will get back to you later.

ScottishColin · 2nd Mar 2021, 6:16 pm

Sorry Mark - could you point me at the post where I did this before? I'm learning fast but I'm not quite getting the meaning of your post.

Colin.

Quote:

Originally Posted by Mark1960

I think it would be good to check the data lines again with the duff prom replaced, see if DA0 is still showing low logic levels from one or more proms.

You could try first with the 6502 direct connected, but its not running NOP now so the pattern will be different and you might not be getting chip select on every prom now.

dave cox · 2nd Mar 2021, 6:47 pm

The 'NOP' gismo is now removed ?
All the other chips back in ?

dc

SiriusHardware · 2nd Mar 2021, 7:12 pm

Pulling a few things together: The steady frequencies you observed on A0-A15 with the NOP test in place won't be there when the machine is running 'normally' as it travels through the address range quite erratically when working normally, and will often spend a lot of time in a small loop of code and running through a relatively small address range.

Assuming you can remove and reinstate the NOP rig quite easily we may ask you to go back to that to do a little bit more fact finding.

However: While you still have all the ICs in the right places, and you hopefully still have activity, even though irregular, on the low address lines, could you just try scoping UH7 pin 2. If you see activity there, also scope UG10 pin 11 and UG11 pin 6.

If we don't have activity on UH7 pin 2, then continue as Mark said: Put the NOP rig back in and do as you were doing before to see if all of the PROMs now output full height data on all of their data pins when they are selected.

ScottishColin · 2nd Mar 2021, 7:18 pm

Correct.

Colin.

Quote:

Originally Posted by dave cox

The 'NOP' gismo is now removed ?
All the other chips back in ?

dc

ScottishColin · 2nd Mar 2021, 7:23 pm

Nothing on UH7/2, UG10/11 or UG11/6.

re the re-test - do you mean for example post 705?

Colin.

Quote:

Originally Posted by SiriusHardware

Pulling a few things together: The steady frequencies you observed on A0-A15 with the NOP test in place won't be there when the machine is running 'normally' as it travels through the address range quite erratically when working normally, and will often spend a lot of time in a small loop of code and running through a relatively small address range.

Assuming you can remove and reinstate the NOP rig quite easily we may ask you to go back to that to do a little bit more fact finding.

However: While you still have all the ICs in the right places, and you hopefully still have activity, even though irregular, on the low address lines, could you just try scoping UH7 pin 2. If you see activity there, also scope UG10 pin 11 and UG11 pin 6.

If we don't have activity on UH7 pin 2, then continue as Mark said: Put the NOP rig back in and do as you were doing before to see if all of the PROMs now output full height data on all of their data pins when they are selected.

SiriusHardware · 2nd Mar 2021, 7:38 pm

That would have been too easy I suppose (you were looking for video and sync signals, but you don't appear to have them).

OK then:-

Reinstate the NOP rig so we can go back to those nice regular address and CS signals,

For each PROM in turn, with channel 1 of the scope on the PROM's CS1 pin (20), use channel 2 of the scope to look at the signals on DA0 to DA7, ideally at the 6502 socket pads, but if not, wherever you can get to them.

You need not post captures of all 28 instances, just make sure the data on those data lines is at reasonable logic '0' and logic '1' voltages in all cases. If you see anything which looks 'wrong' then by all means capture it and let us have a look.

ScottishColin · 2nd Mar 2021, 7:59 pm

They all have what I think are reasonable signals.

Couple of things:

1) I'm not always getting a reading from pin 20 (see attached file for an example)
2) UD7 signals are noticably stronger than 6, 8 or 9 (again, see attached comparison)

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

Colin.

Quote:

Originally Posted by SiriusHardware

That would have been too easy I suppose (you were looking for video and sync signals, but you don't appear to have them).

OK then:-

Reinstate the NOP rig so we can go back to those nice regular address and CS signals,

For each PROM in turn, with channel 1 of the scope on the PROM's CS1 pin (20), use channel 2 of the scope to look at the signals on DA0 to DA7, ideally at the 6502 socket pads, but if not, wherever you can get to them.

You need not post captures of all 28 instances, just make sure the data on those data lines is at reasonable logic '0' and logic '1' voltages in all cases. If you see anything which looks 'wrong' then by all means capture it and let us have a look.

Timbucus · 2nd Mar 2021, 8:23 pm

they look fine - as long as you do see something on Pin 20 it is possible that code is not executing very often or even at all. That is a finding.

The difference in signal height is from different devices driving the line. While the signal is high on the second capture to the left something is driving up to 4v which is typical of a TTL device (it does not go full 0-5) the 5v you see later is because either something with a 5V pullup is let onto the bus or it is a CMOS drive which does go rail to rail.

SiriusHardware · 2nd Mar 2021, 8:42 pm

Quote:

it is possible that code is not executing very often or even at all.

That only applies if the system is running in 'normal' mode. It should be back in NOP mode for these tests in which case all of the PROMs should be selected for the same length of time.

I think Colin may just mean that he doesn't always catch the falling edge of the select signal in his capture. The fact that the select signal is low all the way through the capture still means that the data activity being observed is happening during that chip select period, as long as the scope probe really does have a connection to pin 20 of course.

Colin makes a good observation regarding the different data output strengths from UD7 vs. the rest of the PROMs, that is not unexpected as UD7 is a physically different type of device to the others.

2nd Mar 2021, 2:11 pm	#743
dave cox Nonode Join Date: Jan 2009 Location: Bristol, UK. Posts: 2,061	Re: Non-working Commodore PET 3016 Thx for link julie_m

2nd Mar 2021, 2:27 pm	#744
dave cox Nonode Join Date: Jan 2009 Location: Bristol, UK. Posts: 2,061	Re: Non-working Commodore PET 3016 I think Mark1960 mentioned a higher sample rate earlier. To get a reliable indication of the 'level' of a logic signal you need a sample clock, as a minimum, at approx 20X the system clock. On this 1MHz system that means at least 20M sample/second. Your scope will indicate the sample rate on the display somewhere. Why 20X ? To satisfy the Nyquist criterion, you need to sample at 2X the frequency you want to observe or you may discover the nasty world of aliases - this will be very misleading! For logic signals, we are looking at square waves and to get a reasonable approximation to a square wave you need to see >= 10 harmonics of the fundamental frequency. For a 1MHz square wave you really need to see up to 10MHz sine-wave and to see a 10MHz sine-wave you need a 20MHz sample rate! dc

2nd Mar 2021, 2:31 pm	#745
dave cox Nonode Join Date: Jan 2009 Location: Bristol, UK. Posts: 2,061	Re: Non-working Commodore PET 3016 This is what a 10 harmonic square wave looks like ... (lifted from https://www.prosoundweb.com) Attached Thumbnails

2nd Mar 2021, 4:16 pm	#747
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,553	Re: Non-working Commodore PET 3016 If the PROMs have been mixed up since you got them back and since before you got the new UD7, consider trying the computer with all the PROMs in the right places and the CPU inserted directly, just in case it then works.

2nd Mar 2021, 5:03 pm	#749
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,553	Re: Non-working Commodore PET 3016 You have CPU activity now even with all ICs plugged in in their correct positions? If so, that's another decent step forward. I'm at work just now, will get back to you later.

2nd Mar 2021, 5:25 pm	#750
Mark1960 Octode Join Date: Mar 2020 Location: Kitchener, Ontario, Canada Posts: 1,294	Re: Non-working Commodore PET 3016 I think it would be good to check the data lines again with the duff prom replaced, see if DA0 is still showing low logic levels from one or more proms. You could try first with the 6502 direct connected, but its not running NOP now so the pattern will be different and you might not be getting chip select on every prom now.

2nd Mar 2021, 6:47 pm	#753
dave cox Nonode Join Date: Jan 2009 Location: Bristol, UK. Posts: 2,061	Re: Non-working Commodore PET 3016 The 'NOP' gismo is now removed ? All the other chips back in ? dc

2nd Mar 2021, 7:12 pm	#754
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,553	Re: Non-working Commodore PET 3016 Pulling a few things together: The steady frequencies you observed on A0-A15 with the NOP test in place won't be there when the machine is running 'normally' as it travels through the address range quite erratically when working normally, and will often spend a lot of time in a small loop of code and running through a relatively small address range. Assuming you can remove and reinstate the NOP rig quite easily we may ask you to go back to that to do a little bit more fact finding. However: While you still have all the ICs in the right places, and you hopefully still have activity, even though irregular, on the low address lines, could you just try scoping UH7 pin 2. If you see activity there, also scope UG10 pin 11 and UG11 pin 6. If we don't have activity on UH7 pin 2, then continue as Mark said: Put the NOP rig back in and do as you were doing before to see if all of the PROMs now output full height data on all of their data pins when they are selected.

2nd Mar 2021, 7:38 pm	#757
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,553	Re: Non-working Commodore PET 3016 That would have been too easy I suppose (you were looking for video and sync signals, but you don't appear to have them). OK then:- Reinstate the NOP rig so we can go back to those nice regular address and CS signals, For each PROM in turn, with channel 1 of the scope on the PROM's CS1 pin (20), use channel 2 of the scope to look at the signals on DA0 to DA7, ideally at the 6502 socket pads, but if not, wherever you can get to them. You need not post captures of all 28 instances, just make sure the data on those data lines is at reasonable logic '0' and logic '1' voltages in all cases. If you see anything which looks 'wrong' then by all means capture it and let us have a look.

2nd Mar 2021, 8:23 pm	#759
Timbucus Octode Join Date: Mar 2019 Location: Barry, Vale of Glamorgan, Wales, UK. Posts: 1,363	Re: Non-working Commodore PET 3016 they look fine - as long as you do see something on Pin 20 it is possible that code is not executing very often or even at all. That is a finding. The difference in signal height is from different devices driving the line. While the signal is high on the second capture to the left something is driving up to 4v which is typical of a TTL device (it does not go full 0-5) the 5v you see later is because either something with a 5V pullup is let onto the bus or it is a CMOS drive which does go rail to rail.