18th Feb 2021, 8:50 pm | #601 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,586
|
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? |
18th Feb 2021, 9:42 pm | #602 |
Octode
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,821
|
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. |
18th Feb 2021, 9:49 pm | #603 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,586
|
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. |
18th Feb 2021, 11:55 pm | #604 |
Octode
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,298
|
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.
|
19th Feb 2021, 3:18 am | #605 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,586
|
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 |
20th Feb 2021, 1:26 pm | #606 | |
Octode
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,821
|
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:
|
|
20th Feb 2021, 1:37 pm | #607 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,586
|
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.
|
21st Feb 2021, 7:19 pm | #608 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,586
|
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). |
21st Feb 2021, 8:00 pm | #609 |
Dekatron
Join Date: May 2008
Location: Derby, UK.
Posts: 7,735
|
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. |
21st Feb 2021, 8:20 pm | #610 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,586
|
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. |
21st Feb 2021, 9:26 pm | #611 | |||
Dekatron
Join Date: May 2008
Location: Derby, UK.
Posts: 7,735
|
Re: Non-working Commodore PET 3016
Quote:
Quote:
Quote:
__________________
If I have seen further than others, it is because I was standing on a pile of failed experiments. |
|||
21st Feb 2021, 9:45 pm | #612 | |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,586
|
Re: Non-working Commodore PET 3016
Quote:
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. |
|
22nd Feb 2021, 9:45 pm | #613 |
Octode
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,821
|
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. |
22nd Feb 2021, 11:16 pm | #614 |
Octode
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,298
|
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. |
22nd Feb 2021, 11:23 pm | #615 | |
Octode
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,821
|
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:
|
|
22nd Feb 2021, 11:46 pm | #616 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,586
|
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 11:52 pm. |
23rd Feb 2021, 12:15 am | #617 |
Octode
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,298
|
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. |
23rd Feb 2021, 12:22 am | #618 |
Octode
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,298
|
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.
|
23rd Feb 2021, 12:41 am | #619 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,586
|
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. |
23rd Feb 2021, 4:12 pm | #620 | |
Octode
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,821
|
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:
|
|