UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio and TV Service Data

Go Back   UK Vintage Radio Repair and Restoration Discussion Forum > Specific Vintage Equipment > Vintage Computers

Notices

Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment.

Reply
 
Thread Tools
Old 18th Feb 2021, 7:50 pm   #601
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 7,060
Default Re: Non-working Commodore PET 3016

Replaced:
Clock divider UG5,
Address buffers UE9 / UE10,
PROM UD7.

Of these, UE9 and UE10 did appear faulty to a degree as their outputs were not really driving low enough.

UD7 was dud, the other three main PROMs were OK.

We still seem to have an apparent problem with the CPU reading one of the illicit 'KIL' instructions when all of the data lines are connected.

We have a bit of a catch-22 situation where we can't connect all the CPU data lines so we can't properly observe what is happening with the data bus buffers, or at least on certain lines on those.

Do we go for replacement of the data bus buffers, or try something else? A NOP test to exercise the address lines and chip selects, perhaps?
SiriusHardware is offline   Reply With Quote
Old 18th Feb 2021, 8:42 pm   #602
ScottishColin
Heptode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 647
Default Re: Non-working Commodore PET 3016

Also replaced:

UB3/UC3 ICs and sockets with new ones. The 6502 socket (UC4) has been replaced with a new one and I have a new replacement 6502 should we need to use it for any investigations, although I don't believe we think that the 6502 is at fault here - the faults exhibited happen with both old and new 6502 ICs.

I've not replaced UE9/UE10 yet by the way.

Colin.
ScottishColin is offline   Reply With Quote
Old 18th Feb 2021, 8:49 pm   #603
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 7,060
Default Re: Non-working Commodore PET 3016

Duh, sorry, I meant UB3 and UC3, as you have probably guessed.

We may have to look at changing UE9 / UE10 next - same part, same age, similar function to the not very healthy ones which were being used as UB3 / UC3. Let's see if anyone wants to try something else first.

Although you could try scoping on both sides of the data buffers as you did with the address buffers it would be more difficult to draw a conclusion from what you find because the CPU will not keep running unless you disconnect some of the data bus pins.
SiriusHardware is offline   Reply With Quote
Old 18th Feb 2021, 10:55 pm   #604
Mark1960
Heptode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 638
Default Re: Non-working Commodore PET 3016

I think scoping the data lines each side of the data buffers with the 6502 data lines disconnected might be a good indication if the buffers are working correctly, at least in the direction towards the 6502, which would be the most likely source of a KIL instruction.
Mark1960 is offline   Reply With Quote
Old 19th Feb 2021, 2:18 am   #605
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 7,060
Default Re: Non-working Commodore PET 3016

Colin, could you please scope the following pairs of pins for us, this time with the data pins 26-33 of the CPU disconnected from the system so that the CPU will run. I know it runs with just several data pins connected but we need all the data buffer outputs on the CPU side to be connected to the same thing (...nothing).

UE9
2,18
4,16
6,14
8,12

UE10
2,18
4,16
6,14
8,12
SiriusHardware is offline   Reply With Quote
Old 20th Feb 2021, 12:26 pm   #606
ScottishColin
Heptode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 647
Default Re: Non-working Commodore PET 3016

Hi - I'll get on with this today and report back.

fyi I have got two new ICs and sockets for UE9/10 if we decide they need replacing.

Colin.


Quote:
Originally Posted by SiriusHardware View Post
Colin, could you please scope the following pairs of pins for us, this time with the data pins 26-33 of the CPU disconnected from the system so that the CPU will run. I know it runs with just several data pins connected but we need all the data buffer outputs on the CPU side to be connected to the same thing (...nothing).

UE9
2,18
4,16
6,14
8,12

UE10
2,18
4,16
6,14
8,12
ScottishColin is offline   Reply With Quote
Old 20th Feb 2021, 12:37 pm   #607
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 7,060
Default Re: Non-working Commodore PET 3016

Good forward thinking, I have a feeling we may have to ask you to do that if the results of any scope tests are inconclusive.
SiriusHardware is offline   Reply With Quote
Old 21st Feb 2021, 6:19 pm   #608
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 7,060
Default Re: Non-working Commodore PET 3016

Incidentally, Colin very kindly sent me two nice Commodore-logo coasters by way of a thank you for verifying his PROMs. He makes them himself, by the way.

What he didn't know was how much they would be appreciated. I have quite a fondness for retro computer themed everyday items. (see attached image).
Attached Thumbnails
Click image for larger version

Name:	Colins_Commodore_Coaster.jpg
Views:	50
Size:	80.3 KB
ID:	227300  
SiriusHardware is offline   Reply With Quote
Old 21st Feb 2021, 7:00 pm   #609
julie_m
Dekatron
 
Join Date: May 2008
Location: Derby, UK.
Posts: 7,732
Default Re: Non-working Commodore PET 3016

For what it's worth, all the KIL instructions on the 6502 have the form xxxx0010. (Only 10100010 is a valid instruction, LDX #n.) All instructions of the form xxxx0000 except 10000000 are valid instructions, and 10000000 at least terminates properly despite not doing anything useful.

If the buffer driving D1 of the 6502 can't pull its zeros low enough, then an innocuous xxxx0000 instruction will look like xxxx0010. Now looking at the instruction table, xxxx0000 includes all the conditional branch instructions, JSR, RTS, BRK, RTI, LDY #n, CPY #n and CPX #n; which are all reasonably common instructions, since any program is bound to use at least a few loops and subroutines, and the PET's operating system almost certainly will be making use of interrupts to deal with the hardware. So it's almost certain to encounter one of these instructions. And a fault causing D1 to read high would turn anything but LDY #n into a KIL instruction.

Now, if I'm reading the diagram correctly, the D1 signal is on 6502 (UC4) pin 32, UE9 pins 4 and 5; the buffered version is on pins 15 and 16. (There are pairs of pins tied together, because each line in the data bus can be an input or an output. Each 74LS244 has four buffers going "left to right" with a common output enable which can turn them all high-impedance, and four buffers going "right to left" with a separate common output enable.)

It might be a job proving much from the 'scope traces, though, if the processor dies straight away; if you disconnect pin 32 of the CPU then the buffer output will have no load on it, and suddenly find itself capable of driving its zeros nice and low again.

(Maybe a temporary pull-down resistor on CPU pin 32 would help UE9 drive its 0s a bit lower? Too small a value would leave it with the opposite problem: unable to drive its 1s high enough, though. Still, if it can be made to run even a bit longer before failing, that would tend to indicate a problem there.) It might also be worth noting that xxxx0011 instructions always complete, so you could leave pin 33 of the CPU unconnected while probing UE9 pin 5. If the 0s don't seem to be going all the way down to 0V, that's the problem.
__________________
If I have seen further than others, it is because I was standing on a pile of failed experiments.
julie_m is offline   Reply With Quote
Old 21st Feb 2021, 7:20 pm   #610
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 7,060
Default Re: Non-working Commodore PET 3016

Thanks for the detail, you obviously know your 6502 very well. I'm hoping in the first instance that if there is a fault on one of the buffers it will make itself more obviously known and not be as subtle as you suggest.

If not, we'll try as you say, but as Colin already has a couple of replacements 'on shed' it may ultimately be more straightforward to replace them to rule them in or out - they are after all the same device, possibly the same batch, same age, performing a similar function to the address buffers which weren't working very well.
SiriusHardware is offline   Reply With Quote
Old 21st Feb 2021, 8:26 pm   #611
julie_m
Dekatron
 
Join Date: May 2008
Location: Derby, UK.
Posts: 7,732
Default Re: Non-working Commodore PET 3016

Quote:
Originally Posted by SiriusHardware View Post
Thanks for the detail, you obviously know your 6502 very well.
Thanks for the compliment! Sign of a mis-spent youth, probably.
Quote:
Originally Posted by SiriusHardware View Post
I'm hoping in the first instance that if there is a fault on one of the buffers it will make itself more obviously known and not be as subtle as you suggest.
Yes, perhaps I was being a bit pessimistic. Mind, anything's going to look a bit disappointing after that absolute money shot of the fault on the address buffers! It will all depend on the nature of the fault. Pin 5 seems not to be pulling low enough, but will it do it with the CPU disconnected?
Quote:
Originally Posted by SiriusHardware View Post
If not, we'll try as you say, but as Colin already has a couple of replacements 'on shed' it may ultimately be more straightforward to replace them to rule them in or out - they are after all the same device, possibly the same batch, same age, performing a similar function to the address buffers which weren't working very well.
Indeed; and I'm confident that replacing UE9 and UE10 will produce some improvement. Maybe even a BASIC prompt, although that's probably a little too much to hope for.
__________________
If I have seen further than others, it is because I was standing on a pile of failed experiments.
julie_m is offline   Reply With Quote
Old 21st Feb 2021, 8:45 pm   #612
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 7,060
Default Re: Non-working Commodore PET 3016

Quote:
Originally Posted by julie_m View Post
anything's going to look a bit disappointing after that absolute money shot of the fault on the address buffers!
Not to mention a definitely duff UD7 PROM as well.

It's looking like this one is going to be a slow uphill slog. The potential damage from damp is what concerns me most, there could be one or more open circuit / corroded VIAs. The oxidisation on the pins of the PROMs was really quite severe, if every tinned surface and solder joint on the PCB is like that then Colin has done very well to remove the devices he has so far replaced with relatively small damage.

Among other things, I work on door entry access panels which are usually mounted on outside walls - if the rain seals get damaged or the panel isn't sealed up tight enough and the board gets wet, stays wet for a while and then dries the solder can turn into something which behaves almost entirely unlike solder, no amount of heat from an iron will melt it unless you carefully scratch through the dull grey surface with a fine point to make it all shiny again. That takes a lot of time and patience.

For the time being I think we have to focus on trying to get the CPU to keep running when all its pins are connected to the databus - if we can achieve that and that gives us video and sync signals then we are in with a chance.
SiriusHardware is offline   Reply With Quote
Old 22nd Feb 2021, 8:45 pm   #613
ScottishColin
Heptode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 647
Default Re: Non-working Commodore PET 3016

Evening - apologies for the delay. Here's the pretty inconclusive screen shots of the scope as requested.

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

Colin.
ScottishColin is offline   Reply With Quote
Old 22nd Feb 2021, 10:16 pm   #614
Mark1960
Heptode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 638
Default Re: Non-working Commodore PET 3016

Difficult to tell which text applies to which screenshot, is that just the way the ipad is rendering the document?

10v per division doesnít give a good resolution, but also doesnít seem to correlate with the scale of the signals, unless you have 100v in some of those.
Mark1960 is offline   Reply With Quote
Old 22nd Feb 2021, 10:23 pm   #615
ScottishColin
Heptode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 647
Default Re: Non-working Commodore PET 3016

Either Google Drive or LibreOffice has made a right ricket of that file - looks OK on my PC here though. Here's a PDF of the document which hopefully will be clearer.

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

Would it be preferable if I did the tests again with a 1V setting?

Colin.


Quote:
Originally Posted by Mark1960 View Post
Difficult to tell which text applies to which screenshot, is that just the way the ipad is rendering the document?

10v per division doesnít give a good resolution, but also doesnít seem to correlate with the scale of the signals, unless you have 100v in some of those.
ScottishColin is offline   Reply With Quote
Old 22nd Feb 2021, 10:46 pm   #616
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 7,060
Default Re: Non-working Commodore PET 3016

Possibly there is a mixup between the probe x 1 / x10 setting and the scope 'x1 / x10' setting. Certainly on one of the captures the size of the waveform seems unfeasibly high if the sensitivity really is 10V per division.

There are a couple of factors adding to the difficulties of interpreting these results:

One, quite a few of the system devices including the PROMs pass their data to and from the CPU directly, not through the databus buffers. Specifically, the devices on circuit sheets 2, 3, and 4.

Sheet 2: The 6520 which handles the IEEE interface.

Sheet 3: The 6522 and 6520 which handle various I/O functions, in particular the user port and keyboard scanning.

Sheet 4: The PROMs.

The other factor is that we don't know, when looking at these traces, when and whether the databus buffers are enabled and in which direction. We can only reasonably expect to see the buffered side mirror the unbuffered side when the buffers are either enabled going from buffered data bus to CPU, or enabled going from CPU to buffered data bus.

The devices I mentioned above are mostly in sockets. My suggestion before doing any more hardware work or chip replacement is to try reinstating the CPU data bus pins (which will stop the CPU from running, we know) and then try removing UC6 (6520), UC5 (6522) and UC7 (6520) one after the other and then all together to see if the CPU will run with one or more of them removed. By 'run', I mean continuous activity on the address lines, especially A0 (CPU pin 9).

Edit: With regard to the document posts looking a bit scrambled, they've always looked that way to me with the headings offset down the side somewhere but nobody else ever mentioned it so I thought it was just me. The PDF version looks much better so if it's as easy for you to do them that way, I admit that would be better for me in future.

Last edited by SiriusHardware; 22nd Feb 2021 at 10:52 pm.
SiriusHardware is offline   Reply With Quote
Old 22nd Feb 2021, 11:15 pm   #617
Mark1960
Heptode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 638
Default Re: Non-working Commodore PET 3016

The pdf is much easier to read for me too.

I think 2v per division would be a good compromise, but make sure the x10 settings on the probes match the settings on the scope.

Also I think change the horizontal timebase setting, to show more memory cycles. Maybe 10 to 20 us for the width of the plots.

There should be enough memory reads from prom to show some pulses correspond between inputs and outputs, but some of the plots show no match at all, which makes me doubt the buffers are working.
Mark1960 is offline   Reply With Quote
Old 22nd Feb 2021, 11:22 pm   #618
Mark1960
Heptode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 638
Default Re: Non-working Commodore PET 3016

I just re-read Siriusís last post, I didnít realise the proms were direct to the processor, so maybe not going to see the correlation between input and output on the buffers.
Mark1960 is offline   Reply With Quote
Old 22nd Feb 2021, 11:41 pm   #619
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 7,060
Default Re: Non-working Commodore PET 3016

It's still possible that a fault on the databus buffers is loading the unbuffered databus and stopping everything else on the unbuffered databus from working, so I think that ultimately the databus buffers are going to have to be replaced to rule them out. I think it's worth first removing as many of the unpluggable devices which are also on the unbuffered bus as we can to see if removing any of those allows the CPU to run.

It might be an idea to mark one of the 6520s with a paint dot or a sticky dot if they are not already distinctively marked in some way so that we always know which one was originally where. Unintentionally moving an (unknown) faulty device from one position to another could introduce a whole new level of weirdness, so for the time being we don't want any devices leaping from one place to another, even if they do have the same part number on them.
SiriusHardware is offline   Reply With Quote
Old 23rd Feb 2021, 3:12 pm   #620
ScottishColin
Heptode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 647
Default Re: Non-working Commodore PET 3016

Checked as below. I get no square waves with any combination of UC5,6 and 7 out, either singly or in pairs. Nor do I get anything different with all of UC5, 6 and 7 out. I checked the 6502 by using the socket with pins 26-33 removed and all of UC5, 6 and 7 inserted and I get square signals with that combination.

Colin.


Quote:
Originally Posted by SiriusHardware View Post
Possibly there is a mixup between the probe x 1 / x10 setting and the scope 'x1 / x10' setting. Certainly on one of the captures the size of the waveform seems unfeasibly high if the sensitivity really is 10V per division.

There are a couple of factors adding to the difficulties of interpreting these results:

One, quite a few of the system devices including the PROMs pass their data to and from the CPU directly, not through the databus buffers. Specifically, the devices on circuit sheets 2, 3, and 4.

Sheet 2: The 6520 which handles the IEEE interface.

Sheet 3: The 6522 and 6520 which handle various I/O functions, in particular the user port and keyboard scanning.

Sheet 4: The PROMs.

The other factor is that we don't know, when looking at these traces, when and whether the databus buffers are enabled and in which direction. We can only reasonably expect to see the buffered side mirror the unbuffered side when the buffers are either enabled going from buffered data bus to CPU, or enabled going from CPU to buffered data bus.

The devices I mentioned above are mostly in sockets. My suggestion before doing any more hardware work or chip replacement is to try reinstating the CPU data bus pins (which will stop the CPU from running, we know) and then try removing UC6 (6520), UC5 (6522) and UC7 (6520) one after the other and then all together to see if the CPU will run with one or more of them removed. By 'run', I mean continuous activity on the address lines, especially A0 (CPU pin 9).

Edit: With regard to the document posts looking a bit scrambled, they've always looked that way to me with the headings offset down the side somewhere but nobody else ever mentioned it so I thought it was just me. The PDF version looks much better so if it's as easy for you to do them that way, I admit that would be better for me in future.
ScottishColin is offline   Reply With Quote
Reply

Thread Tools



All times are GMT. The time now is 3:18 am.


All information and advice on this forum is subject to the WARNING AND DISCLAIMER located at https://www.vintage-radio.net/rules.html.
Failure to heed this warning may result in death or serious injury to yourself and/or others.


Powered by vBulletin®
Copyright ©2000 - 2021, vBulletin Solutions, Inc.
Copyright ©2002 - 2021, Paul Stenning.