Resolved! Help repair a C128D! (text display issue)

Discussion in 'Retro & Arcade' started by Thalyn, Nov 12, 2017.

  1. Thalyn

    Thalyn Member

    Joined:
    Jun 2, 2005
    Messages:
    401
    Greetings, OCAU retro crowd! I come to you today to get assistance as to where to start looking with regards to a Commodore 128D that's decided it doesn't want to display text correctly. I'll lead with a picture, then explain a bit more following.

    [​IMG]

    Essentially, what appears to be happening is that bit 2 of the character ID is getting "stuck", for lack of a better term. Not completely stuck, since "COUMOFORG" is clearly trying to the first M, the D and the last E, but it's not succeeding. Those quotation marks are the result of a space with bit 2 active. The same, as with all the following, persist in both C128 and C64 modes (so it has to be something common to both).

    Prior to it showing this, it hadn't been used in quite some time. I don't know exactly how long, but 20 years is not outside the realm of possibility. When it was initially fired up, bit 2 was actually stuck off - the sequence "0123456789" would read as "0101454589" reliably. We (my brother and I) pulled it down, cleaned it out (dust aplenty) and tried switching the CIA chips to see if it did something. And oh boy did it do something!

    Since the screen started to look like what you see there, and some of the keys now weren't working (arrow keys, enter, and some others I don't recall specifically), we figured it was a dud chip. So we switched them back to verify and, while the keys worked again, the screen was now stuck like that. What makes it even more weird is that we switched the CIAs again (I'm not sure why) and the keys now worked while the display stayed corrupted.

    It's not quite as straight-forward as it looks, though (not that it looks straight forward). For starters, the screen will constantly adjust itself. Some of the errors come and go, and over time it actually appears to be "fixing" itself, but it's never perfect. It also gets "better" when the system is under load, such as reading from an SD card adaptor. Copying the character set to RAM and then displaying that instead works just fine, so it stands to reason the character ROM itself isn't the issue. Further to this, if you use a partial graphics mode than a few lines under where the graphics portion ends will be fine, for example:

    [​IMG]

    And the last peculiarity (which I unfortunately don't have photos of) is when filling the screen with characters. If you fill the screen with characters that don't normally contain bit 2 active like "A" than it shows as you'd expect with some of the characters on the left trying to look like a "C" instead, with more failing if you add some actual Cs anywhere on the screen. But if you fill them with a bit 2 character like C than the screen is perfectly stable while the last 8 characters on the bottom line are coloured: black, white, black, red, black, cyan, red, white, in that order every time (or colours 1, 2, 1, 3, 1, 4, 3, 2).

    Since the CIA swap failure (we checked with some donor CIAs from a C64 to verify they weren't the problem), the only thing we've done is re-seat every socketed chip and give the whole thing a going over with a toothbrush and isopropyl. This has apparently made it better (so much so that C64 supposedly almost looked normal) but it still persists. As it stands the only plan is to try that again, this time with an electric toothbrush, and clean up the legs on the two chips which appeared a little dulled (one was for the 80-column display, but I don't recall what the other one was).

    Unfortunately my brother is the "primary" on this one. It's at his place and he's got a Bachelor of Physics, so it's difficult to argue with him given my background is mostly from work experience on ECUs. So I can say he's reluctant to bath it in water of any kind to clean it thoroughly, nor is he keen on the idea of re-capping the whole thing (the two steps that show up frequently when I search for retro PCB restoration). But he's open to ideas and I'm hoping you guys might have some.

    PS We're also having trouble with the floppy drive. If it's plugged in than the drive motor spins and the light stays on, but that's where it stops - literally, as it locks up the system. We've tried switching out the only two socketed chips with a donor 1571 but it didn't help.
     
  2. Flamin Joe

    Flamin Joe Member

    Joined:
    Jun 28, 2001
    Messages:
    3,876
    Location:
    Brisbane
    There are much more qualified Commodore guys on here which I'm sure can help, but I thought I would mention Ray Carson's diagnostic page for the C128 if you haven't looked it up already. His C64 diagnostic page was of great use to me when I was repairing my C64 so it's well worth the read.
     
  3. OP
    OP
    Thalyn

    Thalyn Member

    Joined:
    Jun 2, 2005
    Messages:
    401
    Excellent! Any and all input is welcome, since we're really flying blind at the moment.

    On the plus side (I guess) we've at least ruled out the CPU as the culprit. Got PC/M running, and the Z80 was producing similar garbage, but it seems happy to run programs - even if they're not displaying correctly. Apparently (I wasn't there to witness it myself) it ran Impossible Mission but it was too garbled to solve the puzzles, where Head Over Heels (pure bitmap graphics) ran without a hitch. There was a third title in that list which I've forgotten, but it apparently included scrolling which "worked" in so much as a block of empty characters was there which scrolled into perfectly visible characters as it moved.

    For now I'm mostly just checking circuit diagrams and seeing what is in between the CPUs and the VIC. Anything directly in the path or which touches on the path is probably suspect at this point.
     
  4. callan

    callan Member

    Joined:
    Aug 16, 2001
    Messages:
    4,529
    Location:
    melbourne
    That is quite puzzling. The C128 is a sod to debug: with 2 processors, 2 video chips and an MMU it's a monster - I've had very little to do with fixing the C128 board so my knowledge is scant. Please bear this in mind - I may be leading you astray as this is just what I've been able to deduce from the schematics.

    It doesn't look like a DATA fault but rather an ADDRESSING fault: some of the letters are intact, but the wrong ones. Do remember that the character matrix data FOR THAT LINE ONLY is is fetched I'd normally be looking at RAM multiplexors but that can't be the case: by all accounts RAM is working fine: it's ROM fetches that are getting rogered.
    Accessing character data from the CPU side is fine (as evidenced by copying ROM to RAM and displaying the RAM) and since the VIC is fetching data correctly when accessing RAM I kinda doubt it's the chip, as as far as the VIC is concerned it can't differentiate between a character fetch from ROM or RAM.
    Looking at the block diagram and schematic, CHAROM fetches don't go via the MMU (there are effectively 2 address busses), so that just leaves the PLA to manage chip select and nothing else. I used to think that the C128 had 2 character ROM's but the schematic shows only 1x2K ROM so there must only be the one.
    I'd start off cleaning all sockets / treating them with suspicion (particularly the character ROM). I'd also be deploying a can of freeze spray and seeing if you can identify a temperature-related fault, but there really is very little between the VIC and the ROM (U18), and swap them out of you have spares.
    Here's a thing. The only difference between the C64 and C128 rom pinouts are that pin21 is strapped on the C64, but optionally tied (via jumper) to 64/128 ROM select on the 128. Since the block diagram shows the character ROM as 2K (same as the C64) it implies that the original intention was for a 4K ROM with different 128 to 64 character sets, but production only used the 1. So it's likely a C64 ROM will work in a C128 - they look electrically identical - so at a pinch you could try a C64 character rom. (timings are the same)

    I don't have any other ideas off the top of my head, but that's where I'd start. The only other thing I'd consider is some propagation delay in a failing PLA causing bung CS timing to the ROM, and reads being performed before the ROM is ready. Unlikely but possible.

    Callan
     
  5. sean0118

    sean0118 Member

    Joined:
    Jul 24, 2012
    Messages:
    152
    Location:
    Sydney
    I'm not going to be much help, don't know Commodores at all. But a good starting point is to check all power rails for correct voltage and that they have low ripple.
     
  6. OP
    OP
    Thalyn

    Thalyn Member

    Joined:
    Jun 2, 2005
    Messages:
    401
    Much appreciated, Callan. I'm not 100% sure when I'll get to put any of that into practice but it's definitely somewhere to start - and that character ROM similarity is going to be a useful diagnostic step (we don't have a spare 128, but we do have some space 64s). Given what I've seen in C64 videos, the PLA (or something between it and the VIC) is a likely culprit.

    Curiously, when you mention "heat related fault", how much heat exactly are you talking about? Some of the chips do indeed get warm but nothing so hot that you can't hold your finger on it, but I'm unsure whether that might still be too much.

    Sean0118, you'd be surprised at how difficult it has been to convince my brother to do that kind of "basic" testing. Finally managed to get him to meter the power lines the other day at least, but only really the DC (I can't imagine metering the AC lines to chassis ground is going to be accurate). He does have a CRO but it's never really been calibrated so the feedback from it will be mostly meaningless (but we did see some rather unusual waves - consistent, but not exactly smooth).
     
  7. Phido

    Phido Member

    Joined:
    Jun 20, 2003
    Messages:
    4,435
    Location:
    Dark City
    Agree with Callan.

    I would be going after low hanging fruit, checking the circuit board very carefully for cracks, stains, rust, damage, dry joints, etc. Then I would be looking at getting a new rom.
    I've seen old computers (library search computers) that are so old their character roms started corrupting, usually its losing pixels rather than gaining. Which describes what you are seeing originally. C64 roms are aplenty, you can buy em new, so it would be fairly straightforward to have a go with that. I would be checking those rom legs very, very carefully, maybe redoing them just in case.

    Electrical stuff is hard. Just because you have a physics degree doesn't mean you can handle down to component level repair. You need a lot of knowledge and preferably experience. Even really smart and knowledgeable people go seek other people with more expertise.
    It would be interesting if you ran software that rewrote the character sets, or just used graphics if you would have any problems at all.

    As Callan said the c128 is a weird beast. Even those who know C64 backwards would hesitate, its basically two computers melded together.
     
  8. OP
    OP
    Thalyn

    Thalyn Member

    Joined:
    Jun 2, 2005
    Messages:
    401
    A purely graphical screen is just fine - Head Over Heels basically renders pixel-by-pixel and does so absolutely flawlessly. It's similarly flawless (that I've seen, at least) using RAM-sourced characters, even just having copied them from the ROM directly; though that doesn't fit with Impossible Mission's corruption.
    It could be worse. It could be a C128DCR - those things have merged ROMs, and weren't quite 100% C128 compatible even from factory!

    Currently it's looking like a really thorough physical inspection of the PLA and everything between it and the VIC is in order. I've also grabbed some ROM images for diagnostic cartridges which we'll feed through for another opinion from the machine itself (though it wouldn't surprise me if it showed little useful feedback). For pure curiosity I might also see if I can check it with a C64 CHAROM, since the only difference (as Callan pointed out) appears to be the absence of the C64/C128 selector (supposedly the C128 character set is slightly different, but that may only be in non-English variants going by chip numbers) - either it will be different or it won't, and either is useful to know.

    Perhaps it would be worth my time and money investing in a desoldering station for this one. Dunno how much use it would ever get otherwise, but it's probably cheaper than sourcing an already-working C128D.
     
  9. callan

    callan Member

    Joined:
    Aug 16, 2001
    Messages:
    4,529
    Location:
    melbourne
    I'm not referring to "heat related fault" as being a component that is failing under high temperature, or pumping out more heat than it should: rather behavior that is changing with fluctuations with temperature. Freeze spray is good at tracking those down. At a pinch, "Canned air dusters " from officworks chill chips down rather nicely, particularly as they get towards empty.

    Callan
     
  10. OP
    OP
    Thalyn

    Thalyn Member

    Joined:
    Jun 2, 2005
    Messages:
    401
    Ahh, I see. Not quite sure I understand, but I don't quite understand why this is happening at all so I'm willing to give anything a go.
     
  11. OP
    OP
    Thalyn

    Thalyn Member

    Joined:
    Jun 2, 2005
    Messages:
    401
    Just gonna touch back on this one again....

    I think we may have found a solid lead. Experimenting last night, we found where those errant colours were coming from - they were the 8 bytes after where you would normally expect the colour memory to end on a text screen. Ordinarily there are up to 1,000 "colours" on a text screen (40x25), but colour memory itself actually extends out to 1,024 (it's a 1KB chip, after all). We found that we could reliably change these unexpected colours by writing to the values at 1009 to 1016 - exactly 16 bytes out from where it should be. We could probably find similar offsets on other parts of the screen, but didn't test that (should probably do so, now that I'm thinking about it).

    *ed: So we did go and test it. And, yes, it's consistently inconsistent when it comes to colour as well. So that's something, right?

    16 bytes just also happens to be exactly how far out it is when displaying characters. A character that's 2 "letters" out means its reading data from 16 bytes out, as it's 8 bytes per character. Commonality at last! And further testing has shown the colours to be unstable when the screen isn't covered in bit-2-present characters, so it's also similarly inconsistent.

    So our attention is now turning towards the SA4 line, which should(?) be responsible for setting the binary 16 flag (000x0000) when addressing the character ROM and colour RAM. This line runs from the cartridge port to the VIC-II, with 4 other ICs touching on it along the way: U15, the character ROM; U19, the colour RAM; U55, unknown (links to U6 and U10, the 8502 and Z80 respectively, and U1 and U4, the CIAs); and U17, unknown (links to U14 and U15, which connect to U7, the MMU, as well as U1, U4, U6 and U10).

    Fingers' crossed this is the home stretch. Then we just need to figure out what's up with that 1571...
     
    Last edited: Dec 4, 2017
  12. OP
    OP
    Thalyn

    Thalyn Member

    Joined:
    Jun 2, 2005
    Messages:
    401
    Gah! We thought we had it, but we were wrong.

    Using a CRO, we found a wave with a slow rise - what should be a square wave is a shark fin sawtooth wave. This wave seems to originate on the TA12 line (we also found one on TA13 but that doesn't seem to be causing a problem). TA12, as best I can figure, should only ever be set by the MMU, and a high signal seems to represent a 0 (fits with what we're seeing). It then gets multiplexed with A4 by U14, and output into MA4 and VMA4. VMA4 gets latched through U17 and output on SA4 before hitting U15 or U19 - exactly the line and chips we're experiencing issues with. Since we didn't find any corresponding issue on the A-bus going into the MMU and the pull-up on TA12 tests the same as TA13-15, it stands to reason it's the MMU itself that's the problem - right?

    Well, we replaced the MMU (sourced one from the US) and... it's still doing it. Ugh.

    So I'm really not sure where this leaves us. TA12 could be struggling to go high because of the drain, I guess (some kind of capacitance?), so it may be worth looking into the chips it goes to: U14 (a 74LS257a multiplexer) or U62 (a 74LS244 buffer/driver). It may also be worth trying to increase the current of the pull-up, but I'd be concerned about what long-term effect that might have on those same two chips (how much current can they handle, given they're 1.5mA by design?), or even the MMU itself - plus it should be unnecessary. Otherwise, it's going to be physically looking for a short or contamination somewhere.
     
  13. Grant

    Grant Member

    Joined:
    Jan 23, 2002
    Messages:
    1,187
    Location:
    Wollongong
    I'm not familiar with the schematic, but have you checked the output waveforms of the logic/buffer chips? On the off chance that they've failed in such a way that they're not really buffering the way they're supposed to.
     
  14. OP
    OP
    Thalyn

    Thalyn Member

    Joined:
    Jun 2, 2005
    Messages:
    401
    It's their input that's giving grief, or at least that's how it seems. If it were the output those are easily replaced, or at least easily sourced. Unless they can feed back such an issue, but everything I know suggests that's extremely unlikely (if not impossible).

    I'm planning to buy a desoldering station so we can be a little more invasive with the repairs. It's kinda important that we do eventually get this thing going, after all.
     
  15. OP
    OP
    Thalyn

    Thalyn Member

    Joined:
    Jun 2, 2005
    Messages:
    401
    Success! After a fairly thorough test, I feeling confidant to declare that this one is resolved. I'll outline the last few steps we took, then finish off with what was actually wrong and how we located it for posterity. The short answer is that U17 - a 74LS373 tri-state latch - was failing.

    Starting to grasp at strings by this point, my brother had decided some recapping was in order. When he was telling me about this I'd figured he was talking electrolytics, but it turns out it was the ceramics around the possibly-affected chips that he was talking about. What's curious about these is that they appear to have "leaked" - I didn't even know ceramics could, and frankly I'd rather they couldn't as they seem to form some kind of alloy with solder that has a substantially higher melting point and is much, MUCH more difficult to remove.

    In fact, removing it involved having the vacuum desoldering station on one side (330ºc) while ramming it from the other with one of the cleaning tools. When it did finally come out, it was basically still like a solid plug - as if part of the capacitor (already removed) was still in there, yet they were in tact. The worst of them actually clogged up the desoldering gun, requiring it to be set to maximum temperature (480ºc) and rammed to clear.

    Unfortunately, this didn't help. It appeared to for a little bit, actually, which made for some great disappointment. What it ultimately did do was exacerbate things. I'm not sure if it was due to the heat near the faulty chip, the focus on that part of the board or just inevitability, but while bit 4 (0-base) was now mostly only a problem at the top of the screen, bit 5 was now stuck as a zero (electrically high). Still, that did create an extra diagnostic point, based on the hope that it had the same root cause (turns out it did).

    --What worked--

    So, back out with the CRO and a wiring diagram. A quick check of the MMU found more sawtooth waves (we should have checked this earlier), so as odd as they may have been it seems that's normal and expected behaviour. We then followed the signal back from the character ROM (U15) and colour RAM (U19) to see if we could find where it went bad. Our figuring was that it had to be the link to VIC which was faulty, since you could manipulate everything from the CPU side perfectly both reading (copying characters out of ROM, reading back colours) and writing (it clearly knew what the correct characters and colours were, since it was "trying" to display them) - it was only having trouble displaying it.

    When we hit U17, we found the input was behaving pretty much as expected - square waves, cycling quickly as it rapidly changed between characters and colour, and followed the retrace of the screen. The output, though, was a mess. Bits 0 through 3, 6 and 7 were behaving as expected (patterned square waves), but bit 4 was dancing all over the place (including even higher than the "high" measurement) and bit 5 was basically a constant square wave; though the CRO couldn't sync with it. This seemed a very likely culprit, and we were also running out of "possibles". There wasn't much left after U17 to trace, since it then connects to both the MMU (already tested by substitution) and VIC (believed to be good based on what did work).

    A trip to Jaycar later (who keep 74LS373s behind the counter for under $2, in case it comes up) and we cautiously booted the system with a new chip (now socketed) in place of U17. It was stable. Not convinced due to our earlier "success" with the caps, we rebooted it a couple of times, switched in and out of C64 mode, and switched it off and on a couple times. Still stable. Mission Impossible comes out, since that's been the "killer" application - every time we thought it had come good, it failed again during that game. Still stable!

    Back together it went, mostly to restore the "heatsink". The 30-year old white silicon TIM was removed and some new Noctua NT-H1 was put in place, just for good measure, and we loaded up IK+ to test a couple of joysticks (a genuine Commodore and my own prototype arcade-style stick) as well as the system itself. Booyah! When I was eliminated, we switched over to Wizball since weeks ago we'd decided that finishing it was a good test (lots of colour changes, scrolling, and hours of gameplay time). 2-3 hours later we cleared stage 8 and declared that it was, indeed, stable.

    In hindsight, we probably could have reached this point a lot sooner. Nothing we'd done earlier would have changed what we eventually found, so if we'd know what we were looking for (or at) it could have been a quicker, cheaper and far less frustrating process. But this was the first repair like this that either of us had attempted and we didn't exactly know our way around. Now it's time to look into the FDD controller (finally found a diagram of the 128D controller, instead of the stand-alone 1571 - they're slightly different electrically), as well as a few more old systems which deserve new life (an Apple IIe, Mac Classic and some VIC-20s).

    TL;DR: Traced back from what was giving the wrong results to see what was asking the wrong questions. Found bad output at U17 but seemingly good input. Replaced U17 and nostalgia ensued. "Another visitor. Stay awhile. Stay forever!"

    Both my brother and I would like to thank those of you who took the time to reply to this post, and even those who read it on the off chance they might be able to help but didn't reply because they weren't sure. Hopefully our journey helps in another restoration somewhere.
     
  16. ohayes

    ohayes Member

    Joined:
    Jul 3, 2007
    Messages:
    547
    Location:
    Sydney
    Great thread thanks for sharing - glad you guys were able to bring this classic computer back from the brink!
     
  17. ShaggyMoose

    ShaggyMoose Member

    Joined:
    Jul 1, 2002
    Messages:
    322
    Location:
    Sydney
    Good to hear you got it working. Thanks for sharing the details.
     

Share This Page