The Commodore 64. Arguably the best known home PC ever made, and certainly the most popular single model ever produced having shipped an estimated 10 to 17 million units in its 12 year lifespan. As far as completely 8-bit units were concerned, there simply wasn't anything better: 64KB of RAM, 16 colours (up to 4 usable at the same time), 8 hardware sprites, 3-channel fully synthesised sound, a generous 320x200 display (160x200 in multi-colour) and plenty of inputs and outputs. Other vendors needed to use 16-bit components just to keep up, and it still wasn't enough.
Eventually the C64 would ultimately be defeated by itself. The vast majority of its software became gaming related and the 8-bit system simply couldn't compete against the emerging 16-bit console market. With no direct successor to keep its design legacy alive, the rise of the x86 ecosystem, now moving to 32-bit, was simply the final nail in the coffin.
This particular C64 breadbin was part of a bulk lot we purchased at some point in the '90s, with around 5 breadbin units and 2 slimline units in unknown working order. By this point we had, as many others, transitioned to the x86 system, so they remained in a cupboard until just recently.
The problem in this case both was and was not immediately apparent. Immediately obvious was that the amount of BASIC RAM free was incorrect - instead of reporting 38911 bytes free, it would randomly report anything from 10 (yes, ten) to around 20,000. It would also behave somewhat appropriately when the limit was lowered, sometimes even booting immediately to an "out of memory" prompt.
What was not so obvious, however, were a series of @ symbols already present on the screen. On start-up, the C64 automatically sets all of the text colours to be the same as the dark blue background colour. As a result, these characters were invisible - but still very much present, as they would interfere with lines as they were typed. Changing the background colour would cause them to immediately appear.
Since there was clearly a RAM issue, it was assumed that the two were related. A corrupt RAM chip could be responsible for both. Since the characters were meant to be space (binary 0000 0000) and were showing up as @ (binary 0100 0000), it stood to reason that the fault was coming from bit 6's (base 0) data channel. Because all of the characters weren't affected, and the @s were always in the same place, it was not being caused by a short or break in the circuit - the RAM chip itself was likely at fault.
A donor RAM chip would go on to confirm this. Since the C64, like the Apple II, uses 8 RAM chips (they're actually the same chip type), each providing 1 bit of data, it was a matter of finding out which chip was responsible for bit 6 and replacing it. After switching the chip (U24) out, the @s were gone. This also corrected the instability of the amount of BASIC RAM reported - it was now firmly on 212 bytes free, which could be confirmed in testing. Since there were no longer any visible artifacts we could use for diagnostics, we had to resort to alternative means.
Following a quick search, a sticky thread on the Lemon64 forums yielded a BASIC memory test program. It would write 255 (all bits on) to a memory location, check to see if it could read back 255, then do the same with 0 (all bits off) starting at around 20KB and continuing all the way to the 64KB limit. While slow, it didn't take long to start yielding a pattern: bit 1 (base 0) was often sticking off (255 became 253), and every 256 bytes it was sticking on (0 became 2).
Once more a donor chip would confirm the issue as being a faulty RAM chip. Another chip (U9) was switched out, and the system would now boot with 38911 bytes free every time. The system was operational, which meant we could move on to stability and functionality testing. It was here we would discover both an issue and a curiosity.
The issue was, quite simply, that there was no sound. At all. Since the SID chip only accepts data from the system and cannot return any, there was no pragmatic way to diagnose the issue. SID was also socketed, however, and usually is, so we were able to quickly substitute it for a test. Much like the RAM the substitute chip worked perfectly and we once again had sound.
As for the curiosity... I will admit that I still don't fully understand why it occurs, or why it is limited in its effects. Commodore released 3 different KERNAL ROMs for the C64, aptly named 01, 02 and 03. 01 was only ever released in early NTSC units, where 03 would eventually go on to be the C128's C64-mode KERNAL. This particular unit had an 02 ROM, which resulted in some colour changes not occurring properly - mostly on the CBM loader program (SD2IEC) and some hacker intro screens. No other issues were apparent.
Using a fresh dump of the KERNAL from an 03-fitted unit (and the BASIC ROM from the same, as you cannot disable the KERNAL ROM without also disabling the BASIC ROM), we were able to confirm that the issue was entirely the fault of the 02 KERNAL. Upon uploading and switching to the newer ROM data, the colours would render correctly.
That concludes this BftG. While we did go on to replace all of the other RAM chips in this unit (we wanted them to physically match, but there was also a risk that the other chips may develop similar faults in time), and discovered we had a spare 03 ROM we could switch in as well, both of these steps were completely unnecessary as far as having the system working was concerned. Now we just need to figure out what we're doing with this particular unit.
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.
No comments:
Post a Comment