Commodore 8296D: De-Deutsch-ification

Some years ago I picked up a Commodore 8296-D from a kind fellow aus Deutschland (from Germany).

If you don't know about the C= 8296-D, it is a computer similar to a CBM 8096-SK, but with built in CBM 8250-compatible dual disk drives and the Execudesk rom and software package.  The 8096-SK, if you don't know, is the new-"Porsche" style of the CBM 8096 computer.  And the CBM 8096, in turn, is a CBM 8032 with 64k expansion.  The 8032 is the 80 column version of the Commodore PET 4032-12.  If you don't know what the PET 4032 is, shame on you.

Since I loved the 8296 so much, it quickly became a member of my official PETting Zoo.
Several reasons eventually put it on my workbench.  One is to "re-cap" the Matsushita drive mechanisms.  They are notorious for leaking capacitors, and that notoriety is well-known to this collection.  Every Matsushita drive I have inspected has had at least one leaking capacitor.

Another task was to fix the internal roms.  The computer had been born in Germany as an english 50hz 220V Execudesk computer, but at some point had been converted to a German 8096-SK-D by replacing the Execudesk rom with a German editor rom, and the addition of a Paperclip-software chip, both on hand-written 462532 EPROMs.

The last task had to do with the internal fan on its magical power supply.  For some reason I cannot explain, the power supply works perfectly at U.S. 110V.  Nice for me!  However, the fan only operated at 220V.  A simple fix.

The first task was to recap the drives.  These would be the 5th and 6th such drives I've done.  This wasn't exactly a "new" task, and yet on the second of the two, I had a hell of a time with two of the screws on the magnetic platter. In fact, these were the first unturnable screws I'd ever encountered.   After researching the problem on the internet and trying several things, I had only made the problem much worse.

The last thing I wanted to do was take a drill to them in order to use a stripped screw remover, but that is exactly what it took.  Luckily only one of these drives suffered this fate, and I'll know more to avoid it in the future.

The second task was the ROM replacement.  Unfortunately, I had no spare 2532 ROMs.  So I ordered some compatibles off eBay, and received TMS 2532As, which I discovered, to my great annoyance, are unprogrammable by either my Prominade C1, the parallel port-based programmer on my PC 50-II, or my modern PC's USB-based programmer.  In frustration, I ended up re-purposing the Paperclip rom (I had others).  I burnt the english Execudesk rom, same as the one on my U.S. CBM 8296 computer, and plugged it in.

To my surprise, this didn't work.  The Execudesk menu was shifted too far to the left.  While that was only a mild annoyance on that particular menu, a similar problem made BASIC unusable.  I had discovered that there truly is a difference between 50hz and 60hz PET editor roms, and what I needed was a 50hz Execudesk.  Some research uncovered the fact that my U.S. Execudesk ROM was identical to the PET Editor 4.0 60hz rom, with the addition of the menu code at the end.  So all I did to generate a 50hz version was to add the Execudesk code to the end of the PET Editor 4.0 50hz rom.  In the end, I got my PET Editor 4.0 50hz Execudesk rom, and the computer was in business.

The last task was the simplest.  Find a 3 x 3 x 1.5 inch 110V fan, and swap.  Easy-Peasy.

The PETting Zoo is whole again!

The Commodore 128D Journey Ends

This is the final installment in my four-part walk through of repairing and upgrading my old Commodore 128DCR.

When we left off, I was trouble-shooting a problem with the section of the C128's address bus that touches the back cartridge port.  Several months ago, a lightning storm had sent a surge through the network wiring in my house, zapping a network cartridge in that port.

The four chips pictured above are the only four on that leg of the address bus, from left->right: Character ROM, 2k video ram, flip flop, and bus tranceiver.  The Char-ROM had already been replaced when I first started working on the computer, since it was strange character shapes that told me something was wrong.  It was a failed attempt to use a diagnostic cartridge in the cartridge port that told me that there was still something amiss in that area.

After narrowing down the problem, I ended up replacing the flip flop and tranceiver, socketing them as you can see above.  I then tried the diagnostic cartridge again.

The cartridge did boot this time, so those chip swaps were not in vain.  However, the cartridge would now lock up when it got to the Color RAM test.  This told me that the final unreplaced chip, the 3517B-15 2k ram chip, also needed socketing and replacing.

After doing that, the computer was finally able to run through an entire diagnostic check, finding no other issues.

I was finally able to get back to my upgrades!

The only upgrade I had not yet completed was a second sound chip for stereo sound.  I was going to use a SID2SID board (a pre-built PCB that saves a ton of time and dinky wires for second sound chip installation), but the board did not fit under the C128DCR's power supply.

I also gave piggybacking the sound chips a go, but the legs on those 8580 SIDs just weren't holding solder at the low temperatures, and those sound chips are just too expensive to risk higher temperatures.  For piggybacking, I had even constructed a small signal sub-board, and figured out how to get the filter capacitors on the second chip without soldering them.  However, like I said, piggybacking wasn't happening.

So I went back to the SID2SID board and basically attached an extension cable, so that the SID2SID board could be mounted elsewhere in the case.

To make the board easy to remove, yet firmly mounted, I chose to hot glue the board to a corner of the top of the metal RF adapter case, careful not to allow any short-circuits.  I also chose to use test-lead clips for some of the other necessary signals instead of soldering more wires directly to the board, including ground.  In the end, you can see that it's quite a mess there, but quick and easy to assemble and disassemble when necessary.

A quick test using a type-in program from the Commodore Programmers Reference Guide allowed me to confirm that all 3 voices on both chips were functional.  Since I had clipped the chip select to pin 7 of the cartridge port, the second SID would be found at I/O port address $DE00, which is typical.  However, a switch would allow me to release that port for other uses by shorting the chip select pin on the second SID to 5V (pin 3 on the cartridge port).

All of my upgrades were done!

In the last entry about this journey, you saw that I had actually removed the entire motherboard for the chip replacements.  So now it was time to put everything back together.

Once everything was reassembled, I ran it through one more pass of the diagnostic cartridge (even to the point of attaching the port-testing leads, not shown here) before putting the case top back on.

And that's all there is to it.  All shiny and clean and upgraded! She has:

• All the stock features of the Commodore 128DCR, of course, including 128K of user ram, 64k of 80 column video ram, and 2k of C64 color video ram.
• 2 new built in software packages in a switchable option rom, 
• JiffyDOS kernal rom, also switchable
• Second SID sound chip for stereo music
• SuperMMU 128 for interaction with the SuperCPU accellerator card I'll plug back in
• 4GB UIEC/SD internal compact flash card disk drive, complete with enable switch, as well as forward/backward button for quick disk-image mounting.
• A thoroughly repaired address bus, including 4 new socketed chips.

I hope you found this useful!

The Commodore 128D Journey: Crossroads

Sometimes it is when things seem to be going very well that you discover you've been whistling past the graveyard without even knowing it.

If you followed the first two posts on this journey, you know that we last left off with a final project to add dual stereo SID (sound) chips.  This project has been set aside to solve a more dire problem.

At one point, I paused to run a full diagnostic on the Commodore 128DCR, to make sure everything was OK after all the insertions and removals of the MMU that came from messing with the sound socket (shown above).  That's when I discovered that the diagnostic cartridge, which works fine on a flat C128, didn't boot at all.  Testing other cartridges revealed the same behavior -- cartridges simply would not boot correctly.

However, everything else about the computer SEEMed fine.  C64, C128, and Z80/CPM modes all booted normally and ran software normally.  Everything seemed OK.  But cartridges were definitely not working.

Luckily for me, while the C128 diagnostic cartridge would not boot at all, it would crash into the C128's Machine Language Monitor program, allowing me to take a quick glance at the code in Bank 10, addresses $8000 - .   That address is where the software of the ROM chip inside the diagnostic cartridge would be mapped to in the C128's memory.  $8034 also happened to be where the cartridge software would crash. Using the ML Monitor to disassemble that area of memory revealed, unsurprisingly, that many of the ML commands were corrupted, but only maybe 10% of them.  For some reason, this suggested a problem with the Address bus, which is one of the most complicated systems inside an already complicated computer like the C128.

You see, if one of the many chips that translates and routes a particular memory address to a particular chip in the system has gone bad, this would explain why some entire ROM bytes are being presented incorrectly to the ML monitor (and the CPU!).  Since I know the data inside the cartridge is good, and the data is not generally scrambled, I dismissed the Data bus as a possible culprit.  No, my focus would be the complex Address bus.

To solve this problem, I removed the motherboard from the computer and Got Serious.

I began running other tests, and taking care of some low-hanging fruit:

• I carefully cleaned the pins on both cartridges, and the cartridge port.  No help.
• I tested continuity between all cartridge port pins and an external cartridge.  All checked out.
• I wrote and ran a BASIC program that tested as much of the RAM chips as it could.  No errors.
• I swapped out the 8722 MMU (shown above) since it was socketed, and I have several spares.  No changes.

Since I had decided to focus on the Address bus, and had already tried the MMU, I decided to go after the MOS 8721 PLA (Programmable Logic Array). While the PLA is not socketed, I did have several spares, so it seemed a relatively harmless thing to try.  So I snipped out the old PLA, did one of the best de-soldering jobs of my life to remove the pins and clean out the holes, and soldered back in a precision 48 pin socket.  I went slowly and carefully -- It took all of an evening.  

But when I put the new PLA into the socket and powered on the computer with the diagnostic cartridge in place, nothing had changed.  It was all for naught and I felt like an idiot for risking that part of the motherboard.

I was now at a bit of a loss, so I decided to go back to the beginning and focus on the information at hand: the cartridge crashes into the ML monitor, and I had access to the Machine Language commands and bytes, corrupted versions of those in the diagnostic cartridge, that were causing the crash.  I went online and actually found a binary copy of the firmware for one of the diagnostic cartridges (the one on the left in the picture above, marked simply "C128").  The firmware is for Commodore 128 Diagnostic Revision 588121.  You can download it yourself here.

Having access to the bytes that SHOULD be shown in the ML Monitor but were not, I printed out those correct bytes on a piece of paper, and compared them to the bytes shown in the ML monitor.  Whenever a byte did not match, I crossed it out in blue and wrote in the Corrupted byte shown in the ML monitor.

As you can see, there were several bad bytes discovered.  Upon reflection, I realized two patterns in the bad bytes:

1. Every bad byte was at an even numbered address: $8024, $802e, $803a, etc..
2. Every bad byte was strangely *close*, in value, to the byte after it, often matching exactly: $9f/$9a, $cd/$ca, $20/$20, $00/$00, $00/$06, $00/$00, $9d/$9d, $bd/$bd, $9b/$9b, $80/$80...

Both of those facts made me seriously think that something might be wrong with the Address line that handles the first/lowest/0 bit on the address bus, often called 'A0' on schematics.  If this bit were being incorrectly held high, then attempts to read even numbered addresses would instead grab values from the odd numbered one right after it.  

So back to the schematics I went.  I learned that the low address byte on the cartridge port is part of the "SA0 - SA7" address bus.  The high byte is called the "TA0 - TA7" bus.  The SA lines are my focus.  They touch several chips in the upper-middle area of the motherboard, including, strangely enough, the MOS 390059 Character ROM chip.  If you recall, replacing a bad Character ROM was what actually started this entire journey, so, in a way, I had my first confirmation that I was on the right track.

Further study of the schematic shows that this SA0-SA7 address bus touches four different chips: the Character ROM, a color memory ram chip (?!), and two other chips (a tranceiver and a flip/flop) which appear to translate other address busses: the main 'A' CPU address bus, and an address bus called the 'VMA0 - VMA7' address bus (I did warn you this computer had a complicated address bus system!).  Those chips, at locations U55, U17, U18, and U19, are pictured at the bottom left of the photo below:

And this is where I will end our journey today.  My next step will be to tackle socketing and replacing those two address bus translation chips, starting with the transceiver (a 74F245N), since it handles translation for the main address bus.  Hopefully, my next entry on this journey will regard its end.

Good night!

A CIA Mystery

My olde Trusty Commodore 128, a constant companion since the mid-1980s, recently developed a little problem.

The first sign was a locked-up IEC (disk drive) bus when booting into C128 mode, which locked up the computer as well.  If you don't know, this is possible because the C128 kernal checks for a bootable disk in device #8 at boot-time.  Anyway, the bus lock would prevent the computer from giving a prompt.  C64 mode, since it did not perform this initial check, was fine. Restarting the computer usually put things right, but it was still a concern.

Then, the other day I tried to boot the computer into Z80 (CP/M) mode.  After CP/M finished booting, I tried entering some commands to discover that the keyboard was unresponsive.  A quick check revealed that the keyboard still worked absolutely fine if the computer was booted into either C128 or C64 mode.

So, intermittent IEC bus problems, keyboard problems -- sounds like a bad I/O chip.  And in the Commodore 128, that means it has something to do with one of the two MOS 6526 CIA (Complex Interface Adapter) chips.

You can see the two CIA chips circled above.

Now, the problem could be something internal to the chip (meaning Bad Chip), or it could be that the chip is not properly seated.  There is also the question as to WHICH of the two is responsible for the problems.  Swapping them answers all those questions.  As a stroke of luck would have it, both of the C128 CIA chips are socketed! Woohoo! That means swapping is trivial.

So I swapped them.

And here's the crazy thing.  After the swap, the IEC problems went away, as did the problems with the keyboard when CP/M was booted.  However, now the keyboard is entirely non-functional in both C64 and C128 mode.

Clearly one of the CIA chips was bad, so I made an educated guess that the original bad chip was the one in the back left, replaced it, and now the computer is fine.

But what are the implications of the fact that a different CIA chip handles keyboard I/O depending on whether the Z80 or 8502 is active?

The CBM-Hackers mailing list is mostly unsure.  Bil Herd might know, so I may shoot him and email and post any updates if he has any insights.

Completing the Set

Between 1997 and 2002, I collected well over a hundred Commodore computers, and dozens of disk drives, printers, monitors, modems, and other accessories.  By the time I stopped, my "Wanted" list had shrunk to almost nothing, and many of the things on it where only unicorn-like objects of rumor.

One of those computers was the Commodore 264, the namesake model of the "264 Series".  A set of computers based around the MOS 7360 "TED" chip, which grants the series the sometimes moniker of "TED Machines".  This series includes the Commodore 116, Commodore 16, Commodore 232, Commodore 264, Commodore Plus/4, and Commodore V364.

Luck and circumstance allowed me to find every machine on the list above, except one: The Commodore 264.  All my searching had only revealed one other owner, and while he was not selling, I did secure a promise that I would get first right of refusal when he does. :)

Thirteen years later, you'd think I'd have forgotten about it.  But a mindlessly OCD collector never forgets, and I finally struck gold on eBay:

This unit left the Commodore U.S. offices for a game company called Infocom, where it played some role in the porting of their famous Zork trilogy to the Plus/4.  A few years later, a fellow from Rhode Island was granted a tour of Infocom, his favorite game company.  He was given this computer, which the company no longer needed, as a gift.  After deciding it was not interesting, it went into storage until the owner decided the storage was a bit too full, and some of it needed to go.  So to eBay went this computer, and finally to my Commodore lab.

After taking it from the box, the first thing I noticed was that it needed a good cleaning, but that it was in remarkably good cosmetic condition.  An external inspection revealed that it did indeed share its case design with the Plus/4, with the exception that the power connector was an old round C64-style DIN connector, instead of the square custom connector common on the Plus/4s.

The case was held closed by some clear tape, which had long rotted away.  There were no screws holding the case together.  I would later surmise, when I put screws in, that it had probably never been screwed shut, like, ever.

After a quick visual inspection of the board, I decided that it was probably safe to attempt to turn it on.  I used a nearby C64c power supply and attempted to give it life.  Upon flipping the switch, the computer perfectly synced with my NTSC monitor, which wasn't surprising given its origin, but still gave me some relief.  The familiar 264 series color screen popped up, and BASIC appeared to initialize by placing its familiar message at the top of the screen.  Under that message was the READY prompt, but under that was a crash message and an immediate drop into the computers built-in machine language monitor.

I filed this information away, powered it down, and planned a more detailed inspection of the board itself.  While that was going on, the space bar and the four directional arrow key heads would be carefully removed for retr0brighting, since they showed signs of yellowing.

During my first board inspection, I noticed that the keyboard cable was not even connected to the board (the owner had been considerate enough to warn me about this), and several of the keyboard cable pens were bent up.  A light application of Superglue under the folded pins corrected this problem, so I turned my attention to the board itself:

Several interesting things popped out at me:

• Every single IC is socketed! Repair will be simple when the time comes!
• The TED chip (located upper-middle, in that square casing) had no protection from overheating, which, in the Plus/4, was provided by a metal contact that dips down inside the lid which covers that casing area, along with a dab of heat sink compound.  
• The RF modulator, silver box in the upper-left, has "No 20" written on it.  Perhaps this was 264 board number 20?  Prototypes rarely had serial numbers, so I guess they needed to keep track somehow.
• The KERNAL and BASIC ROM chips (bottom left, just to the left of those empty sockets) are, of course, only dated EPROMs.  They were still a work-in-progress at the time this unit was delivered.
• The board assembly number is the same used in the Plus/4. No difference there at all.  And the empty sockets in the middle are already there, ready to receive the built-in software ROMs that given the Plus/4 its name.
• The PLA chip (marked 1CCD), is also some sort of pre-production chip.

My next step would be to archive the KERNAL and BASIC ROM chips, which would also reveal which of the two, if either, caused the crash I observed during my initial test.

During removal of the BASIC ROM, I immediately saw a problem: pin 1 on the chip was bent up, and was either not making contact with the socket, or was making intermittent contact.  After removing the chip, I carefully bent it back into shape.

For reading in ROMs, I still use a Promenade C1 EPROM programmer on my Commodore 64c.  For software, I either use PROMOS 2.0 shell, or PROMSHELL 2.0, depending on the type of ROM that needs reading.  I had no trouble reading either chip, and saved them onto a 1581 3.5" floppy, for transfer to my PC and later uploading.

The ROMs were marked 1/19, which I surmised to refer to the snapshot date of the software on them, probably January 19th, 1984, which would be 3-4 months before release.

Comparing them with the ROMs from Jim Brain's Commodore 264 (marked 2/3) revealed that there are differences, though determining what they are and their significance will have to wait.

So, with my internal inspection and archiving done, and all the photographs taken, I carefully re-inserted the newly fixed keyboard cable, and re-connected the case.  Since it had previously been held together with tape, I scavenged some case screws from an old Plus/4 that was missing it's 7501 CPU altogether and used those to button it up properly.  The screws went in snugly, making me think that the case had never been screwed shut in its entire life.

Another power-on test showed that the bent pin on the BASIC ROM was, in the end, the only problem.  The computer was fully operational.  Further tinkering will wait until the differences in the BASIC and KERNAL ROMs are identified, so that I know what there is to tinker with.

Until then, I can bask in the satisfaction of having completed the 264 Series in my Commodore collection, and look forward to whatever secrets it may reveal in the future.

How to bathe a PET

This last weekend was crazy busy, with almost no time to do much of anything fun.

However, I was able to squeeze in a task that's been on my whiteboard for way too long -- giving my beautiful PET 2001-8 a good cleaning and retr0brighting (de-yellowing) the datasette keys. As you can see in the picture below, those keys really need it.

Once it was on the bench I opened it up, compress-air cleaned the board and case a little, cleaned the edge connector contacts with an eraser (yes, I keep unsharped pencils around JUST for this purpose), and removed the datasette for the final step.

The datasette in the original PET computers is a strange beast.  It's obviously some sort of OEM tape player that has been hacked in order to attach the custom cable.

Retr0bright is the greatest discovery of the 21st century for owners of older plastic electronics parts.  Far from being a simple "bleaching", Retr0bright actually de-yellows plastic surfaces, returning them to white if they were white, cream-colored if they were cream-colored, grey if they were grey, etc.

Although the theory behind it is a bit convoluted, and the recipes numerous and hotly disputed, I've found that Salon Care 40 Creme does everything those complex recipes do, and comes ready off the shelf.  All I do is paint the cream onto the yellowed surface, wrap the surface in cellophane to prevent drying, and put it under a pair of powerful UV-A-B lamps.  And while I'm not entirely certain even the lamps are necessary, I've never had the occasion to test it.

After the retr0brighting for 3-4 days, I reassemble the computer and smile.  Back to the PETting Zoo with you -- we'll play later.

Re-Introducing the C64 'Aldi'

When I first heard about the "Commodore 64 'Aldi'", it did not strike me as anything of particular interest to a collector.  The distinguishing feature of the computer, judging by the name at least, was that it was sold in a chain of stores in Europe.  Big Deal! Does that mean there's something interesting about having a Commodore 64 'Sears' or a Commodore 64 'Toys R Us?'.  Of course not.

And then, while perusing the sites of some European collectors, I discovered that the 'Aldi' always had a White 64C keyboard in its brown Breadbox case, and that it actually contained the same "short board" found in the 64C.  Now that's something a C64 'Sears' can't claim! So, while the notion of getting another PAL C64 did not overwhelm me with excitement (they are tricky for me to use here in the 60hz NTSC-dominated U.S.), I got interested enough to get one.  After chatting with the accommodating Stefan Walgenbach in Germany, we reached an agreement, traded some things, and I ended up with a a brown Breadbox PAL C64 with a short-board, in the original box!

Now, a decade goes by, and I end up in a discussion with a fellow on AmiBay about the 'Aldi' computer he has for sale.  "It's Genuine!" he says, because "it's not one of those West German made look-alike C64s that came later!"  So, there's a Look-Alike 'Aldi'?  And how the heck would he even KNOW?  I mean, No One keeps their store receipts when they buy these things, so who could have confirmed that THIS white-keyboard-brown-breadbox-short-board-64 came from the Aldi stores, but that one did not?

This led me to exchanging an email or two with a fellow in Germany named Stefan Vogt, who has apparently made a hobby out of gathering information about the Aldi, and through his Extensive Research, learned more than a few fascinating things about this computer that made it indeed worthy of the attentions of a Commodore enthusiast, especially if the 64 is your thing.

The punch line is  (paraphrasing Stefan's email here):

• The 'Aldi' C64 was manufactured in the U.S. for the German market in the Summer of 1987, probably because the short-boards were brand new, and assembly was being kept closer to the engineers until it had been proven...
• It was the First Commodore computer to feature the cost-reduced C64 short-board.  It was before the C64G, it was before the C64-II, it was before the C64C.
• It had the earliest revision of that motherboard (250469 rev.3), one of the short boards to have a separate color-ram chip.
• Contrary to early rumors, some of which came from the German 64er Magazine which reviewed these new C64 motherboards from Commodore, the Aldi *does* have 9 volts on the user-port.
• And contrary to later rumors, the Aldi Look-Alikes made in West Germany are not true Aldis, having later-revision motherboards.

So, needless to say, I took the guy on AmiBay up on his offer.

Now, given all the information I'd been absorbing, I immediately endeavored to inspect and confirm some of the information I received.  Aside from the obvious 'Aldi' appearance, the first thing I confirmed is that, Yes, this German PAL computer was actually made in the U.S.   Also, something I'd never noticed before is that even the rubber "feet" of the computer are 64C white instead of the normal breadbox Black.

Next was to pop open the case and inspect the motherboard.  While attempting this, I confirmed that no previous owner had ever opened this case.  None.  Ever.  How do I know?  Because it took me a dadgum hour to get the case off after removing the screws -- the plastic latches were so tightly gripping the inside of the case that I had to carefully jimmy them lose with a tiny screwdriver to avoid damaging the case.

But once it was open, sure enough, I found it had the earliest known revision of the short-board c64 motherboard.

Further inspection of the motherboard shows that, indeed, there is a 2114 RAM chip present on this board that is  not found on the later Rev B motherboards.  You can see it below, it's between the VIC-II 8569 (dead center), and the larger PLA/integrated chip to the left of it.  As that chip is also seen in Rev.4 and Rev.A motherboards, I guess it wasn't integrated until the (final?) Rev.B boards.

Of course I also made sure the computer itself worked OK.  My PAL->NTSC converter does not exactly give a clean picture, but it was enough to see that the computer was working.  I also retr0brighted the keyboard, though it didn't need much.

In conclusion, I've definitely learned some interesting things about the later history of the Commodore 64.  Stefan makes the case for the extreme rarity of the 'Aldi' C64, and he may be right.  Although white-keyboard-brown-breadbox-short-board C64s seem at best uncommon, and Rev.3 short board motherboards have been found in all kinds of later C64 cases, including the C64-II/C64C., perhaps it's the strange combination of these things, reflecting an important transitional period in C64 manufacturing, that makes the 'Aldi' a special computer to make so much fuss about.