I had tried the unit one board previously, so I knew that it was not working. I had previously replaced the processor because the legs were corroded. (Later I tried cleaning it up, but it still did not work.) I also replaced the GPIB buffers as they were also corroded.
I did the set to work of the Unit 1 board in the already completed Unit 2 chassis.
The screen was not scanning, so I disconnected it.
There are lots of things that could go wrong, and this board is a little more challenging than the other one because most of the larger ICs are soldered down. This makes it difficult to just swap them out. On the plus side, the socketed ICs tend to be more corroded than those that are soldered in.
The power supplies were good, the clock was good, and the reset was good.
The most likely cause of failure was RAM, but there had been no RAM failures on the other board. I probably should have just replaced the lot, but you don’t learn much doing things that way and the thought of cutting out 16 RAM chips didn’t fill me with joy. I did it the hard way.
It’s relatively easy to see when the ROMs are accessed. The 6502 resets to FC00, which is in the kernal (sic) ROM. The webs suggested that the kernal calls an initialisation routine in the Edit ROM at E000.
It’s in here:
http://www.zimmers.net/anonftp/pub/cbm/src/pet/pet_rom4_disassembly.txt
The vector at FC00 jumps to FD16. The call to E000 is made at FD1B just after the stack is initialised. This listing shows the edit ROM, but there are many edit ROMs.
This one seems to match reasonably well with the 50Hz 80 column ROM used in this board:
Using this I could use the scope to read the address lines on the ROM one at a time to get the address. (it’s moments like these when a logic analyser would be handy but there’s not much that can’t be done with a good scope and some time.) I added a reset button (between UD16-2 and ground) and the timing is repeatable with respect to the reset (which can be conveniently picked up on pin 40 of the processor). This is partly because the system is so slow (1us per bus cycle) that there is time for both an access and a refresh. Not all machines are so deterministic.
CAS cycles (R10) identify accesses to RAM. Accesses to VIA/PIA are trickier because they use multiple chip selects. They are tucked into the E800 to EFFF space next to the Edit ROM, which is only 2k. The other ROMs are nominally 4k.
The map is here:
https://www.zimmers.net/cbmpics/cbm/PETx/petmem.txt
I looked for where the processor seemed to lose its way and used ROM addresses to work out where execution was in the ROM.
Suspecting RAM I looked for the first time there was a critical RAM read eg a subroutine return which I expected to be two back to back reads – it turned out to be three. Similarly, I expected a call to be two writes, but they are always one read and two writes. I still don’t understand this, but maybe the penny will drop one day.
Sure enough, the first return was just before the processor went rogue. Checking the call and the return showed that the data read from RAM was very different to that written. Very different. Either there were a lot of dead RAM chips or something more systematic going on.
I got good at reading the data (during CAS for a write and valid at the riding edge for a read and also the row and column addresses – valid at the falling edge of RAS and CAS respectively. Everything looked good, so I concluded that nearly all the RAM chips were duds. And that proved to be the case. After replacement of the lower 16k the machine came to life with a garbled display that looked a little like a sign on message but not quite. (I checked the sync timing before reconnecting the monitor.)
After replacing the video RAM, the display improved but was still not right. It changed with a wiggle of the character ROM. After cleaning the legs (it is socketed) the display was good. I could type in and run a program.
I tried some pokes and peeks in the second 16k. It also had many failures, so it needed the same tedious treatment. Once the second bank of RAMs was replaced, it worked.
Although the machine was doing quite well there was no chime and there were also issues detecting the datassette button presses. That sounded like a VIA problem. I replaced it and all was good.
I connected up the disk drive, and I was able to get a directory listing.
The 4116 datasheet did indicate that the power should be sequenced correctly to avoid damage. In particular, the -5V rail should power up before the others and power down after the others. I checked just to be sure.
Having worked over the metal work and CRT I moved processor board one into its chassis.
Initially nothing appeared on the CRT. The first problem was the spring which contacts the ground surface of the tube. It was a little oxidised and bent. After cleaning and adjusting it was fine. The display was quite dim though even with the sub-bright and bright at their max. The issue was that the 400VDC supply was only 200V. This was because R253 had gone open circuit. I have replaced it, but it may be a symptom of a bad capacitor – there’s quite a lot of commentary on it on the web eg:
https://forum.vcfed.org/index.php?threads/pet-12-monitor-repair.79319
