Back from the Grave: Commodore VIC-20 (Part 2: blank, dark screen)

Contrary to popular (at the time) belief, the "20" in "VIC-20" wasn't actually a reference to any part of the system.  Speculation varied, from it being a reference to its horizontal text resolution (which was actually 22 columns), the total size of the system memory (16KB of ROM and 5KB of RAM, for 21KB total), revision numbers, IC count (the original version had 32 chips, the "CR" or D version had 26; both had 7 proprietary chips), speed references or all manner of other potential origins.

As it turns out, however, it was much less meaningful.  According to Michael Tomczyk (responsible for leading development on the VIC-20), in an interview in 1996, 20 was simply chosen as it was "a friendly number" to offset that VIC "sounded like a truck driver".  It was, after all, "the friendly computer".


If I'm perfectly honest, I wasn't actually expecting to be writing this particular post just yet.  Given our experience so far I had expected that the second rescue machine would be the next one we'd get running but, as it turns out, we're still not quite there with that unit.  Instead, we managed to fully restore my old unit to working order.

In the end, we found three issues with this machine: two of them fatal, one minor, but all three repairable.

The first issue we discovered was that the 6502 was stalling.  From our experience, we knew this could be caused by a couple of things: removing one of the low RAM chips, removing the kernel ROM, removing the data line buffer and removing the block controller.  Having already socketed these chips and tested them we knew that these components individually worked, which meant it was either the interconnects or the CPU itself.

In this case, the easiest option was to test the CPU itself in another system, since it had been socketed by now.  Within seconds we knew that the CPU was the problem - or at least part of the problem - and would need to be replaced.  Fortunately, 6502s are quite easy to source and we have access to a few substitutes, so this was a relatively painless fix in both the short and the long term.

This would not solve the problem.  A known-working CPU was still stalling exactly the same, which pointed us back to either the chips or the connections.   Since we knew the chips were good, the only other option was board damage.  Locating this is a matter of trial and error with a continuity tester and a circuit diagram - finding which pins should link together, and ensuring they actually are.  Since the system hadn't been abused I wasn't expecting anything, but we were running short of ideas.

As it happens, this was exactly the right idea.  We would eventually discover that address line 13 (base 0) was not connecting to UC5 - the block controller.  This chip is responsible for determining which upper RAM or ROM chip was in use, with that particular line being the deciding factor in which ROM - kernel or BASIC - was active.  While this would need to be remedied regardless, that also meant it was possible this was stalling the processor by denying access to the kernel ROM.

After fitting a patch lead and restoring CA13 to the block controller, we fired it up and anticipated we'd now be looking for another issue.  While we were partially right, we were mostly wrong - it booted perfectly.  We left it running for a few minutes for an initial stability check, then rebooted it a couple of times just to make sure.  It was solid.  Now it was time to test execution before declaring it finished, closing it up and moving on to the last of the VICs.

Sadly, it was here we found our minor issue.  While the system was perfectly stable, running everything we threw at it, it had a peculiar fault.  Some lines of text would start to "bleed" towards the right, even going into the border, and a buzzing would occur.  In many ways it was reminiscent of the C128, in so much as it required enough of certain characters to happen, where other combinations would render without fault.  Unlike the C128, however, there are no corresponding multiplexer chips which could be responsible.

Given that it was bleeding into the boarder, we figured that it had to be something between the VIC chip and the display, since VIC can't easily do that on demand (certainly not easy enough to be an accident).  We knew the RF unit to be good, which left an assortment of components on the board itself.  Analysis with a scope, however, didn't pick up any noticeable signal issues - nor did it pick up the source of the buzzing.  Before setting about removing and testing each part one by one, though, we decided to quickly check the pots (potentiometers) as this could be done quickly and easily.

Turns out this was once again the right course of action.  Turning the first pot resulted in both the visual distortion and the buzzing disappearing, though turning it too far would cause issues with brightness and contrast.  We settled on a position with good colour and no errors, only to then discover that the pot on our last VIC-20 was in this same position - a good indicator that we were in the right.

We now have a second working VIC-20.  It still needs a clean (the cassette and user ports were a mess), but as yet we're unsure as to what to do with it.  For now it's going to be a test bed for the last VIC's repairs, as well as testing various accessories we will likely need to at least service, if not repair.

So, with all that, you might wonder why I was surprised that we got it working.  As this was the furthest-from-working system, we were only really glancing at it in the background.  In order to test the other machine we had actually wound up removing every chip on the board save the 555 timer, the colour RAM selector and the character ROM.  We'd confirmed that every one of these chips (save the CPU) was in fact working perfectly, so we were expecting this one's repairs to be something of a crap-shoot (or a complete mess).  Turns out, thankfully, we were wrong.

That's all for part two this three part BftG.  One more VIC-20 and some accessories to go, and then it's on to the Amigas.  This last one, however, may take a bit as it actually works - it just stops doing so without being told, and intermittent faults are the worst of them all to diagnose.

Remember that electricity can be dangerous to both property and life.  If you don't respect it you can wind up seriously hurting or even killing yourself or others, and chances are it's going to be painful while it's happening.  Unless you're sure of what you're doing, avoid tampering with any electrical circuit - especially when it's live or mains powered - and always ensure you have a nearby assistant who can contact emergency services.