Results of troubleshooting party
Results of troubleshooting party
Twylo dropped by yesterday night and we spent the better part of five hours poking and prodding the sick 4032 and 8032. I thank him very much for his efforts and the loan of an 80mhz analog oscilloscope for further testing. Unfortunately we didn't manage to hit pay dirt on either machine.
This post is about the 4032. (I don't have the time to detail everything we did in one go.):
The first and most obvious thing we attempted on this machine was to substitute a known working set of ROMs from an identical 4032. (Twylo's.) Unfortunately there was no visible change in the system's behavior.
Various and sundry attempts were made to change the system's behavior, including piggybacking new 2114 RAM chips on the existing ones. Piggybacking on the second chip appeared to change the exact garbage being displayed, but don't appear to have gotten the machine any closer to booting. After that we chased several avenues related to the video system, noting that shortly after the system is power cycled the garbage on the screen changes. We've verified that this change is attributable to the character generator being switched from one character set to another by comparing the characters before and after the change to the chart here:
http://www.atarimagazines.com/compute/issue26/171_1_ALL_ABOUT_PET_CBM_CHARACTER_SETS.php
(The character generator is changing from the "alternate" set to the "standard", going by the terminology on that page. Does anyone know if this might be a normal part of the initialization cycle, and might be taken as a sign that the CPU is succeeding in executing at least some way into the ROM code?)
The next step was probing/connecting a small logic analyzer to various places on the video RAM memory bus, my idea being that perhaps we might be able to find some indication of whether the CPU was ever attempting to write to video. It *appears* we were able to verify that the output half of the video circuitry is working to the extend that data is being fetched to refresh the screen (IE, the junk on the screen at least appears like it may be coming from RAM).
(But there are possibly some reasons to be skeptical. The junk displayed on the screen is *very* but not entirely consistent between power cycles. We don't know if this might be just the static rams roughly "favoring" a given bit pattern on power up, if there might be bits stuck, or if the screen pattern might be the result of the computer attempting to clear the screen and the result being systematically garbled.)
Attempting to determine if the CPU were writing to RAM was another problem. We traced the path from the CPU bus to the video RAMs through the intervening buffers and tried getting a trace in the logic analyzer, and the results seemed very garbled. We attached probes from the analyzer to both sides of a given buffer for a given data line and powered on the machine, assuming we'd see a similar pattern from the two sides. Instead we got a very noisy trace with peaks of various widths. We don't know if what we're seeing is actually indicative of a problem with the buffers or our methodology/the probe... Twylo said he may try running some similar traces on his working 4032.
Another thought I had involved some documentation about the "Killer Poke", IE, how the PET stops itself from writing to video RAM when it's not in the blanking period. I wasted some time chasing through the schematic to see if this was actually imposed in hardware. (IE, if a write attempt inside the active display area would halt the CPU or otherwise physically block it. My thought was if that were "stuck" it might be halting the CPU when it attempted to clear the screen or put up the basic prompt.) I eventually found a theory page that explained it was a software loop in the output routines that looked for status on one of the VIA pins, so we checked that pin to see if it were cycling. It is, at what appears to be the appropriate rate.
So... overall, we seem to have eliminated a few things that it's *not*, but we don't seem immensely closer to determining what it is, which is of course a little disappointing. Sigh.
(Suggestions are of course welcome. The apparent "noise" we observed downstream of the data bus buffers between video RAM and the CPU has me wondering if it might be worth replacing some components in that area. System RAM isn't ruled out either, although I did piggybank the bottom 16k with no behavioral change. I'm also planning to try to poke the appropriate place to see if the machine is scanning the keyboard matrix. The idea to try that came too late in the evening to pursue. But... sigh. I'm still in way over my head here, apparently.)