Troubleshooting Microprocessors

[bostonman]

I have a question regarding troubleshooting microprocessors. I'm in the process of fixing a Commodore 64 (this isn't a C64 question though) and experiencing the same problem I've had over the years when coming across microprocessors: trying to measure data and address bus signals.

Basically my question is: what is the flow of a computer section?

A computer section is comprised of a micro, ROM, RAM, and some sort of programmable chip like a PROM. What happens when power is first applied, which chip(s) drive the address bus, etc...?

My difficulty has always been the chips are bi-directional, and all the lines go in and out of each chip. So if say my address bus isn't clocking, which chip(s) drive that bus so I can check whether that chip is getting signals to tell the address bus what to do?

Also, on paper, IC chips (let's say microprocessors) always have some sort of timing diagram. When looking at data and address signals on an oscilloscope, assuming they are working correctly, are always jumping. How does someone look at those signals that are changing rapidly tell whether they are correct?

[chris_leyson]

In this sort of situation it's usually good to pulse the reset pin with an external reset generator and use it as a scope trigger. From then on you just probe the processor address and data bus pins looking for stuck drive signals. Then look at chip enable signals and so on. It's tedious and time consuming with a scope so a logic analyser, Saleae for example me gnat be quicker.

[ferdieCX]

The easiest way is to build a simple hardware "single step" for the microprocessor, this usually involves using the RDY line to put the processor in WAIT at each machine cycle.
I used to do that when repairing 8080 and 8085 based VT100 and VT102 terminals. Probably you will find such a circuit for the 6502 in the internet.
In the general case, without single step, you have to sync the scope with the MEMREAD or MEMWRITE signals to see what is traveling trough the data and address buses in the "valid" time. As already said, it is a good method to look what happens immediately after pressing the "reset"
It helps to have a ROM burnt with a very simple loop program with few instructions.

[David Hess]

My difficulty has always been the chips are bi-directional, and all the lines go in and out of each chip. So if say my address bus isn't clocking, which chip(s) drive that bus so I can check whether that chip is getting signals to tell the address bus what to do?

The combination of the -CS (chip select) and -WE (write enable) signals reveal what each chip should be doing on the address and data bus.

Also, on paper, IC chips (let's say microprocessors) always have some sort of timing diagram. When looking at data and address signals on an oscilloscope, assuming they are working correctly, are always jumping. How does someone look at those signals that are changing rapidly tell whether they are correct?

With a storage oscilloscope the results can be frozen for display.  Otherwise a specific signal is selected for triggering which produces a consistent set of results like the -CS or -WE signal to a specific chip.  A word recognizer might be used to trigger only on a specific combination of signals.

Sometimes the levels are less important than the transitions or you are looking for invalid levels which does not require a stable display.

[atmfjstc]

It's difficult to provide a very clear and specific answer to such a broad question, particularly because the specifics may differ from architecture to architecture. If I was to try my hand at a very general summary of how simple computers work, I'd say something like...

The ultimate source of the control flow is the system clock/oscillator. It starts by itself at power up and drives all the other chips from a control flow perspective, i.e. without a clock they will never advance through their states. It's one of the first things that should be checked after the voltages, if the clock is stopped, unstable or misshapen, none of the other chips can function as a system.

Downstream from the clock, the CPU is usually the main "master" chip, which is to say that as long as it is getting a clock, it will go by itself through all the state changes required to make the system go: it will put a read request on the bus for the next instruction, it will execute it, then post other read/write requests for data or I/O, it will respond to interrupts etc. Other RAM/ROM/IO etc. chips are "passive" in the sense that they will not do anything until the CPU sends a signal. At which point they will go through a few state changes so that they take control of the bus data lines, put the result there for the CPU to read, then relinquish it.

Depending on the architecture, the video controller might also be a master chip vis-a-vis the control flow, since it may need to spontaneously and continuously read the video memory (if shared with the CPU) so as to form a TV signal. Thus, it will also drive the bus so as to issue read requests. There is usually some synchronization mechanism to resolve conflicts if the CPU also wants to read data at the same time (e.g. keep the CPU halted until the video chip gets a byte of data).

So, on a broad level, the flow is clock -> CPU/Video controller -> all other chips. There is usually no DMA controller or other complications in simple computers such as these.

On a smaller scale, especially from the perspective of the bus, things are of course more complicated, each chip can be a "master" for a given clock cycle. All chips that can answer queries (e.g. RAM/ROM/IO) will have to take control (drive) of the bus at some point so as to return the answer while the other chips listen. However they only do so in response to requests, and their "masterhood" is limited to a few clock cycles and usually applies only to the bus data lines.

In a sense, there's no such thing as a "bidirectional" lines. A line transmits data in only one direction at a time, and the current direction, if any, is determined by a strict protocol whose phases we advance through with every clock cycle. It pays to look trough the datasheet of the memory chips and CPU and see their phases of operation. The protocol is often not complicated.

[bostonman]

Thanks for the detailed explanation. I did, however, use the wrong term when I used 'bi-direction', but understand chips need to be told which direction to send data.

While I'm not asking for help with the C64 (I'm already posting my measurements on a C64 forum, but I'll take what I can get hhahahah), I do think it's a relatively simpler system and an opportunity to learn the fundamentals of microprocessor circuits. Currently the address bus is not clocking and basically all the signals are stagnant - I assume this is a good starting point.

I guess to simplify my question, in this case, since this is a simpler system, does only the microprocessor generate address bus commands? I'm confused because these lines go to multiple chips, a few chips seem to use only three (or maybe four) of the total 16bit bus, and the 6502 is missing three signals (when compared to a good unit): IRQ, R/W, and RDY (although I don't know what this is because the datasheet doesn't seem to define it, just names it on a pin).

Only a few chips have sockets, and I've tried swapping them. Between tracing all the chips that connect to A0 - A15, the chips that only use three or four of the address bits, and the ICs I've swapped, I've narrowed it down to two forty-pin chips. But I don't know if the chip or chips that generate the address bus commands is bad or being told not to generate them because that chip is bad or being fed bad information from the culprit.

If I can figure out which chip generates the address bus commands, maybe I can focus on that chip to determine if any pin is being held in a state that tells the chip to not clock the address bus or whether that chips is the culprit.

[atmfjstc]

Even if you intend your query to not be about the C64 specifically, you have no chance of understanding any system unless you precisely identify the chips used in the machine, and read up on their pinout and how they are supposed to work together in that particular machine.

In this particular case, you should note that the C64 uses a 6510, not a 6502. The pinout is different and it has several extra inputs/outputs that are required for it to share control of the bus with the VIC-II video chip. On the C64, the VIC-II video chip also drives the address bus in order to read the video memory and the character ROM. I think it and the CPU basically take turns in being bus masters.

If the address lines are not showing any activity at all (provided you've identified them correctly), that is a very bad sign. Both the CPU and the VIC-II should be putting new addresses on the address bus regularly. If there is no activity at all, then you should check whether there is any activity on the chips' clock pins, and whether the chips are not being kept in a reset state.

Some summary info on the chips' pinouts:

https://ist.uwaterloo.ca/~schepers/MJK/6510.html
https://ist.uwaterloo.ca/~schepers/MJK/vic2.html

[james_s]

The CPU drives the address bus, then the address decoding takes the values on the address bus lines and decodes them to drive the chip selects on the individual peripheral chips. You might notice in some lower cost machines that the address bus is often not fully decoded, ie the circuitry is somewhat crude, causing some devices to appear at multiple addresses.

When power is first applied, the CPU jumps to the reset vector, this is an address location which is normally routed to ROM where the first instructions you wish to execute are located. Once the first instruction executes things will carry on from there.

[techman-001]

I have a question regarding troubleshooting microprocessors. I'm in the process of fixing a Commodore 64 (this isn't a C64 question though) and experiencing the same problem I've had over the years when coming across microprocessors: trying to measure data and address bus signals.

Basically my question is: what is the flow of a computer section?

A computer section is comprised of a micro, ROM, RAM, and some sort of programmable chip like a PROM. What happens when power is first applied, which chip(s) drive the address bus, etc...?

My difficulty has always been the chips are bi-directional, and all the lines go in and out of each chip. So if say my address bus isn't clocking, which chip(s) drive that bus so I can check whether that chip is getting signals to tell the address bus what to do?

Also, on paper, IC chips (let's say microprocessors) always have some sort of timing diagram. When looking at data and address signals on an oscilloscope, assuming they are working correctly, are always jumping. How does someone look at those signals that are changing rapidly tell whether they are correct?

Long long ago I used to repair large commercial video game boards, usually sporting a Z80, 6502 or 6809 etc.

On average I'd fix about 10 boards each morning, many had bad solder joints, some had bad Ram, Eproms or CPU, etc.

Our repair tools usually consisted of a logic probe and a small flat bladed screwdriver. The more well equipped techs also owned a logic pulser.

The screwdriver was used to try and lever up DIP's and detect dry solder joints, you'd be surprised how often it detected the problem when a complete 24 or 40 pin chip levered right out of the board. It was also used to short out CS pins ( to adjacent pins) to try and generate some response on the data bus.

Using these crude methods, a board could either be fixed in 15 minutes by a experienced technician without a schematic diagram, or never fixed at all.

All suspect chip pins were cut with fine wire cutters and the body binned. The legs were removed with soldering iron and tweezers then the solder sucked thru from the opposite side of the board. Chips were *never* removed complete because the risk of damaging the PCB was too great.

[james_s]

I currently repair vintage arcade game boards, I've been removing chips intact for years, ever since I got a vacuum desoldering gun. I can pull a 40 pin DIP on a whim and I don't remember the last time I damaged a board.

[techman-001]

I currently repair vintage arcade game boards, I've been removing chips intact for years, ever since I got a vacuum desoldering gun. I can pull a 40 pin DIP on a whim and I don't remember the last time I damaged a board.

Different circumstances.

We didn't have a vacuum de-soldering gun to share between 20 technicians who produced 90 complete commercial games a day including enclosures (stand up or sit down) 5 days a week. Spending more than 15 minutes on a board was not worth it.

These weren't vintage, they were the current tech of the day.

My point is that there are two ways to fix this old technology, the fast way with a few simple tools and lots of experience, or the *really* slow way with a workshop full of hitech gear, schematics and every possible aid.

[paulca]

I found this fascinating to watch.

https://youtu.be/LnzuMJLZRdU

[NivagSwerdna]

Do the simple things first...

Check PSU voltages (all of them), check for uP clock, check for Reset.

Things get complicated quite rapidly when DRAM and contention between main CPU and memory mapped video get involved.

https://www.retro-kit.co.uk/user/custom/Commodore/C64/manuals/C64C_Service_Manual.pdf

[bostonman]

If the address lines are not showing any activity at all (provided you've identified them correctly), that is a very bad sign.

Is it a bad sign because the failure is catastrophic or complex to find? This was a working C64 a few years ago, placed it in "storage", and now it doesn't have a display. As for the voltages, the power supply was built by me and works on two other units; it also worked on this C64 before I placed in storage. The 5V is a bit low though (I used a 2A or 3A regulator). With no load it's 5V, at power on it's 4.9xx V, and after the inductor (L5) it's 4.88V, but two other C64 units work fine with this power supply.

During power recycles, sometimes the address lines will show some activity (although I don't know if it's correct as the signals just jump around). Also, from what I can tell, the clock signals are present such as 14.3MHz and 8.18MHz (at U30 and U31 respectively).

I'm trying to avoid fast and hacking methods to fix this C64 for a few reasons: It's my original C64 and I'd like to keep it in tack without hacking the board, it was working before placing it in storage and now it doesn't work indicating (hopefully) one component has failed, and replacement chips are hard to get (I'm trying to avoid drop in replacement stuff designed within the last few years such as the PLAnkton which is a PLA replacement).

Thinking it was the PLA (U17), I unsoldered it using a hot air pencil and for whatever reason, the pin broke from the body of the IC. So now I'm avoiding the option of randomly removing ICs; and I don't have a vacuum desoldering station (just good old solder braid and the heat pencil).

[atmfjstc]

OK, so the COLOR (14.3MHz) and DOT (8.18MHz) are going into the VIC-II chip. Now check whether the 1MHz clock for the CPU is being output on pin PHI0.

[bostonman]

The bad quality schematics I have don’t seem to show PHI0.

Where is it?

[james_s]

My point is that there are two ways to fix this old technology, the fast way with a few simple tools and lots of experience, or the *really* slow way with a workshop full of hitech gear, schematics and every possible aid.

The first way is obsolete when dealing with vintage gear, there isn't the volume to get that kind of experience and the stuff is rare enough that you don't hack and slash or just give up if you can't fix it in a few minutes.

Then of course there is a whole spectrum in between those two extremes. I have found a happy medium with a modest collection of tools and gear and schematics when available.

[james_s]

If the address lines are not showing any activity at all (provided you've identified them correctly), that is a very bad sign.

Is it a bad sign because the failure is catastrophic or complex to find? This was a working C64 a few years ago, placed it in "storage", and now it doesn't have a display. As for the voltages, the power supply was built by me and works on two other units; it also worked on this C64 before I placed in storage. The 5V is a bit low though (I used a 2A or 3A regulator). With no load it's 5V, at power on it's 4.9xx V, and after the inductor (L5) it's 4.88V, but two other C64 units work fine with this power supply.

During power recycles, sometimes the address lines will show some activity (although I don't know if it's correct as the signals just jump around). Also, from what I can tell, the clock signals are present such as 14.3MHz and 8.18MHz (at U30 and U31 respectively).

I'm trying to avoid fast and hacking methods to fix this C64 for a few reasons: It's my original C64 and I'd like to keep it in tack without hacking the board, it was working before placing it in storage and now it doesn't work indicating (hopefully) one component has failed, and replacement chips are hard to get (I'm trying to avoid drop in replacement stuff designed within the last few years such as the PLAnkton which is a PLA replacement).

Thinking it was the PLA (U17), I unsoldered it using a hot air pencil and for whatever reason, the pin broke from the body of the IC. So now I'm avoiding the option of randomly removing ICs; and I don't have a vacuum desoldering station (just good old solder braid and the heat pencil).

On the contrary, I'd say it's a good sign because it points to the problem being something relatively simple to find. It's a lot easier to troubleshoot something that is completely dead than something that behaves in some bizarre way.

I'd check the CPU clock and reset lines first, you could have a bad clock, stuck in reset or it's possible you have a bad CPU. IIRC the C64 uses a custom derivative of the 6502 and failure is common due to one of the pins being routed directly to the expansion connector.

[atmfjstc]

The bad quality schematics I have don’t seem to show PHI0.

Where is it?

Check those links I provided. PHI0 is pin 17 of the VIC-II. On the C-64, the CPU is not clocked directly by the oscillator. Instead, the oscillator clocks the VIC (on pin #21, DOT CLOCK), the VIC divides the frequency by 8, and outputs a ~1MHz clock for the processor on pin #17, PHI0. This should go to the 6510's pin #1, PHI0.

This particular feature of the C-64's architecture means that if the VIC-II is removed or completely toast, the CPU will not work either, which might explain why there's no address activity.

Thus, you should check whether a 1MHz clock is being output on pin #17 of the VIC, and if yes, whether it is actually getting to pin #1 of the 6510 (could have a broken trace, who knows).

[bostonman]

OK, so the COLOR (14.3MHz) and DOT (8.18MHz) are going into the VIC-II chip. Now check whether the 1MHz clock for the CPU is being output on pin PHI0.

I took pictures to make it easier than going by my description. Hopefully the file names are posted.

[james_s]

Ok so it looks like you have a clock signal there? I don't have the schematic in front of me so I'm not entirely sure what each scope capture is showing.

What's the reset line on the CPU doing?

[atmfjstc]

The clocks seem to check out. And the /RESET and RDY lines seem to be high, so there is nothing keeping the processor from working. I am seeing some activity on the A0 address line though. Previously you said that "Currently the address bus is not clocking and basically all the signals are stagnant - I assume this is a good starting point." - are you sure this is the case?

Maybe try sampling A0,A1,A2,A3 with a longer timebase. If there is continuous activity here, it could be the CPU is working after all, in which case you can focus on the VIC-II chip output and modulator.

You could also try (blindly) typing:

POKE54296,15

as soon as the computer boots up. This should cause a 'pop' in the audio.

[bostonman]

What's the reset line on the CPU doing?

Sitting at +5V DC (and appears a bit noisy). It's labeled 'U7 Pin 40' in my scope pictures.

Maybe try sampling A0,A1,A2,A3 with a longer timebase. If there is continuous activity here, it could be the CPU is working after all, in which case you can focus on the VIC-II chip output and modulator.

I already tried a good VIC chip since that has a socket. As for the address lines, the waveform I included (Pin 7 - Address A0) should have more activity on it (when compared to a good one). Some address lines either sit at 5V DC while some look like the wave I included whereas on a good one, these signals have lots of activity on them. Also, I tried typing "load"*",8,1 blindly, three times, with a power reset after each time, and the disk drive didn't load. When turning on the C64, it does cause the drive to spin for the two or three seconds it normally does, but the C64 doesn't acknowledge what I typed.

[james_s]

What happens if you momentarily force the reset line to ground? Do you get a spurt of activity on the address lines? It's possible the CPU is starting up then due to some fault the code ends up off in the weeds and halts.

[bostonman]

Is touching a ground wire to the reset pin safe for the chip?