Saturday, 27 June 2015

Commodore 8032 Mainboard Repair

Another 8032 board in for repair. I seem to be doing quite a few of those at the moment. They never fail to disappoint in the range of weird ailments. It's the traditional black screen, no beep, a generally dead computer. The owner has previously attempted to get this running, replacing four of the ROMs with 2532 EPROMs, and replacing the four 2114 video RAM chips.
There were a few suspicious looking solder joints, but these boards can be difficult to work on, so that is understandable. Usual first tests, power, reset, clock all came out OK, although the reset pulse was a bit slow, three or four seconds, it's normally a second or so. So time for the ROM/RAM replacement board.
With the ROM/RAM board in place and set to replace the onboard ROM and RAM the system booted. Checking individually, there was a fault in the RAM, and with the RAM replaced, the onboard ROM would beep, but not show anything on the screen. This usually means the kernal is getting somewhere, but not far enough along to start BASIC. The other issue was the screen.
Quite a nice pattern, but that's not much use. Looking closer, it appeared the text was being displayed, but the right hand half of each character was a solid block. You can just make out the 31743 bytes free and ready prompts.
The 80 column video circuit on the Pet is quite complex, and there is a lot of odd / even split, and it uses pairs of 2114 SRAM which are 4 bits wide each to give the 8 bit character. It's very tempting to start looking at all the odd and even bytes parts, and the buffers that only affect half of the byte. The section outlined in red is the video circuitry, and most parts of it operate on only odd or only even, or on half bytes.
But you have to stop and think about the Pet. It has no pixel graphics capability. All of the above things are working at the character level, so when they go wrong, you don't get half a 'b' in 'bytes', you get half of the bits that make up the character code for 'b' (0x42), so it won't be a 'b' at all, but 0xF2 or 0x4F if the bits are stuck on, 0x02 and 0x40 if they are off. That isn't what is happening, it's actually in the pixel that make up the 'b', and that narrows it down to only two candidates, the two chips on the left of that red box, the character ROM and the 74166 shift register.
Testing that was easy. I removed the character ROM, and I still saw half blocks on the screen, so the culprit was the shift register. This takes a line of the bitmap of the character from the character ROM and sends it out to the screen a pixel at a time. Replacing that and the display was restored.
Well, I say restored, there were a few random characters, usually @ symbols on the screen. This seemed to get worse when the screen was scrolled. This is a simple test program that is meant to alternate \ and / characters to make up a random maze, but the more it scrolls, the more @ symbols appear.
I went to a simpler test program:
10 PRINT ".";
20 GOTO 10
This produced a screen half full of dots as expected by also a random collection of letter n's.
Here '.' is 0x2E in PETSCII and n is 0x4E, and on the boot screen, @ is 0x00  and it should be space (0x20). It looked like one particular bit was wrong in the value being fed to the character ROM, so it could have been the input buffers or output latches or the 138 that does the timing not pulsing the write for long enough. But, it did look like it was the video RAM. It could have just been one bad bit on one RAM chip, but there were some n's that were on the alternate characters (i.e. .n.n.n.n would mean just the odd or the even, ..nn.. would mean both). I replaced all the video SRAM with good chips, and it was fine. The 2114 that had been replaced passed memory tests, but I think were just a bit slow to cope with rapid screen fills. With the video RAM replaced, and the screen was back to how it should be.
Now I could get on with the rest of the testing. Memory tests showed one faulty 4116, so I replaced that with a similar spare. This time I soldered it in place, as these MOSTEK ones all seem to have short legs and it didn't sit well in a socket. You'd hardly know it was there.
The ROMs were still not able to boot. I tried a full set of known working 2532 EPROMs, and got the same result, so I tested for continuity and found a few bad connections. I decided the best approach was to removed and replace all the ROM sockets.
The tracks underneath were in good condition, and all continuity tests passed with no sockets, so I installed a new set of sockets and tested with a set of known working ROMs. That worked, so I want back to the set of 2532's that came with the board, and they all worked as well. With those labelled up, it was back in business, running on it's own ROM and RAM.
Further testing showed no response from the IEEE-488 port with one of my pet microSD disk drives plugged in, and no response from either tape. Oh, and it is still slow to reset. Tape 1 came back after cleaning the connector, I've found the best way with those is to re-tin them with fresh solder, and then wick most of it back off with solder braid.
I cleaned all of the connectors and but still no tape 2 or IEEE-488. The IEEE-488 connector is gold plated, so I didn't want to tin that, I checked for continuity, and all the connections were going through.
I used the debug output from the pet microSD to check what was coming through, and it was getting a request, but the handshaking wasn't working. I could see the name of the file I had tried to load, so the data lines looked OK. That rules out one 6520 and two of the MC3446's. The one chip that does handshaking and tape 2 is the 6522. I removed and socked that and installed a new 6522 and that brought back the IEEE-488 port and tape two.
So that's it pretty much sorted, other than the slow reset. I had noticed some of the capacitors were in a poor state, including the one on the 555 that generates the reset signal. I don't normally replace the capacitors on Pet boards unless they appear damaged, or are not preforming properly. In this case it was both, the covering was shrunk and split on several of them, that usually means they have got rather hot at some point. I went though and replaced all the electrolytics, bar the large one, as that seemed OK and is difficult to get one with the right lead spacing.
Testing the caps, some were still OK, but several were out of tolerance and had quite a high ESR.
With those replaced, the reset was back to how it should be, and all was working. Well.
A long soak test and lots of testing and it's ready to go back.
The final list of faults was as follows:
  • RAM - 1x4116 DRAM replaced
  • ROM - all ROM sockets replaced, all ROM and EPROMs tested OK
  • Video half character blocks - 74LS166 replaced
  • Video random characters - 4x2114 and sockets replaced, 
  • Tape - edge connectors cleaned
  • IEEE-488 - 6522 socketed and replaced
  • Slow boot - recapped

Tuesday, 23 June 2015

Commodore Pet USB Keyboard

I've been looking around for a Commodore Pet 2001 to add to my collection, as I'd like to be able to test the pet microSDs and ROM/RAM replacement boards on a range of machines. Full machines seem to go for quite a bit these days, but I recently won a 2001 mainboard on ebay. In the listing, the seller mentioned they had other bits from the machine. It turns out he was in the process of converting the 2001 into something else. I mentioned my range of USB keyboards, and asked if it would be useful for him to be able to use the Pet keyboard as a USB keyboard. A deal was arranged, I ended up with all the other bits removed from the 2001 (a 2001-32 N), and he got a USB keyboard controller board.
This is another of the USB keyboard conversions that I wasn't planning to do. It is a Commodore Pet USB keyboard, that is, a Commodore Pet keyboard that can be used as a USB keyboard on a modern PC. I'd rather see Pets restored as Pets, rather than turned into media players. But this one was already in progress, and the innards of the 2001 will live on. Well, I hope they will, I'm determined to get it running. but it's going to be quite a job, the board is in rather poor condition,
Over the years of making these USB keyboards, I've produced various shapes and sizes of controller boards, including one specifically for Commodore keyboards like the C64 and the VIC20.
Unfortunately, although the Pet uses the same connector, it is a 10x8 matrix, rather than 8x8+1 as in the C64, so the microcontroller on that board was one I/O pin short of being able to do that.
Instead, I went for one of my generic USB keyboard controllers with a larger microcontroller and a few more I/O pins.The mapping was fairly simple as most of the keys only have a single function.
This is the Normal / Graphics keyboard (see my previous post on editor ROMs for more info on Pet keyboard types).
Even the top row of keys that are usually numbers and symbols are only symbols on this keyboard. The numbers are only on the numeric keypad.
I also built a version which works with the business keyboard layout:
These boards have turned out to be quite useful for testing these keyboards when refurbishing them (see a previous post on cleaning Pet keyboards).
I can supply these as a kit, which contains USB keyboard controller, mounting pillars and a USB lead.

Select model:
Price including postage:

Sunday, 21 June 2015

Commodore 16 USB keyboard with Raspberry Pi

This is one that has been missing from the range of USB keyboards and USB keyboards with Raspberry Pi that I have in my Etsy store. There are various combinations of Commodore keyboards, with and without integrated Raspberry Pi computers. I already have a Commodore 16 USB keyboard listed, but I hadn't listed a Commodore 16 with integrated Pi.
I've been asked to build one, so here it. As with all of the keyboards, I start by refurbishing the keyboard, stripping it down to the chassis, cleaning and reassembling.
The frame is the same as the Commodore 64 and VIC 20, and almost the same as the Pet business keyboard, and the key stems, springs and keycaps are interchangeable with all but the early versions.
The only change is the colour and legends on the keycaps and the layout of contacts on the PCB.
Once all the keys are reassembled, and the PCB cleaned, the PCB is screwed back into the frame. I use the USB keyboard controllers to test the keys, to make sure each key is responding. Sometimes the key stem contacts need a bit of extra cleaning, but they are fairly sturdy keyboards.
Once tested, the controller is fixed to the back of the keyboard, and the keyboard cable clipped into place.
The keyboard into the lid of the case. The power LED is plugged into the USB keyboard controller, leaving just a USB connection between the case halves.
There is an option to fit this with a mode switch to change between keyboard mappings for general use, and a mapping specifically for use with Vice Commodore 16 emulator. This uses a different controller board, and there would be a mode switch connector to the rear panel. The power LED is changed for a tricolour one, green for normal use, red for emulator use. I can also fit the USB socket externally, so the keyboard can be used as a USB keyboard, or with the Pi using a short loopback cable.
The Rapsberry Pi B+ and Pi 2 B have 4 USB ports, I remove one of the dual USB connectors and replace it was a single USB connector, and wire a lead into the pins for the second port. This connects to the USB keyboard controller, and leaves 3 ports externally accessible. (shown above on a Commodore 64 version).
Power is extended from the board to a 2,1mm DC jack. I'm not a fan if the microUSB connector for the Pi, there are that many cheap microUSB cables and chargers which are not up the job. They may be fine for charging phones, but the Pi needs a better supply. I find the ones with 2.1mm DC jacks tend to be better, so I use one of those.
HDMI is extended from the side of the Pi to the hole where the 'Video' connector originally went. Those are then covered in unecessary amounts of hot melt glue to hold them in place. The completed lower case, in the tradition of the original Commodore 16, it's half empty.
The two halves folds closed in the standard way, leaving access to LAN, 3 USB, power and HDMI out. There would also be a mode switch there if the mode switch mapping option was selected.
These are now available from my Etsy store. As with the other versions, this is available with the Raspberry Pi B+ or Raspberry Pi 2 model B with the faster processor and more RAM. These are supplied with a microSD card installed and tested running Raspian. I can set up alternate operating systems as required for dedicated media players or arcade emulators.

Wednesday, 10 June 2015

pet microSD 8032-SK internal fitting guide

Here is a bit more information on installing one of my new pet microSD Commodore Pet disk drive replacements inside a Commodore 8032-SK or 8096-SK.
The normal pet miroSD has an edge connector soldered to the board, and plugs into the rear of a 4032 or an 8032 or similar.
The 8032-SK doesn't have edge connectors on the rear, it has IEEE-488 connectors.
Inside, it is actually the same board as the normal 8032, but it is rotated 90 degrees, and had cables connecting the user and IEEE-488 ports to the rear panel.
The 8032-SK version of the pet microSD does not have the edge connector soldered on
The kit includes the board, a power cable and a riser.
Temporarily remove the rear panel cable and the riser board can be installed where it used to connect.
There is then a special slot on the riser into which the pet microSD connects. The connections on this socket have been reversed for this purpose.
The pet microSD rests above the board, supported in the socket. Make sure it is not making contact with anything below, there should be a clear gap.
Power is taken from capacitor C11, the grey one in the photo above. The polarity is marked on the board and the capacitor. The black 0V rail should be clipped onto the lead near the edge of the board, and the red 5V lead to the other end, marked + on the board. If it doubt, check with a voltmeter.
The other end of the power cable connects to the pet microSD, again with black to the edge of the board, and red marked +. Here it a closer view, with a piece of white paper behind for clarity.
The original rear panel cable can then be reattached to allow other IEEE-488 devices to be attached to the pet as normal.
The edge connector on the top of the riser board is the now the same as the original edge connector, so connect the cable in the same orientation.
From the side, you should be able to see how all this fits together.
If you would like to order an 8032-SK kit or indeed a normal pet microSD kit, contact me.