25th May 2022, 6:52 pm | #141 | |
Octode
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,762
|
Re: Perth PET
They're E7 and E8 and I tried that earlier on today as I have a spare chip. No change.
I have a spare 6520 which I could use from the 4040 disk drive which I could try in UC7 and let you know. A tiny bit more info - the screen is more recognisably a PET boot screen, but still with random characters dotted around. There is a flashing cursor but the keyboard doesn't work. If I connect a tape drive at boot, it spins for a small amount of time as normal. Colin. Quote:
|
|
25th May 2022, 7:05 pm | #142 | ||
Octode
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,762
|
Re: Perth PET
My bad - it's a 6522 in the disk drive so I can't use that. I did swap UC7 and UC6 6520s with no difference.
Colin. Quote:
|
||
25th May 2022, 7:26 pm | #143 |
Nonode
Join Date: May 2004
Location: Halifax, West Yorkshire, UK.
Posts: 2,583
|
Re: Perth PET
|
25th May 2022, 8:02 pm | #144 |
Octode
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,762
|
Re: Perth PET
Swapped the disk drive 6522 into UC5 - no difference.
As a note, the Tynemouth board has a push-to-reset switch on it; if I reset it, I still get no keyboard input but all the screen corruption goes away. Colin. |
25th May 2022, 8:11 pm | #145 | |
Nonode
Join Date: May 2004
Location: Halifax, West Yorkshire, UK.
Posts: 2,583
|
Re: Perth PET
Quote:
Alan |
|
25th May 2022, 8:27 pm | #146 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
Re: Perth PET
I do remember from past times that Colin has often recorded supply voltages over and above 5.0V. Can we ask for the present voltages from the two +5V regulators be measured with a meter? The voltage from one can be measured on the non-ringed end of diode CR10, and the voltage from the other can be measured on the non-ringed end of CR11.
As to the main problems, let's recap: Transactions which take place over the unbuffered databus? - all of them, even the ones going to and from devices which are on the buffered data bus, at least for a short distance between the CPU and the UE9 and UE10 buffers. Transactions which take place entirely over the unbuffered data bus include reads from the PROMs and bidirectional communications with the keyboard controller PIA UC7, The user port VIA UC5, and the IEEE-488 PIA UC6. Transactions which take place initially or ultimately over the unbuffered data bus, but mostly over the buffered data bus via UE9 / UE10 include writes to and reads from system RAM and writes to and reads from video RAM, where the data also passes through additional buffers UE7 and UE8. So with that in mind, let's consider the behaviour of the machine with (a) the Tynemouth Board and (b) the normal setup, with or without a diagnostic PROM. My understanding of the way the Tynemouth Board (hereafter abbreviated to 'TB') works is that its ROM and RAM are internal so the TB does not need to venture onto the motherboard databus when it is reading from its internal ROM and reading from or writing to its internal RAM. It is probably only running into trouble when it does venture onto the motherboard data bus, as it eventually must, firstly, to write initial content to the video RAM (via the unbuffered databus initially, and then through UE9/UE10 to the buffered databus and onwards through UE7 and UE8 to the video RAM). Secondly, to communicate bidirectionally over the unbuffered data bus with the keyboard controller in particular. The common choke point for both of these failing TB operations is the unbuffered data bus. Taking the case where the system is not able to execute code at all even in its normal operational mode with motherboard ROMs, motherboard RAMs, etc, all that needs to work for the CPU to be able to read and execute code from a motherboard based diagnostic PROM is for the address output lines to be working, the address decoder to be working - and for the unbuffered data bus to be intact and working between the PROMs and CPU. You can see where I might be going with this. A fault on the unbuffered data bus could be the cause of all the behaviours described above. Colin has already scoped the bus on both sides of the UE9/UE10 buffers but only in a very basic way. So my suggestion, after checking the +5V supply voltages with a meter, is to fit the CPU in the mainboard socket, fit the Slothie EPROM in its adaptor in the UD9 position and temporarily remove PROMs UD6, UD7, UD8, and 'Big Chips' UC5, UC6 and UC7. When removing the PROMs in particular, please note carefully which one goes where. This should leave only the following major elements still in place on the unbuffered databus: - CPU, which has been eliminated by substitution already. - Slothie EPROM - the fault is present regardless of whether this part is fitted or not, so this is unlikely to be the problem. - The UE9/UE10 data bus buffers - now these are a possible suspect but we need to leave them in place so that the diagnostic EPROM, if it manages to run, can try to write the results to the video RAM through those buffers and also communicate with the system RAM (to run tests) through those buffers as well. Let's see if the Slothie Eprom manages to start with that configuration. Last edited by SiriusHardware; 25th May 2022 at 8:52 pm. |
25th May 2022, 8:34 pm | #147 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
Re: Perth PET
Oh, and if you have that BASIC toolkit PROM fitted in UD5 position, remove that as well.
|
25th May 2022, 10:07 pm | #148 |
Octode
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,762
|
Re: Perth PET
OK - one at a time.
Voltage at CR10 - 5.4v Voltage at CR11 - 5.4v Colin. |
25th May 2022, 10:13 pm | #149 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
Re: Perth PET
That is slightly on the high side but I would not say dangerously so. It is a fixed value determined by the internal circuitry of the 5V regulators, you can't adjust it.
|
25th May 2022, 10:14 pm | #150 |
Octode
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,762
|
Re: Perth PET
So. 6502 installed, Slothie ROM installed into UD9. All other ROMs removed from UD8/7/6 (none in UD5).
Both 6520s removed from UC7 and UC6, 6522 removed from UC5. Still get the screen attached and no Slothie ROM messages. Colin. |
25th May 2022, 10:19 pm | #151 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
Re: Perth PET
OK, remind me again, last time, did we replace both UE9 and UE10..?
or... only one? |
25th May 2022, 10:21 pm | #152 |
Octode
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,762
|
Re: Perth PET
|
25th May 2022, 10:26 pm | #153 |
Octode
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,762
|
Re: Perth PET
By the way I still have the NOP tester soldered to pins 8 and 16 of UG4. Should I remove that? It's not inserted into UC4.
Colin. |
25th May 2022, 10:37 pm | #154 | |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
Re: Perth PET
Quote:
If they had both been socketed I would have suggested replacing them both or one at a time and repeating the check from #146. You can try substituting UE10 of course but it is almost inevitable that if one of them is jamming the data bus it will be the one which is 40 years old and not in a socket. Do repeat the experiment with an alternative UE10 if you have one, if the result is the same remove the CPU and the Slothie Eprom and with power off, make resistance checks from the following UE9 pins and UE9 pin 10, and the same UE9 pins and UE9 Pin 20. In order to be consistent put the black probe on UE9 pin 10 when doing the checks to that pin, and put the red probe on UE9 pin 20 when doing the checks to that pin. As in the past, you are looking for one pin which looks suspiciously unlike the others, resistance measurement wise. UE9 pins to measure from to pin 10 and pin 20 = Pins 2 and 3 Pins 4 and 5 Pins 6 and 7 Pins 8 and 9 Edit: Having power connected to the NOP device is bad only in the sense that if it flops around and hits something it could do some damage. Make sure it can't make contact with anything else. |
|
25th May 2022, 10:47 pm | #155 | ||
Octode
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,762
|
Re: Perth PET
I have no continuity from any pins to either pin 10 or pin 20 on UE9.
As a matter of interest, I do have a reading from pin 20 to pin 10 of 72.4 Ohms. Is that significant? Also, is it worth me performing comparative frequency tests from the pins on UE9 and UE10 to see if there is any difference. Like this one we did before in post 1422? https://www.vintage-radio.net/forum/...t=UE10&page=72 Colin. Quote:
|
||
25th May 2022, 10:53 pm | #156 | |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
Re: Perth PET
Quote:
I think you have one meter with manual range setting, try winding that up through the resistance ranges until you do see a resistance between UE9 pin 10 and UE9 pins 2/3, and then compare the other three pairs of pins with that reading. Unlike the address buses when under NOP control, we don't really expect to see constant frequencies on the data bus. Resistance from pin 20 to pin 10 is just the combined parallel resistance of every IC which is still connected across the +5V power rails, you would expect that to be quite a low resistance. Last edited by SiriusHardware; 25th May 2022 at 11:02 pm. |
|
25th May 2022, 11:01 pm | #157 |
Octode
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,762
|
Re: Perth PET
OK - apologies. All UE9 Pin 10 or Pin 20 readings are between 3.623 and 3.625M ohms.
I ran the same test on UE10 and they are between 4.009 and 4.015 M ohms. Colin. |
25th May 2022, 11:33 pm | #158 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
Re: Perth PET
Was worth a try, but not conclusive in this case.
Going to have to call it a night for now, sorry, as I get up at 6:20 these days (change of hours at work) and I'm practically sliding under the table. I (and hopefully others) will have a think about where to go next. |
25th May 2022, 11:42 pm | #159 |
Octode
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,762
|
Re: Perth PET
No problem at all. Thanks again for your help.
I have an appropriate socket and a spare chip - perhaps replace UE9 anyway tomorrow? Colin. |
25th May 2022, 11:48 pm | #160 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
|
Re: Perth PET
That's up to you, you know our philosophy was always to try to establish reasonable doubt before replacing something but those buffers have a poor reputation for reliabilty so it might not be a bad idea to make it easy to rule that chip out on this and any future occasions. When UE10 had failed last time around, it did so in a way which was only affecting data coming from the buffered data bus to the unbuffered data bus - the unbuffered data bus was not affected by the fault on UE10 so it didn't stop the test code from running.
The conjecture this time is that a fault on one of UE9's CPU-side elements could be interfering with the databus on the unbuffered side, corrupting the data flowing from the PROMs to the CPU and preventing code in the PROMs from being run. I was thinking we might try scoping the data bus in a more scientific way before replacing UE9, can you say whether your scope only has two inputs, does it by any chance have an EXT TRIG input in addition to the channel 1 / channel 2 inputs? I'll check back in for the answer tomorrow. Last edited by SiriusHardware; 25th May 2022 at 11:54 pm. |