Commodore 128D
Good evening and welcome to Tinkering with Atkelar! It is time for a bit of a breather from the recent flood of test equipment. To this end, I dug out a home computer of the mid-1980s that is getting a bit too little exposure it seems. There is a ton of videos about the Commodore 64, but not about what I consider its successor, the Commodore 128. Commodore set out to create a compatible system so people could still play all their C64 games, which is probably what made this system so weird and full of compromises in the first place.
It is essentially three systems in one. The 128 native system, with 128 kilobytes of RAM, the C64 with all its support chips for full hardware compatibility, and a CPM mode complete with the mandatory Z80 CPU. So since the integrated floppy drive is also compatible with the C64 drives, we end up with three CPUs and two graphics chips inside. To top it off, Commodore offered the 128 in two versions. A low-end one, and a high-end one.
This model here is the high-end version. The low-end version would look more like an Amiga 500 with different keyboard. I got lucky on a German marketplace site, and thanks to a friend in Berlin, the "Pickup Only" offer was also forwarded to me without issue. Thanks! The 128D has the keyboard tucked in on the underside of the case, and a carry handle on the side, making it somewhat portable. The main unit contains a power supply, the floppy drive and a controller board as well as the main PCB. The floppy controller board is the first to be removed.
It blocks access to all the other components. Then there is the front panel. It is held in place with three screws and a few latches. Followed by the floppy drive itself. Next we have the power supply. Oh, a fan! That's new! Now finally, the main PCB. It is somewhat
stuck inside the case. To free the rear sockets, you need to slide it forwards. But to free the ones on the right, you need to slide it left. I'm not sure if that board even can come out without bending anything.
And last but not least, there's two cover plates for the bottom part of the case. The front one is essentially the fan intake. The rear one is the storage location for the keyboard cable. The handle is held in place with two pins for hinges. They are... hot glued in place? Hmm... must be a
special high-end hot glue. Recapping! Let's start by removing the shield from the floppy controller board. Now to unwrap the main PCB. It seems that Commodore is using the shield as a heat sink for most of the chips too. Oh! Some botch wires! On both sides even, there have been multiple revisions of the board.
Maybe this was updated before shipping? The display controller chips are hidden in another shielded can, as is the RF modulator. This one also doubles as a heat sink. Notice the empty socket? It is for a feature ROM. That is, in a way, a
built-in cartridge slot. There is apparently a GEOS version available for it, amongst a few others. Would be interesting to make a switching option for it. Several ROMs with a selection switch out the back.
Maybe a future project? Anyhow, after removing all the electrolytics, and one ceramic by accident, I move on to the power supply. It has a few caps too, and a fan that is slightly too loud for my taste. Good thing that these haven't changed size in ages. I'll order a quieter one. The floppy drive is a bit of a special case. There are some electrolytics on the motorboard, but to get that one off, the top has to be removed first. Now mechanically, the floppy is in near-mint condition, so I keep the heads attached to preserve the alignment.
The keyboard is next. Naturally. After a bit of poking and prodding, the screws underneath the rubber feet become obvious. The keyboard is pretty much exactly the same mechanism as the classic C64 keyboard, only with a few additional keys. That includes three lock keys for shift, caps and 80 column boot mode, which are soldered to the PCB with little wires. I give all the plungers and contacts a quick scrub.
There was some faint residue on the metal plate that felt like soda. So better be safe than sorry, now that I have it apart. And after cleaning the metal plate, starting with the freshly cleaned keys again. At the end, there even was a spring left! Oh wait, the space bar had three! Not just two! There, all done! Putting the keyboard back together, including the riser feet and ziptie strain relief.
Soldering in the new capacitors for the power supply. And for the RF modulator. And for the floppy drive. Note that I had to mount the caps at an angle, since the PCB sits very close to the base plate of the drive and I couldn't find the low profile caps this time.
And finally, the main PCB. After a good clean, it's assembly time! First of course, the power supply. It creates a 5V rail as well as a 9V AC line, so that the user port is compatible with the C64. And a 12V line for the floppy drive.
I tried to fire it up, but it would jump to nominal 5V output and then just shut down again. Seems that this one needs a load to run. I put the 22 ohm resistor across the 5V rail and yes, it runs! Now for the actual computer. I'm doing a quick function check first. With all the shielding, it's a pain to open it up again later.
I put my TV up and see if the 40 column output, the 64-VIC video, works. This would cover both the Luma-Chroma signals as well as the RF modulator. Well, I got an empty screen, but when I disconnected the keyboard, it started up fine. Huh? Oh, turns out I just misread the manual. Pressing the 80-40 key is requesting 80 column mode. And that is the RGBI output, not the normal video one. So all good on this one.
What is a bit more annoying is the lack of color. Again, a bit of tuning for the PAL color signal, and there is color. Woo-hoo! Well, at least in the RF signal. Oh wait, the cable for the video connection has Luma-Chroma separated, and my TV only has composite input. Whoops! With the composite cable from my C64, it started to work fine. The RGBI has no adjustments, so now, slapping the covers on it and putting it into the box again, so I can put a disc in it and try to load something with sound.
A bit improvised, but here we go. Floppy drive ready. I checked in C64 mode and yes, the drive reads one of my disks. So, time to load a classic for the sound test! Ah, Maniac Mansion! I love that game! The audio carrier in the RF modulator needed some tweaking, but all is well there too! And now, a bit of a spoiler! A freshly restored Commodore 1084S monitor to test the RGBi as well as the Chroma/Luma lines. Works fine! Well, all seems good! Closing up the case again...
And just for fun, I decided to format a disk. The 128 has a command for it called "header". It also comes with a directory command to list the contents of the disk. Sweet! But...
umm... the headline of the directory was smeared across the display? What? Side note, some of you might already know what's going on, but I couldn't find any hint on Google, so I dug into the issue, and here's what I found out. Now I can't let that slide at all. I want
a fully working unit, and this is not going to fly. It seems that whenever too many inverted characters are showing up in a text line, the horizontal screen lines get jumbled up. I assumed that the video controller chip is missing the internal counter due to a weird bit pattern. I ruled out a screen problem early on, since typing inverted text didn't cause the issue, but once a white space was at the end of the text, or multiple ones inside the inverted text, BAM! Smearing! I opened up the case again, removed the shields again, and poked around in the color and sync signals that came off the video chip.
Nothing suspicious. To check if a particular color channel, RGB or I was to blame, I repeated the test with various colors. And indeed, color made a difference. Only when the intensity bit was set, the smearing occurred.
But still, nothing seemed out of the ordinary, until... I double-checked the output on the horizontal sync line again. Clearly, something is off on that one. Now, the graphics chip outputs RGBi signals directly, but they are routed through a driver I see before they go off to the connector. And here I saw something strange. The vertical sync signal was as expected. TTL
in, TTL out. As were the color channels. But the horizontal one? TTL in, and... something out? Whatever it was, it was no clean TTL rectangle. And it also seemed to have occasional crosstalk from the pixel lines in between the sync pulses. Now that is a clue! But nothing in the circuit should be able to influence the signal. It is only passed to the connector and a few chips that create a monochrome signal on pin 7.
I thought that I might have bridged some contacts with a spec of solder, so I triple-checked the PCB underside. Still nothing. And on a hunch, I unplugged the monitor and checked the sync signal... which was perfect! Yikes! A quick glance at the monitor schematic shows that the RGBi connector has pins 7 and 8 connected, which are H-sync and the monochrome signal. So, it seems that the monochrome signal is bleeding into the sync signal via the monitor, and that throws off the monitors sync circuit when there is too high of a level coming in from the monochrome line between regular sync intervals. To double-check my suspicion, I desoldered the ferrite bead for the monochrome output and tried again.
Perfect sync pulses and a crisp picture! I soldered the bead back into place and wrapped up the case again. So indeed, if you run a 128 on a 1084S with a 1 to 1 RGBi cable, this can be the result. Will it always behave like that? Maybe. It might be a weird combination of tolerances on my set here, but it is certainly a possibility. The original cable that Commodore used might have omitted pin 7. Either way, I don't want to modify any of my components since I want to use my monitor for some other computer and I might connect a different monitor to the 128.
And naturally, I also want to keep the cable I have intact. So... Let's make an adapter! As luck would have it, I had a male and female 9-pin connector around, so I soldered them together, one by one, keeping pin 7 clear. And it works! Perfectly serviceable! And that's it! An interesting part of home computing history! While the Commodore 128 didn't catch on nearly as much as the C64 did, I still think of it as a milestone. If only that people learn from it that keeping up hardware compatibility at the chip level is a bit... umm... problematic. I can't say I have seen similar approaches in any newer machine, but then again, I only know so many of them myself. I hope you enjoyed this episode! See you next time! I still think of it as a milestone. If
only that people learn from it to keep... nope, not to keep.
2025-03-22 19:15
