Commodore 16 not booting/Fault Screen

[DistantStar001]

Any idea what might be causing this?




I've replaced the TED (new/old stock), PLA (PLAnkton, CPU (6510 w/ adapter), Kernal ROM (had to because of the cpu). This screen has shown up before, but it used to boot at least some of the time. But it was glitchy (printing random characters on the screen/corrupted characters). Now, this is all I get.

Note: I get this screen even when the kernel or CPU is removed (also both).

 

[DrAM19]

Hi DistantStar001.

That's not a screen I've ever seen on my TED machines. That this occurs if the CPU is removed means you should look at the basics first. Voltage rails, clock, reset circuit. What diagnostic tools do you have? An oscilloscope would be best. A logic probe is good for checking reset, not great for clock. A multimeter can help with basics like the voltage.

Glitchy random characters indicates bad RAM usually. Do any of those chips get hotter than usual?

If you have the ability to burn a ROM, you can get a diagnostic ROM here -> https://www.zimmers.net/anonftp/pub/cbm/firmware/computers/plus4/index.html

Since I am pointing you in 3 directions, let me sort out my thoughts in order of how I would do it:
1) Check the voltage rails, clock, reset
2) Feel for hot RAM and logic chips, but don't bother with more diagnostics there yet.
3) Make a diagnostic ROM and run it, see what happens.

Let us know what you find.

 

[DistantStar001]

Checking power, clock, and reset were some of the first things I checked. All are present. Also, none of the chips are getting hot. That's what has me stumped.

Unfortunately, the only ePROM programmer I have is for the C64 and I don't know how to use it (yet).

 

[DrAM19]

What tests have you done (like voltage, clock, reset), and what did you see?

Without more information: The the next thing I would check then is activity on the address and data lines. I'm curious if the system is attempting to execute instructions. Doubtful since this behavior is unchanged with the CPU removed.

These machines don't have dedicated video RAM, so an issue in the RAM or a bus contention could also manifest as a screen issue. Worth a try to piggyback on the 4416s if you have spare, see if that helps. It usually doesn't, but its a free test.

SYNC is on the LUM line, so give that one a look too.

One other question: Is the PLAnkton you're using the TED version? I've never used one before, but it looks like the 64 and +4 versions are not the same.

 

[DistantStar001]

What tests have you done (like voltage, clock, reset), and what did you see?

Without more information: The the next thing I would check then is activity on the address and data lines. I'm curious if the system is attempting to execute instructions. Doubtful since this behavior is unchanged with the CPU removed.

These machines don't have dedicated video RAM, so an issue in the RAM or a bus contention could also manifest as a screen issue. Worth a try to piggyback on the 4416s if you have spare, see if that helps. It usually doesn't, but its a free test.

SYNC is on the LUM line, so give that one a look too.

One other question: Is the PLAnkton you're using the TED version? I've never used one before, but it looks like the 64 and +4 versions are not the same.

Sorry this took me so long. I work on the weekends and have class on the week days, so I've been trying to fix this in what little spare time I have.

In any case, I get a solid +5.02v on all ICs with my multimeter. Reset starts low but goes high after about a second. As for the clock: I apologize in advance for the poor photography (I was doing this one handed with my iPad while probing with the other), But picture 1 is clock-in and 2 is clock-out:


Near as I can tell, both signals look good to me.

I also did a quick probe of the other pins, and it would appear that something is holding them high. There was some activity on some pins, but the high line is always there. It's almost as if there were two signals on the line, but the high signal was drowning the active one out.

As for the PLAnkton, it is the version specifically intended for the C16, as both the C64 and Plus 4 have different versions.

I purchased some new 4416 RAM (new old stock) from my local electronic supply store and will be testing that soon. Also, aside from the usual suspects (CPU, TED, ROMs) the only MOS chip on the board is a 7714 (equivalent to a 74LS02). A quick check with a logic probe seemed to indicate that it was working, but I might replace it to be sure.

 

[DistantStar001]

Ok. I've poked around a bit more, and I can safely say that it's not the RAM, either of the ROMs, or the PLA (I know that wasn't a real suspect, but I wanted to be sure). Basically, I removed each and the screen has been unaffected. I now have new RAM installed in sockets, and a 64k SRAM expansion board installed underneath the TED. Supposedly, it should bypass the DRAM on the board when active. Unfortunately, it hasn't fixed the issue.

I did manage to trace down one problem, a dodgy 74LS257 at U7. Removing it didn't fix the issue (and now I need to find a replacement), but the conflicting signals seem to be gone. Now, everything on the address and data lines are either solidly high or low (mostly high). It's possible the other is bad as well (or I'm an idiot and removed the good one by mistake), and that's why most of the lines are being held high. Regardless, I'm going to get a few new replacements since they're always good to have.

In any case, the search continues. If anyone has some suggestions to steer me in the right direction, it would be appreciated.

 

[DrAM19]

Good troubleshooting so far. You'll find the answer before you know it. And no worries about a delayed reply. We all have to attend to life.

Good to see the voltage and proper reset behavior. The clocks look fine in those pics.

On the topic of that daughterboard bypassing the system RAM, did you happen to try it with all of the onboard RAM removed (since you socketed it anyway)?

Seeing address or data lines are held high is concerning; there should be activity. You said that swapping that MUX fixed the lines held high that you saw? Which pin (or pins) was that? Its important to remember that with two MUXes, each only touch half of the address lines (and only the address lines, the data lines are not MUXed).

If its not trouble, can you list out the address and data line behavior as it stands right now? You might see different behavior on the pins when you first boot and before it locks up, so that that into account.

 

[DistantStar001]

On the topic of that daughterboard bypassing the system RAM, did you happen to try it with all of the onboard RAM removed (since you socketed it anyway)?

Yes. It seemed to make no difference.

If its not trouble, can you list out the address and data line behavior as it stands right now? You might see different behavior on the pins when you first boot and before it locks up, so that that into account.

Yes. I can do this, but it's going to take me a bit to get some new 74LS257s without the bypass.

In any case, here's what I got (Note 1: I'm using the 6510 processor with adaptor since it's a bit of a pain to get in and out. Note 2: I'm getting better with my oscilloscope, so I was able to home in on some signals I didn't see before).

Pin 1: Clock in
Pins 2-4

Pin 5

Pin 6: VCC
Pins 7-13

Pins 14-15

Pins 16-20 + 22 & 23

Pins 24-29 were just high with no activity
Pins 30-37

Pin 38

Pin 39 Clock out
Pin 40 Reset

 

[DrAM19]

Very cool. The data lines look like normal activity. The lower address lines seem alright up through A6. A7 and A8 look like they're stuck high but trying to do something (those little dips). So that is where I'd be going first.

Looking at the schematic, A7 shares a line with +5 on the MUX output at pin 12 of U8. Was it U8 or U7 you replaced? That goes to a resistor pack (rp3) before the 4416 at U5

Pin 4 of U7 has a similar MUXing with A1 and +5, then into RP4 before getting to U5. So check both of those MUX outputs and compare the behavior. Also worth taking a quick set of measurements on the RPs to be sure no failures happened. Very unlikely, but not impossible.

A8 shares the line with A1 coming out of U7. So its less likely that a MUX issue would cause A8 to be stuck high if A1 has activity.

If I get some time tomorrow, I'll pull out my C16 and take similar measurements on the CPU to compare to yours, so that you have a baseline of expectations for the behavior.

 

[DistantStar001]

Very cool. The data lines look like normal activity. The lower address lines seem alright up through A6. A7 and A8 look like they're stuck high but trying to do something (those little dips). So that is where I'd be going first.

Looking at the schematic, A7 shares a line with +5 on the MUX output at pin 12 of U8. Was it U8 or U7 you replaced? That goes to a resistor pack (rp3) before the 4416 at U5

Pin 4 of U7 has a similar MUXing with A1 and +5, then into RP4 before getting to U5. So check both of those MUX outputs and compare the behavior. Also worth taking a quick set of measurements on the RPs to be sure no failures happened. Very unlikely, but not impossible.

A8 shares the line with A1 coming out of U7. So its less likely that a MUX issue would cause A8 to be stuck high if A1 has activity.

If I get some time tomorrow, I'll pull out my C16 and take similar measurements on the CPU to compare to yours, so that you have a baseline of expectations for the behavior.

Thanks. And sorry again for not getting back sooner. I needed to get some sockets for the 74LS257s.

Speaking of which, I salvaged some from a broken C64 board. I have no idea if they work but I ordered some new ones that should be here by Tuesday. In any case, installed them on the theory that even if they were broken, they would likely have different symptomology and swapping their positions would allow me to trace which chips were causing what problems. However, there was no change on the scope with the new chips and swapping them made no difference as well. This leads me to believe that my problem lies elsewhere.

My next suspect is the 74LS157 at U15

Probing with my scope I got the following:

Pin 1: Held high, with some activity
Pn 2: Low
Pin 3: Just high
Pin 4: Active
Pin 5: Active
Pin 6: Just High
Pin 7: Just Low
Pin 8: Just Low
Pin 9 Just Low
Pin 10: Just Low
Pin 11: Just High
Pin 12 Active
Pin 13: Active
Pin 14: Just High
Pin 15: Just Low
Pin 16: VCC (+5.02v)

 

[DistantStar001]

Possibly fixed. I finally managed to find my original Kernal ROM, so I was able to revert it back to the 8501 CPU. Whoever programed the 6510 replacement ROM must have either done it wrong or the ePROM was defective, since putting the original ROM and processor got it to boot almost right away. The fault screen pictured still appears before the boot, but only for a few seconds. Also there is no longer any graphical glitching or any of the random characters that got me started on this little odyssey. However, there is still some ghosting in the screen which can kind be seen in the pic below (it's much more prevalent in person):



All and all, this thing is back on its original processor, ROMs, and TED! (I suppose I have a spare now) But it does have all new RAM (both 16k and 64k) and new 74LS257s (guess they do work!). I'm guessing that there's no real reason to switch to the 6510 if the 8501 is working, but I did put a heat synch on it to be safe. In any case, maybe let me know if the ghosting is normal or if there is something I can do to reduce or make it go away. Other than that, thanks for all the help. I'm going to bed now and tomorrow, ar long last, I'm going to start playing in Commodore 3.5 BASIC!

 

[DrAM19]

Wonderful news and congratulations! I'm really glad to see that it's working.

The screen looks just like mine; so I'd say you're at normal operation.

Make sure to also heatsink the TED.

If you do look at an ePROM programmer in the future, that nice extra feature is being able to extract ROM data to verify it too. You'd be able to see if that 6510 ROM was the fault.