I’ve been giving some more thought to the next steps now there is more confidence in the security of the JP8/P4 connection. In the absence of an oscilloscope, logic probe or EPROM programmer there are still a few options in terms of eliminating possible reasons for the random character display and consequent failure to boot correctly. In no particular order these are a some of the possibilities which might be worth considering:
1. The 555 (UA2) timer circuit should reset the CPU a couple of seconds after switch on. If this doesn’t work correctly the random character screen doesn’t clear as highlighted by Slothie earlier. Operation of the circuit can be verified by monitoring the voltage on the reset pin (40) of the 6502 (UC4) CPU at switch on. The voltage should remain at 0V for a couple of seconds before rising to around 4V (steady). Pin 40 is in the top left corner of the 6502 when viewing the board from the opposite side to the power supply.
2. The PET doesn’t need the two PIAs (UC6 & UC7) in order to boot but faulty chips can cause the random character screen problem. Switching on the machine with the PIAs removed won’t harm the PET although if it does boot properly neither the keyboard nor the external interfaces will function. This is just a simple way of identifying faulty PIAs.
3. During the work so far there has been quite a lot of board manipulation/flexing and elderly PETs are well known for developing poor IC pin to socket contact. Rather than removing socketed ICs completely (fiddly with a risk of pin damage on re-insertion) I’d suggest the lift slightly, squirt with contact cleaner, rock and then push home firmly approach. I’d probably leave the processor and ROM chips alone in the first instance and just concentrate on the 15 socketed DRAMs.
4. In view of the fact(?) that the DRAMs are the only chips which rely on anything other than the +5V supply I still think they are the most likely candidates for damage caused by the JP8/P4 issue. See earlier post. If Sirius is able and willing to provide an EPROM with which to test for individual DRAM failure that would be ideal of course. However there are other ways to at least carry out some checks on the DRAMs. The attached document might help as it illustrates how the dynamic RAM board can be configured to operate with only eight 4116s, albeit at half capacity. With a bit of chip swapping it might be possible to identify groups containing one or more faulty chip(s) and arrive at a set of eight working chips thereby ruling out faults elsewhere on the board.
If none of the above suggestions bear fruit it’ll be necessary to start thinking about things like logic ICs, the CPU, ROMs and the like but in view of the previously working nature of the machine I’m hoping that won’t be necessary. I’ve also rather ignored the possibility of supply line failure somewhere along the line for the same reason.
Just throwing out some ideas really to help (hopefully) get us started on the next steps.
Alan