Troubleshooting Microprocessors - Page 1
Forum section: electronics / beginners

author: bostonman
author_rank: Super Contributor
timestamp: December 27, 2019, 01:44:01 pm
content: 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?

author: chris_leyson
author_rank: Super Contributor
timestamp: December 27, 2019, 02:46:12 pm
content: 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.

author: ferdieCX
author_rank: Regular Contributor
timestamp: December 27, 2019, 02:47:41 pm
content: 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.

author: David Hess
author_rank: Super Contributor
timestamp: December 27, 2019, 03:39:51 pm
content: Quote from: bostonman on December 27, 2019, 01:44:01 pmThe combination of the -CS (chip select) and -WE (write enable) signals reveal what each chip should be doing on the address and data bus.QuoteWith 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.

author: atmfjstc
author_rank: Regular Contributor
timestamp: December 27, 2019, 04:39:00 pm
content: 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.

author: bostonman
author_rank: Super Contributor
timestamp: December 27, 2019, 11:59:21 pm
content: 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.

author: atmfjstc
author_rank: Regular Contributor
timestamp: December 28, 2019, 12:52:46 am
content: 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.htmlhttps://ist.uwaterloo.ca/~schepers/MJK/vic2.html

author: james_s
author_rank: Super Contributor
timestamp: December 28, 2019, 01:11:40 am
content: 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.

author: techman-001
author_rank: Frequent Contributor
timestamp: December 28, 2019, 07:16:03 am
content: Quote from: bostonman on December 27, 2019, 01:44:01 pmLong 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.

author: james_s
author_rank: Super Contributor
timestamp: December 28, 2019, 07:53:31 am
content: 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.

author: techman-001
author_rank: Frequent Contributor
timestamp: December 28, 2019, 08:42:31 am
content: Quote from: james_s on December 28, 2019, 07:53:31 amDifferent 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.

author: paulca
author_rank: Super Contributor
timestamp: December 28, 2019, 09:23:44 am
content: I found this fascinating to watch.https://youtu.be/LnzuMJLZRdU

author: NivagSwerdna
author_rank: Super Contributor
timestamp: December 28, 2019, 11:45:50 am
content: 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

author: bostonman
author_rank: Super Contributor
timestamp: December 28, 2019, 02:45:12 pm
content: QuoteIs 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).

author: atmfjstc
author_rank: Regular Contributor
timestamp: December 28, 2019, 02:53:31 pm
content: 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.

author: bostonman
author_rank: Super Contributor
timestamp: December 28, 2019, 06:36:21 pm
content: The bad quality schematics I have don’t seem to show PHI0.Where is it?

author: james_s
author_rank: Super Contributor
timestamp: December 28, 2019, 06:47:01 pm
content: Quote from: techman-001 on December 28, 2019, 08:42:31 amThe 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.

author: james_s
author_rank: Super Contributor
timestamp: December 28, 2019, 06:49:36 pm
content: Quote from: bostonman on December 28, 2019, 02:45:12 pmOn 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.

author: atmfjstc
author_rank: Regular Contributor
timestamp: December 28, 2019, 11:32:50 pm
content: Quote from: bostonman on December 28, 2019, 06:36:21 pmCheck 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).

author: bostonman
author_rank: Super Contributor
timestamp: December 28, 2019, 11:34:20 pm
content: QuoteI took pictures to make it easier than going by my description. Hopefully the file names are posted.

author: james_s
author_rank: Super Contributor
timestamp: December 29, 2019, 05:49:40 am
content: 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?

author: atmfjstc
author_rank: Regular Contributor
timestamp: December 29, 2019, 12:06:17 pm
content: 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,15as soon as the computer boots up. This should cause a 'pop' in the audio.

author: bostonman
author_rank: Super Contributor
timestamp: December 29, 2019, 02:53:10 pm
content: QuoteSitting at +5V DC (and appears a bit noisy). It's labeled 'U7 Pin 40' in my scope pictures.QuoteI 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.

author: james_s
author_rank: Super Contributor
timestamp: December 29, 2019, 05:18:06 pm
content: 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.

author: bostonman
author_rank: Super Contributor
timestamp: December 29, 2019, 05:27:40 pm
content: Is touching a ground wire to the reset pin safe for the chip?

author: james_s
author_rank: Super Contributor
timestamp: December 29, 2019, 05:43:59 pm
content: It's safe for the CPU chip, reset is an input. Whether it's safe for whatever drives the reset pin depends on what that is, but there is certainly a way you can force the reset. A safer method is to use something like a 10 ohm resistor to ground, this will limit the current to something reasonable in case a pin is being driven by a low impedance source.

author: bostonman
author_rank: Super Contributor
timestamp: December 29, 2019, 07:31:19 pm
content: When I pull reset low, it causes the address lines to be a continuous 1.xMHz clock pulse, 0 to approx. 3.5v. Although they are not switching states, they do look close to a good unit.

author: james_s
author_rank: Super Contributor
timestamp: December 29, 2019, 09:41:37 pm
content: The address lines are a pulse but they're not switching states? That's contradictory, are they pulsing or are they just sitting at a fixed voltage?

author: bostonman
author_rank: Super Contributor
timestamp: December 30, 2019, 12:32:54 am
content: See the two pictures I included for a better idea of what I mean.On a working one, the signals are jumping around (I assume because the scope isn't synchronized to the board). On the broken C64, only half the signals are present (see picture), and with reset held low, the full screen is filled with signals; but they don't jump around.

author: Shock
author_rank: Super Contributor
timestamp: December 30, 2019, 06:57:03 am
content: Quote from: techman-001 on December 28, 2019, 08:42:31 amVacuum desoldering is actually the fast way but you still need experience as it's easy to butcher PCBs if you are impatient. If parts are scarce, expensive or need further testing they also may need to be removed intact.Perhaps not on company time but I still think it's best to learn proper manual desoldering without ripping out traces. You will a hard time convincing most people that though that schematics and oscilloscopes aren't useful especially on complex repairs.

author: techman-001
author_rank: Frequent Contributor
timestamp: December 30, 2019, 07:29:12 am
content: Quote from: bostonman on December 30, 2019, 12:32:54 amI have a 54601A scope myself, bought it new in 1994, use it every day and just love itPicture is via the RS232 module and some Unix processing.

author: NivagSwerdna
author_rank: Super Contributor
timestamp: January 01, 2020, 04:21:25 pm
content: might be educational

author: bostonman
author_rank: Super Contributor
timestamp: January 02, 2020, 07:08:40 pm
content: I've kind of run out of ideas and feel maybe I should readdress repairing this in the future as I feel my measurements take me in a loop.At the moment, any chips I suspect are not in sockets; nor do I have extras to swap (or my other C64 doesn't have those chips in sockets either).Any chip I suspect is driven by the address bus which goes to several chips. Any other chip that has bad signals is either being told to be bad by the address bus or is the culprit.Ideally I'd like the ability to freeze the unit so I can measure chips individually (which is how I opened my initial question), however, doesn't seem easy to do.Per my initial question, trying to measure microprocessors comes down to needing a custom micro to freeze the bus and measure signals?

author: atmfjstc
author_rank: Regular Contributor
timestamp: January 02, 2020, 07:47:21 pm
content: You don't need a "custom micro". As others have said before, the best tool for this situation is a logic analyzer. However, you can do without it (as the guy in the video did). A 4-channel scope, even a 2-channel scope could provide enough information to figure out what's going on. It'll just take more work.I don't mean to sound mean, but I think your real problem here has nothing to do with the tools available. Looking at your posts, I'm not convinced you have done the research and truly understand how the C64 works and what signals to expect. I'm not even sure you understand how buses work. A tool, however advanced, can only make your work easier and faster, but can't do the thinking for you.Sometimes you can get lucky and stumble your way into a solution without really understanding what's going on. But just as often, you will hit a brick wall.If I were you, I'd spend a few days researching the 6510, VIC, the RAM/ROM chips, the C64 schematic, what all the pins mean, and how the chips work together. I think you'll find that none of the chips' behavior is really that complicated. And then you'll know exactly what to look for and how to recognize incorrect behavior.

author: bostonman
author_rank: Super Contributor
timestamp: January 03, 2020, 02:00:01 am
content: QuoteYou're not completely wrong. Generally speaking, I know what a ROM does, RAM, etc... and been around electronics long enough to know about signals. On paper, it's much easier to interpret the signals because a datasheet states which pins need to be high/low to process data.I do, however, get overwhelmed by the many signals and where to look in order to find the origin of the signal(s). You're correct, maybe I should sit and read the many pieces of information in order to understand the C64 better. When it comes to the microprocessor section of any piece of electronics I've worked on, I always get overwhelmed. I'm also a bit timid because this is my original C64 and not some random piece I bought. So I don't want to hack the board and trying to approach the problem methodically.

author: ogden
author_rank: Super Contributor
timestamp: January 03, 2020, 02:20:25 am
content: Quote from: bostonman on January 02, 2020, 07:08:40 pmYes. Sorry to say, but seems you need to learn basics first until you actually understand what you are doing. Looking at "full screen of signals that jump around" do not sound like CPU troubleshooting at all. What you *can* do in this case - find someone with hands-on C64 knowledge to guide your troubleshooting steps according to your (rather limited) level of expertise.

author: bostonman
author_rank: Super Contributor
timestamp: January 03, 2020, 07:37:08 pm
content: QuoteJust to clarify, I'm an engineer, just lack microprocessor experience. Any experience was all theory and any hands on was at a minimal.Upon posting my question, I never thought I'd receive the extensive feedback focusing on the C64 that I did, so I appreciate it. Obviously I learned a bit more than I knew about uprocessors, but still need much more knowledge (and why I posted my question in 'Beginner'.Many basic questions still exist like how would I sync my oscilloscope to the microprocessor? I'd need to tap off the clock circuit, but not sure if it can drive the scope. So maybe I'd need to build a buffer amp. I have a 64-channel logic analyzer (two actually) that I'm uncertain work; maybe I'll try connecting one of them.

author: ogden
author_rank: Super Contributor
timestamp: January 03, 2020, 07:58:42 pm
content: Quote from: bostonman on January 03, 2020, 07:37:08 pmhttps://www.testandmeasurementtips.com/the-trigger-function-of-an-oscilloscope/QuoteClock of CPU is logic level signal as well. Don't measure clock at the crystal terminals. measure at the clock buffer output.QuoteNo. Clock is logic level signal, any scope can show it w/o any buffers. Schematics of the thing will be very, very helpful. Do you have it?QuoteLeave it alone at the moment, 2-channel scope is good enough for basic troubleshooting. When you see that you need more than 2 channels - THEN look for logic analyzer. Logic analyzers show only 0 or 1, they do not indicate logic signal integrity which is much more important in your case. So stick with scope.

author: bostonman
author_rank: Super Contributor
timestamp: January 03, 2020, 08:11:26 pm
content: QuoteI meant is the clock signal (I know not to take it at the crystal - and I have schematics) capable of driving the impedance of the scope along with the C64 circuit?

author: ogden
author_rank: Super Contributor
timestamp: January 03, 2020, 10:28:07 pm
content: Quote from: bostonman on January 03, 2020, 08:11:26 pmYes indeed. Clock buffer is one of strongest digital signal source in such devices, it will not even notice 10MOhm scope probe connected. Could you please share URL/link to schematics, if any.

author: Shock
author_rank: Super Contributor
timestamp: January 04, 2020, 12:50:24 am
content: Here is a video showing testing from an almost dead state. Minimizing the board into a basic running state with the dead test cart seems reasonable to me, especially if you have nothing on the screen. If you have a working board to compare the cart on even easier, with the right triggering you should be able to determine exactly what is working and how clean the signals should be between your two boards.You should have no problem probing the signals with your oscilloscope it won't load it significantly. If you are concerned about the quality of signals compared to the other board you should look at how you are grounding the probe and use the closest ground. Unexpected noise on the power or specific data line requires attention. As you notice in the video a change in voltage level can indicate a faulty component. In fact not measuring all voltage levels/ripple and ground continuity to all ICs to start with is punishable by death.In your case don't make any assumptions in your testing or having introduced a marginal fault by accident with the power supply, video and cables. What worked before might suddenly be the culprit until you double check (even if it works on another system). Pays to use two testing methods followed up with measurement to confirm your findings.For example, the display flickers for you therefore it must be able to work on this system would be an assumption. So if you haven't thoroughly tested the circuitry involved or double checked your changes to the circuit or changes in your testing environment since the last time it was working correctly you need to revisit it.He mentions at the beginning his ram looks fine but he based that off seeing just activity alone with the oscilloscope. I think there is a large chance however this video covers your problem. Looks like he has the same board revision as well.

author: bostonman
author_rank: Super Contributor
timestamp: January 07, 2020, 08:04:15 pm
content: I haven't had a chance to watch the video or continue addressing the problem, but I have a question.Why can't the microprocessor be removed, and a socket be installed that has all the pins either grounded or pulled to Vcc (ignoring the ones that are either a clock in, Vcc in, etc...)? This would allow the entire address and data bus to remain in one state and allow for measuring all the chips to see where issues are.

author: ogden
author_rank: Super Contributor
timestamp: January 07, 2020, 09:01:09 pm
content: Quote from: bostonman on January 07, 2020, 08:04:15 pmNo need. If everybody else can find faults w/o replacing CPU with switchers, you can do it as well.

author: Shock
author_rank: Super Contributor
timestamp: January 08, 2020, 12:10:43 am
content: Quote from: bostonman on January 07, 2020, 08:04:15 pmIf the microprocessor is functional it is the main diagnosis tool (think of it as a multi channel signal generator), but lifting pins and isolating is a troubleshooting technique you can use if required.Watch that last video and this one as well, both useful as they give ideas on how to sniff out the problem from a similar state. Ignore that bit about the ram not being used by the dead test cart and soldering through hole plated joints (aside from verifying they are still connected). But otherwise the only place he went wrong (shown in the video at least) was a few assumptions based on previous work which weren't that fruitful, checking previous work though is a good idea.

author: NivagSwerdna
author_rank: Super Contributor
timestamp: January 08, 2020, 11:07:34 am
content: Quote from: bostonman on January 07, 2020, 08:04:15 pmSimplistically it can... and people have built gadgets using 5V compatible technology to tweak the lines and simulate the uP however life gets rapidly more complex.... to reduce costs DRAM was used rather than SRAM and DRAM requires refresh so there will at least be bus contention and in some cases (e.g. Z80) the actual DRAM refresh is done by the uP itself... further video architectures differ but some work asynchronously with respect to the uP and use some bus logic to arbitrate between the uP and the video... your gadget would need to respect that arbitration. On very simple architectures you could achieve what you are suggesting... in fact it might be fun to try... an Arduino Mega 2560 would be an obvious starting point as it is 5V and has lots of GPIO but you might find yourself tearing your hair out with the number of wires required and then you would get into the land of a custom PCB for an adapter... and... the rabbit hole goes deep.

author: Shock
author_rank: Super Contributor
timestamp: January 14, 2020, 11:38:25 am
content: Made any progress?Am going to binge watch a few C64 repair videos tonight, I love murder mysteries. You have probably seen this before but checkout the link below. It mentions some books at the end, "Troubleshooting And Repairing Your Commodore 64" by Art Margolis looks fairly comprehensive.http://retro64.altervista.org/blog/commodore-64-repair-a-quick-guide-on-the-steps-required-to-fix-it/The second link shows some other tools born of that time period the logic pulser and probe, clip and current tracer (there was also a logic comparator as well). In the logic clip video (he is demoing on a arcade board) you will see him disable the crystal and manually drive the clock with the pulser.https://www.youtube.com/playlist?list=PL7K-x1E-x5j_XhmMCJg99_BhLusGDCUgTAside from the speed of testing on those tools, triggering on an oscilloscope, a function generator and or a logic analyzer replaces those (functionality wise) and some programmers cover the testing of logic. But doing something similar combined with the board running on minimal ICs (if possible) and a dead test cart then comparing to another board seems to be about as low level as you can get for complex issues.Here is the troubleshooting approach I would take working within your specific rules of minimal board changes:1. Proper confirmation that power has no issues and the whole board is supplied and grounded.2. Video has been ruled out (as much as possible).3. All input is non responsive and known points of failure like electrolytics, temperamental regulators, dry joints, degraded traces, corroded pins or bad sockets have all been addressed.4. Basic signs of life and signal quality as per the last video I linked or web guides, service manual, datasheets.5. Low level or minimal config troubleshooting compared to a good board with the dead test cart.6. Manually testing and observing data lines.7. In circuit analog signature analysis with a curve tracer in the hope it shows something missed.8. Then lastly removing and swap testing components to check if you have an obscure IC or board fault.

author: Shock
author_rank: Super Contributor
timestamp: January 23, 2020, 12:20:50 am
content: Here is another 3 videos that show an efficient repair process.

author: bostonman
author_rank: Super Contributor
timestamp: January 23, 2020, 03:35:57 pm
content: For some reason I haven't been receiving notifications about message updates.Unfortunately I set this project aside for a bit. Not because I was having bad luck, but initially I began thinking it was an easy fix. I haven't built a workbench yet, so I'm not setup to spread out with test equipment, and a warm basement.One thing I've learned after years of working on electronics: when an area gets too messy, accidental shorts and damage to the PCB occurs. So I feel it's necessary to clean the area, take a break, and readdress this in a month or two.As for the eight steps listed above, the video works as I've used other working C64s on the same setup using the same power supply I built. The only thing I've questioned is whether the power supply putting out 4.88V is too low (although it's suppose to be a 5V regulator - and I didn't buy a cheap one).

author: james_s
author_rank: Super Contributor
timestamp: January 23, 2020, 07:59:54 pm
content: 4.88 is a bit low, it *should* still work assuming that's the voltage at the ICs rather than at the power supply but it's not ideal.