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.

Closed Thread
 
Thread Tools
Old 11th Apr 2021, 6:58 pm   #1561
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,762
Default Re: Non-working Commodore PET 3016

Here's UC7 pins 2, 3, 4 and 5.

Colin.


Quote:
Originally Posted by SiriusHardware View Post
Yes, if you haven't already. The one we think there could be a problem with is UC7 pin 2 - UC9 pin 15 (Same signal line, different ICs, just to make sure the signal is present at both ends).

Disregard anything I said about UC9 pins 1 through 10, I was obviously having a bad day yesterday. As long as we have the expected signal on UC7 pin 2 / UC9 pin 15, the 74LS145 remains the prime suspect.
Attached Thumbnails
Click image for larger version

Name:	UC7 pin 2 - 20210411.jpg
Views:	42
Size:	41.3 KB
ID:	231506   Click image for larger version

Name:	UC7 pin 3 - 20210411.jpg
Views:	38
Size:	40.3 KB
ID:	231507   Click image for larger version

Name:	UC7 pin 4 - 20210411.jpg
Views:	38
Size:	38.5 KB
ID:	231508   Click image for larger version

Name:	UC7 pin 5 - 20210411.jpg
Views:	37
Size:	41.2 KB
ID:	231509  
ScottishColin is offline  
Old 11th Apr 2021, 7:02 pm   #1562
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,762
Default Re: Non-working Commodore PET 3016

Here's UC9 pins 12, 13, 14 and 15.

Colin.


Quote:
Originally Posted by SiriusHardware View Post
Yes, if you haven't already. The one we think there could be a problem with is UC7 pin 2 - UC9 pin 15 (Same signal line, different ICs, just to make sure the signal is present at both ends).

Disregard anything I said about UC9 pins 1 through 10, I was obviously having a bad day yesterday. As long as we have the expected signal on UC7 pin 2 / UC9 pin 15, the 74LS145 remains the prime suspect.
Attached Thumbnails
Click image for larger version

Name:	UC9 pin 12 - 20210411.jpg
Views:	40
Size:	40.8 KB
ID:	231510   Click image for larger version

Name:	UC9 pin 13 - 20210411.jpg
Views:	43
Size:	41.0 KB
ID:	231511   Click image for larger version

Name:	UC9 pin 14 - 20210411.jpg
Views:	42
Size:	41.2 KB
ID:	231512   Click image for larger version

Name:	UC9 pin 15 - 20210411.jpg
Views:	42
Size:	42.6 KB
ID:	231513  
ScottishColin is offline  
Old 11th Apr 2021, 7:02 pm   #1563
julie_m
Dekatron
 
Join Date: May 2008
Location: Derby, UK.
Posts: 7,735
Default Re: Non-working Commodore PET 3016

That's exactly what I was expecting to see; and it exonerates UC7, and pushes the blame towards UC9. Pins 12, 13, 14 and 15 are the 8s, 4s, 2s and units of a binary number which is counting up in sequence from 0000 (0) to 1001 (9).

It's probably time to think about ordering a replacement 74LS145 and a high-quality turned pin socket ..... 74HCT145 or 74HC145 probably would substitute fine, if needs must.
__________________
If I have seen further than others, it is because I was standing on a pile of failed experiments.
julie_m is offline  
Old 11th Apr 2021, 7:04 pm   #1564
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,762
Default Re: Non-working Commodore PET 3016

Already ordered. Hopefully here Tuesday.

Colin.


Quote:
Originally Posted by julie_m View Post
That's exactly what I was expecting to see; and it exonerates UC7, and pushes the blame towards UC9. Pins 12, 13, 14 and 15 are the 8s, 4s, 2s and units of a binary number which is counting up in sequence from 0000 (0) to 1001 (9).

It's probably time to think about ordering a replacement 74LS145 and a high-quality turned pin socket ..... 74HCT145 or 74HC145 probably would substitute fine, if needs must.
ScottishColin is offline  
Old 11th Apr 2021, 8:50 pm   #1565
ortek_service
Octode
 
ortek_service's Avatar
 
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 1,394
Default Re: Non-working Commodore PET 3016

Yes, agreed all inputs to UC9 do look OK and that UC9 has to be faulty from the symptoms found.

At first I wondered why UC9-15 ('A') was staying high most of the time, after a few pulses, whereas other inputs appeared to go return to low state most of the time when keyboard wasn't being scanned. But I then realised it was due this line being a '1' in the last input code, and checking the datasheet's BCD input code table (plus rechecking the 'scoped UC9-12 ('D') also finding that stayed high most of the time) did tie up with 1001 input code which sets the last UC9 output ('9' line) to be active (Low).

And there was no point in the PET's Kernal setting the 74LS145 input-lines code back 0000 etc. at end of scanning period, as there is always one output active unlike conventional direct parallel (non-demultiplexed/decoded) matrix scanned systems.
I presume the scanning is all done via regular interrupt timing, otherwise it would slow programs down a lot if it sat constantly reading the other (column) side of keyboard matrix, for the whole complete keyboard scan time.


So Keyboard should then be all working again, once UC9 (Hopefully the last entry on the IC casualties list!) is replaced, now that track has also been repaired. And hopefully won't need to resort to repairs on the any of the key's conductive plungers. These could all be measured for resistance, between the appropriate row and column lines on the connector, in conjunction with keyboard map table I posted a link to earlier - Although if all keys do now produce some response (even if incorrect character) then that's a good sign, and probably much easier to just check all keys work when its all running.

Last edited by ortek_service; 11th Apr 2021 at 8:55 pm.
ortek_service is offline  
Old 11th Apr 2021, 8:57 pm   #1566
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,762
Default Re: Non-working Commodore PET 3016

I have just recehcked what actually appears on the screen when the keys are pressed and it's all still the same as in post 1529 i.e. not right....

Colin.


Quote:
Originally Posted by ortek_service View Post
Yes, agreed all inputs to UC9 do look OK and that UC9 has to be faulty from the symptoms found.

At first I wondered why UC9-15 ('A') was staying high most of the time, after a few pulses, whereas other inputs appeared to go return to low state most of the time when keyboard wasn't being scanned. But I then realised it was due this line being a '1' in the last input code, and checking the datasheet's BCD input code table (plus rechecking the 'scoped UC9-12 ('D') also finding that stayed high most of the time) did tie up with 1001 input code which sets the last UC9 output ('9' line) to be active (Low).

And there was no point in the PET's Kernal setting the 74LS145 input-lines code back 0000 etc. at end of scanning period, as there is always one output active unlike conventional direct parallel (non-demultiplexed/decoded) matrix scanned systems.
I presume the scanning is all done via regular interrupt timing, otherwise it would slow programs down a lot if it sat constantly reading the other (column) side of keyboard matrix, for the whole complete keyboard scan time.


So Keyboard should then be all working again, once UC9 (Hopefully the last entry on the IC casualties list!) is replaced, now that track has also been repaired. And hopefully won't need to resort to repairs on the any of the key's conductive plungers. These could all be measured for resistance, between the appropriate row and column lines on the connector, in conjunction with keyboard map table I posted a link to earlier - Although if all keys do now produce some response (even if incorrect character) then that's a good sign, and probably much easier to just check all keys work when its all running.
ScottishColin is offline  
Old 11th Apr 2021, 9:07 pm   #1567
ortek_service
Octode
 
ortek_service's Avatar
 
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 1,394
Default Re: Non-working Commodore PET 3016

Yes, that's to be mostly-expected until you've (received &) changed UC9.

Although I had thought that the track-repair may have made a slight difference to some of the actual displayed responses
- if there was any of these where a key hadn't produced any (rather than just incorrect) response from pressing it.
ortek_service is offline  
Old 11th Apr 2021, 10:49 pm   #1568
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,762
Default Re: Non-working Commodore PET 3016

I wonder if you could doe a favour, and you might feel you've already done this, but could you put into like one syllable words for a 12 year old why you think UC9 is at fault from the screenshots I have provided?

I'll replace it and hopefully it'll.move us forwards, but I'm afraid I can't understand why it's at fault from the screenshots.

Apologies and thanks.

Colin.

Quote:
Originally Posted by ortek_service View Post
Yes, that's to be mostly-expected until you've (received &) changed UC9.

Although I had thought that the track-repair may have made a slight difference to some of the actual displayed responses
- if there was any of these where a key hadn't produced any (rather than just incorrect) response from pressing it.
ScottishColin is offline  
Old 11th Apr 2021, 11:44 pm   #1569
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,265
Default Re: Non-working Commodore PET 3016

The screenshots don’t show a fault, so now we know the inputs to the 74LS145 are correct, but the pattern of key response for keys pressed shows that odd and even rows of keys are giving the same response. The request for plots of the inputs to the 74LS145 was to make sure the problem wasn’t earlier in the circuit.
Mark1960 is offline  
Old 11th Apr 2021, 11:47 pm   #1570
ortek_service
Octode
 
ortek_service's Avatar
 
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 1,394
Default Re: Non-working Commodore PET 3016

Colin, What may be confusing you, is that the screenshots you have captured don't actually show the fault!
Measuring all the other ones that SiriusHardware had originally suggested, would have shown this, but they were a bit more involved to measure - requiring you to add extra pull-up resistors

However, what your screenshots do confirm is that the inputs to UC9 (74LS145) are all correct.
And we know that UC9's 10 outputs go straight to keyboard matrix's Row lines - with nothing else in the way, other than connectors

From your table of the responses you got from each key separately pressed, and looking at the layout of the keyboard, here: http://www.6502.org/users/andre/peti...ards.html#scan
(I couldn't find a decent correct schematic for your keyboard at the time, but this was adequate)
Then it can be seen that the incorrect responses are all in the same (0..7) 'column' as the key actually pressed
- but are just one row higher from it. e.g. (Both in Column 0): Q is in Row-2 and W is in Row-3


So for a Q to actually be read as W, then it can be seen that can only occur if the Kernal is setting the PIA to UC9 4-bit BCD code outputs to 0010, to try to read Row 2 it doesn't get any response as key 'Q'
- So the (Row) Output 2 from UC9, isn't going Low

But when the Kernal increments the 4-bit BCD code (to 0011) move on to read the next Row (3), both Q and W keys give the same 'W' key result - So the (Row) Outputs 2 AND 3 from UC9, must BOTH be going Low. (And hence it must be faulty)

A simple short between Rows Outputs 2 & 3, would probably produce a Q and a W or ignored, depending on how the Kernal firmware works.


And the same fault happens between other row pairs, like (also column 0) 'Z' (Row 6) & 'X' (Row 7), both giving an 'X'


Hopefully that explains it (and is a bit more involved than it first seemed to me, but appears to be the best explanation for what is happening)

Last edited by ortek_service; 11th Apr 2021 at 11:55 pm.
ortek_service is offline  
Old 11th Apr 2021, 11:58 pm   #1571
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Non-working Commodore PET 3016

Quote:
Originally Posted by ortek_service View Post
I presume the scanning is all done via regular interrupt timing, otherwise it would slow programs down a lot if it sat constantly reading the other (column) side of keyboard matrix, for the whole complete keyboard scan time..
Yes, one of the interrupt pins on one of the IO chips is connected to the vertical retrace signal, and the keyboard is scanned in the interrupt service routine which also adjust the real time clock, flashing cursor etc.
Slothie is offline  
Old 11th Apr 2021, 11:59 pm   #1572
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Non-working Commodore PET 3016

Each binary value which UC7 outputs on pins 2, 3, 4, 5, should select a particular output of UC9, but we knew from the analysis of the keys pressed / characters returned that either:

-Bit 0 of the 4-bit code was not being correctly output by UC7

or

-Bit 0 of the 4-bit code was being correctly output by UC7 but was being ignored / misinterpreted by UC9.

The latest results show that UC7 is generating the expected 4-bit codes and sending them to UC9, therefore we conclude that UC9 is not responding correctly to those 4-bit codes because it is faulty.

Last edited by SiriusHardware; 12th Apr 2021 at 12:11 am.
SiriusHardware is online now  
Old 12th Apr 2021, 12:24 am   #1573
julie_m
Dekatron
 
Join Date: May 2008
Location: Derby, UK.
Posts: 7,735
Default Re: Non-working Commodore PET 3016

Sorry, perhaps I should have made it clearer. The inputs to UC9 are absolutely spot on. That means the fault must lie in or downstream of UC9, but the only things between there and UC7 again are UC9 and the keyboard.

The keyboard is just a bunch of switches, so it is very unlikely to be at fault. Much more likely is the outputs of UC9 going low at the wrong times, and the only way that can happen is if UC9 itself is faulty.

If you want to prove it, connect each of UC9 pins 1-7 and 9-11 in turn via a 10K resistor to +5V, and put your probes on whichever pin of UC9 has the resistor and pin 15. If UC9 was working properly, you should see each output going low in time with a different one of the 10 states of pin 15 (low, high, low, high, low, high, low, high, low, hiiiiiiiiiiigh). This selects a group of just 8 keys from the keyboard, whose states will show on UC7 pins 10-17 as "low" if depressed or "high" if released.

But I think one of the outputs of UC9 is going low out-of-turn. This will cause a different group of keys to be read back than what the computer thinks it is asking about. It thinks it is asking about the group with W in it, but actually takes the common line low for the group containing Q. You press Q. It sees a key was pressed corresponding to W in the group it asked about, and so treats it as a W.

Is that any clearer?
__________________
If I have seen further than others, it is because I was standing on a pile of failed experiments.
julie_m is offline  
Old 12th Apr 2021, 12:57 am   #1574
ortek_service
Octode
 
ortek_service's Avatar
 
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 1,394
Default Re: Non-working Commodore PET 3016

This webpage also describes how the keyboard works (Where they too had a faulty 74LS145, but with just a missing row of keys): http://www.primrosebank.net/computer...s_keyboard.htm
- However their (UK) Keyboard Row / Column layouts doesn't match what seems to be on this particular 3016 PET, as Q & W are in both different rows & columns from info I'd previously posted a link to. And maybe clearer graphical image of that here https://i.redd.it/i3v45fyu5d751.png


But it seems the 8000-series at least also had a different matrix layout http://cbm.ko2000.nu/schematics/comp...032/320284.gif


There is also an annotated view of the 3032 PCB, so you can see what keys that broken track should have affected: http://www.zimmers.net/anonftp/pub/c...eyboardPCB.jpg


I also found this book on the PET, which has program listings for assisting with tape head alignment and other memory checks etc.
https://doc.lagout.org/science/0_Com...of_PET-CBM.pdf
ortek_service is offline  
Old 12th Apr 2021, 10:36 am   #1575
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Non-working Commodore PET 3016

Quote:
So the (Row) Outputs 2 AND 3 from UC9, must BOTH be going Low.
There is another potential explanation, which is that, due to a fault on its 'A' input, the 74LS145 is always seeing a 'high' or 'low' on that input.

Whether UC7 outputs 0000 or 0001, UC9 activates the same column output, rather than consecutive outputs - so for 50% of the possible code outputs from UC7, the wrong key column output is going low on UC9. This would be why we get 'W' when 'W' is pressed (correct) but we also get 'W' when 'Q' is pressed (incorrect).

The exact nature of the problem within UC9 is only a matter of nerdy technical interest: As long as replacing it fixes the fault I think I will be happy.

Last edited by SiriusHardware; 12th Apr 2021 at 10:41 am.
SiriusHardware is online now  
Old 12th Apr 2021, 3:24 pm   #1576
ortek_service
Octode
 
ortek_service's Avatar
 
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 1,394
Default Re: Non-working Commodore PET 3016

That's what I had thought at first, with the 74LS145's BCD-Input 'A' bit pin not functioning, being stuck high or low. So only half of the (Row) outputs from it were going low.

However, whilst trying to explain to Colin why the 74LS145 must be faulty from what we'd seen, I then realised that if only half of the (Row) outputs from it went low, then half of the keys on the matrix wouldn't actually do anything at all - Rather than what had been found in that all Key presses are detected, but half in the wrong (adjacent) Row.

Hence my explanation of about the only way I could see what was occurring
- even though it did seem to be a very strange internal failure of a 74LS145
ortek_service is offline  
Old 12th Apr 2021, 4:02 pm   #1577
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Non-working Commodore PET 3016

Yes, I see your reasoning.

It's a shame Colin doesn't have a friendly football team dropping by to visit, as they could then hold down all of the keys (to give us the required pullups) while he scopes the outputs of the 74LS145 so we could see what is happening. To be honest I don't think it's of vital importance as I feel really sure now that the 74LS145 is the culprit.

Last edited by SiriusHardware; 12th Apr 2021 at 4:13 pm.
SiriusHardware is online now  
Old 12th Apr 2021, 4:35 pm   #1578
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,762
Default Re: Non-working Commodore PET 3016

Thank you - I was looking for something that wasn't there....

Colin.


Quote:
Originally Posted by ortek_service View Post
Colin, What may be confusing you, is that the screenshots you have captured don't actually show the fault!
ScottishColin is offline  
Old 12th Apr 2021, 8:32 pm   #1579
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
Default Re: Non-working Commodore PET 3016

Just a heads up, my diagnostic s/w was checking the wrong place for the stack. Luckily it wasn't a problem for Colin. Any further progress on this project I will move to a new thread when that happens!
Slothie is offline  
Old 12th Apr 2021, 9:18 pm   #1580
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,484
Default Re: Non-working Commodore PET 3016

Even with that mild bug your test firmware was instrumental in getting the machine this far and I'm grateful that you sidelined whatever you meant to be doing the other evening to knock that tweaked version up for us instead.

Although Daver2's test firmware is obviously quite advanced in terms of what it does, the way it stalled on the screen test might have had us a a little bit perplexed if we had not had your alternative which was able to go past that point.

I would imagine it is very hard to write a comprehensive test suite in 2K when you have the crippling limitation of not being able to use either RAM or subroutines, at least initially.
SiriusHardware is online now  
Closed Thread

Thread Tools



All times are GMT +1. The time now is 10:24 pm.


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 - 2024, vBulletin Solutions, Inc.
Copyright ©2002 - 2023, Paul Stenning.