Friday, 22 August 2014

Commodore PET Repair Part 4 - Video Circuits

This is an old post, preserved for reference.
The products and services mentioned within are no longer available.

This is the fourth part of the restoration of a Commodore Pet 'Fat 40' 4032. You might want to start at Part 1. The story so far: empty 4032 case being filled with parts from a donor rusty 8032-SK. The main board has been cleaned up and using the ROM/RAM replacement board, the Pet has booted, but there is garbage on the screen.
There is a lot you can tell from the garbage on the screen. It's very useful to be able to trace through the schematics at this point, and again I refer the to invaluable resource at zimmers.net. The pet video uses separate screen RAM, on the 4032, this is 2 x 2114 SRAM, giving 1K bytes. This can be read or written starting at address 0x8000, accessed via two 74LS244 buffers. That is 1024 characters, enough for 25 40 character lines with one byte per character. So no pixel graphics here, just a single character per position. The address lines are multiplexed with the outputs of the 6545 display controller, and it accesses the screen on the clock half cycles when the CPU doesn't. The data is latched into a 74LS373 gate and used to set the address of the character ROM, it's outputs being fed to a 74166 shift register to generate the actual pixel data. This is similar to the way the screen is generated in the ATMega328P video generator I previously built to drive the Pet monitor. This is running as fast as it can on the 16MHz clock, and isn't fast enough to achieve an 80 column display. To this, they added another set of RAM and buffers and latches and set them to do alternate characters, so whilst the odd RAM is setup for one character, the even RAM is getting ready for the next.
Here the screen shows 80 x 25 characters being generated, just not changing. But the Pet is working behind this, hold down a key until it gets to the end of the line and it beeps. If I had a suitable disk drive setup, it should respond to disk commands. However, nothing seems to change the screen. I found it useful to change to the test ROM, this alternates between a character set and memory test results every couple of seconds. This is useful as it should be writing to the screen RAM every couple of sections. However, when I checked, there didn't appear to be any write signals going to the screen RAM chips. That would explain why it wasn't changing.
The write signal is generated by UC3 a 74LS138 3-8 line decoder. This is a bit odd as one of the inputs is tied high, so it is only working as a 2-4 line decoder.
Also strange is one of the outputs is tied high? Pin 13 is definitely an output, so why is it tied high? I took the '138 out to check and replaced it and I now started to get write pulses to the video RAM. But still no change to the display? Probing further, it looks like the main buffered data isn't changing, and I traced that back to a 74LS00 gate, UE11, which is meant to invert the read / write line to enable the two data bus buffers UB9 and UB10. The output seemed to be stuck high, so I removed that. It's nice to get confirmation when you remove a chip like this, I use the Minipro programmer which has a test function for logic circuits.
Here you can see the 74LS00 does indeed have one failed gate. With that replaced, there was a change in the garbage on the screen.
It is now changing, but it's still mainly garbage, but at least it's different garbage. This should be showing 'gggggg' for the first half of the screen. The second half is expected to be full or garbage as the memtest is designed for 40 character monitors. It then alternates to a character set, so should be 'abcdefg' etc.
So there are two different problems here. Firstly, it seems to be composed of 16 characters ok, 16 characters garbage, 16 ok etc. That looks to be due to addressing, tracing out showed a break in the buffered address line BA4.
Fixing that removed the 16 on / 16 off problem, and I got the screen have full of 'ogogog' this time. Going back to the 80n50 Pet ROM, and we have a boot screen, and the keyboard is responding. Although every other character is wrong. It should say
### commodore basic 4.0 ###
31743 bytes free
ready.
but it is showing
Checking the PETSCII table, the 'c' in commodore would be 0x43, but it's actually 'k' which is 0x4b. Space should be 0x20, but it's showing 0x28, '('. However, some were right, the 'm' was 0x4d as it should be. Checking the other characters, it seems that bit 3 was stuck on, and due to the Pet's odd/even switching this meant it was the even half. That rules out half the chips and I tracked it back to the 74LS244 buffer UB3. Replacing that, I got a proper display at last.
A few keys weren't working (the keyboard needs cleaning), but there were sufficient to test it in the traditional way.
I still need to adjust the screen, but I'll wait until it's back in it's case. Now the display side is working, lets see if we can get rid of the ROM/RAM board, and fix the ROM and the RAM....

Thursday, 21 August 2014

Commodore PET Repair Part 3 - Power, Reset, Clock

This is an old post, preserved for reference.
The products and services mentioned within are no longer available.

This is the third part of the restoration of a Commodore Pet 'Fat 40' 4032. You might want to start at Part 1. The story so far: empty 4032 case being filled with parts from a donor rusty 8032-SK. The main board cleaned up quite well, there were a number of chips corroded, which needed replacing. Three of the 40 pin chips and three of the 24 pin ROMs were socketed, and the sockets all looked a bit suspicious. In the end, I removed and socketed all the 40 pin chips and the 24 pin ROMs.
I could then try the newly restored power supply. With those chips all removed, and the monitor disconnected, I tried the power. All the voltages seemed OK, so I powered off again. That's the first point checked off, Power. Next to check is reset. On the Pet (and most of Commodore's computers), the reset pulse is cleanly generated by a 555 timer. I checked that and it seemed to be sending out a clean pulse. So far so good, next the clock.
The 8032 board has a 16MHz clock, divided down to 1MHz for the processor. Or at least it should have. This one didn't. It appeared one of the legs of the crystal had corroded, so I replaced it. I used a low profile crystal as I had one to hand, and I wasn't keen on the way the old one rested on a couple of resistors. I may change it to a larger one to be more authentic, maybe not. With that replaced, the clock was coming through properly at 16MHz. So that's all the main requirements to keep the CPU happy, clean power, clean reset and clean clock. Time to install some chips.
There are 5 40 pin chips:
  • A 6520 PIA for the GPIB/IEE488 interface
  • A 6522 VIA for the user port and cassette interfaces
  • A 6502 CPU
  • A 6545 CRTC display controller
  • A 6520 PIA for the keyboard
Checking over those, the 6545 wasn't working, and one of the 6520s was too badly corroded. The IEE488 PIA is not required unless using that port, so I can do without that for the moment. I replaced the 6545 with a known working 6845 which should also work here. Time to power on. No chirp from the sounder. I tried connecting the monitor, but all I got was a blank screen (or rather a bright green dot in the centre), so I turned that of quickly. Normally it gets tricky at this point. Something is stopping the CPU executing the ROM code and setting up the CRTC to drive the screen and the I/O chips to make the chirp. This could be any number of things, bad ROM, bad RAM, bad glue logic, bad CPU, wind in the wrong direction, wrong coloured shirt etc.
Now was the time for the 6502 ROM/RAM replacement boards, the Pet was the main reason for I built those. It is a great tool to have at this point, as it can bypass the onboard ROM, RAM and glue logic and at least get the CPU up and running. Credit again to the original designer of the ROM/RAM board. His site has GAL logic terms for 2001 Pets, VIC20's and disk drives. So I had to write the terms for the 8032. It turned out not to be too different to the 2001, just a larger ROM area for the BASIC 4, and I changed the RAM options to 16K or 32K.
I also needed to compile an EPROM image of all the Pet 4032 ROMs. I got the images I needed from the invaluable resource at zimmers.net. The 4032 and the 8032-SK would have had almost the same set of ROMS:
  • 901465-22 - 4K BASIC 4 Kernal
  • 901474-04 - 2K Editor
  • 901465-21 - 4K BASIC 4 ROM
  • 901465-20 - 4K BASIC 4 ROM
  • 901465-23 - 4K BASIC 4 ROM
The only difference is in the editor ROM. The 4032 has a 40 column display and 32K RAM. It has the same 12" monitor as the 8032 (80 Column, 32K), hence the 'Fat 40' name. The board I have from the 8032-SK is one of the later 'universal' board which can be configured as 40 or 80 column. Currently it is 80 column, and I plan to leave it that way for the moment. I'd like to the final machine to be a 4032, so I will be converting it to 40 column, possibly switchable to 80 column mode. The editor ROM is changed depending on screen size and keyboard type.  There are also 50Hz and 60Hz versions of the editors, which confuses things further.
The Pet came with two keyboard types, the 4032 has the 'Normal' or 'Graphics' keyboard, which rather oddly has no numbers above the letters, only symbols. The numbers have to be typed on the numeric keypad.
The other type, as would have been fitted to the 8032-SK is the 'Business' keyboard. This has the numbers, but no graphic symbols. Both are in need of a good clean! Commodore appear to have generated three of the possible combinations, 40 N, 40 B and 80 B, but no 80 N. All of the later computers had business keyboards. Some kind person at the Vintage Computer Forum has merged those to create the missing 80 N. That is what I have used for the moment, as the board is 80 column, but the keyboard is Normal.. Since there is space for 4 sets of ROMs, I had one with 80 N 50, one 80 B 50 and one 40 N 50. I also added an 80 column memory test ROM image (I'll insert the link when I find it).
I plugged this into the board, with it set to replace both ROM and RAM, and switched on. I was relieved to hear the power on chirp, and connecting the monitor, there was something on the screen.
Ah, the old familiar problem with Pets, garbage on the screen. But still this was progress. The test setup is ready to fix the rest of the pet.
I think the first task is to fix the video circuits.....

UPDATE:

The new V2.0 6502 ROM/RAM boards are available now.

UPDATE 2:

The V3.1 ROM/RAM boards are now available.

2022 Update: A redesigned small version of the PET ROM/RAM boards are still available from  TFW8b.com 

Thursday, 14 August 2014

Commodore PET Repair Part 2 - Power Supply

This is an old post, preserved for reference.
The products and services mentioned within are no longer available.

This is the second part of the Commodore Pet repair, see Part 1, Mainboard cleanup. This covers the power supply. It's a fairly chunky and fairly simple linear power supply. This one originates from the rusty 8032-SK.
Electrically, it's the same as the 4032 would have had, but it's mounted differently.
This mounting plate was flat and separate from the rear section. It's mainly the mounting that is rusty, so that can be removed. I did look at bolting the transformer to the case, but I know the 4032 would have had a mounting place which held the transformer and the rear panel.
Along with the rusty 8032-SK, I also got an equally rusty 8250, and that did have a power supply mounting plate, and it appears to be the same as the 4032 would have had, the smaller 8250 transformer is fitted on extra little brackets.
This 8250 was also in bad shape, but will be restored (much, much later). For the moment, I borrowed this plate for the 4032.
There were actually mounting holes below for the transformer in the 8250 case, so I bolted it back onto those, without the bracket, and will be able to use the 8032-SK rear panel to wire it back up.
That left me with a suitable bracket, and test fitting that into the 4032, it was all looking good. But there was a bit of surface rust, on the transformer, so I cleaned it up and sprayed it black.
That turned out well, so I cleaned and sprayed the bracket as well.
The back was already black, so it tied in well.
All ready to put back together, just needed some spacers. The only ones I could get where white, so I sprayed those black as well.
The final part was the wiring, again, mainly from the 8032-SK. The exception being the monitor connector.
The power and the signal to the monitor are combined in a single lead, one end attached to the power supply, the other to the motherboard. The 8032-SK had an inline connector so the monitor could be removed, the 4032 didn't. I did have the original cable from the 4032, so I used that.
The original 1982 capacitor from the 8032-SK still seems fine, low ESR and reading higher than marked capacitance (it would have had -20%/+80%  tolerance).
That's turned out quite nicely, considering it is composed of parts from a rusty 8032-SK, an 8250, and the original 4032. Next was onto testing the mainboard...

Commodore PET Repair Part 1 - Main board cleanup

This is an old post, preserved for reference.
The products and services mentioned within are no longer available.

This is the start of either a very long article, or more likely, a series of articles, covering the restoration of a Commodore Pet. Last year, I dug out the case from a Commodore Pet 4032, with the intention of finding something interesting to put in it, since I didn't have the original main board or power supply. I did look at various options, and managed to drive the keyboard and screen from a microcontroller, and for a while, it ran with a Z80 CP/M system inside.
However, the real goal was always to get it back to being a Commodore Pet. That is going to be a little tricky, as it is currently an empty case. So in an effort to get missing parts such as power supply, motherboard etc. I took a punt on a rusty broken Commodore Pet 8032-SK on ebay.
This was missing the keyboard, and the metalwork was rusty. But what I needed was the power supply and the mainboard, and hopefully I'd be able to fix that. The 8032-SK was a recased version of the original 8032, SK standing for Separate Keyboard, the keyboard being a massive external unit with a big curly cord. In this case, I don't have that, so it's NK, No Keyboard.
As a bonus, inside I found a 64K memory expansion, so this had been an 8096-SK. I'll leave that for the moment as it just complicates things. It needs extra software to work, and that comes on disk. I don't have the disks. I also don't have a suitable disk drive (although I have an 8250 in a similar state). Also, it's full of 4116's, and I'd be surprised if they all worked.
Oh, and one of them is cracked, exposing the silicon die inside, I bet that one doesn't work. Let's rule out the memory card for the moment, and concentrate on the main board.
When removed from the case, the board was intact, but in need of a good clean.
Some of the chips had corroded badly, although most cleaned up ok.
There had been a previous repair, replacing two of the 4116 DRAMs with two unmatched chips and strange red DIL sockets, the contacts of which had corroded badly inside. There were also some corrosion to the other 4116s. I removed and socketed the ROMs and the 40 pin ICs, so they could be cleaned and tested. The RAM was a bit more corroded, and there was damage to some of the tracks. I removed a couple of the RAM chips which were damaged and replaced the red sockets.
Next I moved onto the power supply.


Monday, 11 August 2014

Raspberry Pi Real Time Clock Upgrade

This is an old post, preserved for reference.
The products and services mentioned within are no longer available.

Just a quick update following my Raspberry Pi B+ ZX Spectrum USB Keyboard Case Mod, there was almost a square inch of space inside the unit. This would not do, so I have been asked to add a Real Time Clock module. The RTC stores the date and time and is backed up by a battery when the unit is not powered up. Most larger computers have one of these built in, but there wasn't space on the Raspberry Pi. The DS1307 is the standard I2C RTC chip to use for this sort of thing. I use these in my LED clocks.
Here I've used an Adafruit RTC module as it was relatively small, although I've still had to fit horizontal headers to it. It's not specifically designed for the Pi, but is easily adpated. I've removed the I2C pullup resistors on the RTC as the Pi has it's own, and they pull up to 3V3, where as the DS1307 runs from 5V.
The wiring is straightforward, but due to the limited height, I've also had to bend the GPIO pins sideways to make the connections, the I2C SDA and SCL on the left and 0V and 5V on the right. It all fits snugly in the only remaining space inside the Spectrum.
I've overlaid the image of the parts in the top of the case, so you can see the 3D spacial puzzle involved in arranging the components inside.
Setting it up was fairly straight forward, I followed this guide on the adafruit site. This is what they refer to as the 'v2' Raspberry Pi, the I2C on the GPIO is bus 1. Also remember to read the text as some of the screenshots are different.

Thursday, 31 July 2014

Dymo Label Maker PnP Review

This is an old post, preserved for reference.
The products and services mentioned within are no longer available.

I've been having a well overdue tidy up of the workshop. As part of that, I've bought couple of another cabinets of plastic storage drawers. After the mammoth task of sorting things into the drawers come the problem of labelling the drawers. In the past I've tried different things, writing on paper labels, printing on labels, printing and then cutting out little bits of paper. Time for something different.
I have an old Dymo labeller which is the traditional emboss letters onto thick plastic tape type thing. I use these for serial numbers on the USB keyboards, as they are seem to fit. I think they still sell these, now called '3D' label printers.
However, they aren't really ideal for this task as there are only upper case, no " (for inches), and a limited number of characters. So I looked at a new printer, and found this one, also from Dymo.
This is the Label Maker Plug'n'Play. The pack is actually sold as two packs of D1 tape with a free printer, and was less than £20 on Amazon. It's a USB label printer, which is advertised as plug and play, no software to install, no batteries etc. Well that's not entirely true, there is software to install, and there is an internal battery, but you shouldn't have to worry about them. The battery is Li-ion type which presumably charges up whilst it is plugged in and provides extra power for the mechanics of the printer.
The tapes supplied were 9mm yellow and 12mm white. I also needed 9mm white, so I bought one of those as well (£7.50 for 7m, not too bad).
The unit is small (150mm x 150mm x 50mm) and the only connector is a standard USB socket. There is a power button on the top with a blue LED, and a button to cut the label off (as that doesn't happen automatically). Slightly oddly, the labels come out upside down.
The software appears as a USB drive when you plug it into the PC, and can run from there, it would autorun if you have that enabled. I downloaded a later version from their website. It installs one of those annoying things which runs in the taskbar, taking a small but unnecessary amount of screen space and memory. Easy to disable though. It's also fairly easy to use, designed to appear like Microsoft Word (the proper versions, not 2013/365 style). The resizing of text areas seems a little counter intuitive, but I managed to generate all the labels I needed.
A nice feature is that the width can be fixed, so I found that 61mm was ideal for these drawers as it slid into the slot on the front of the drawers without actually needing to remove the backing and stick them on.
I got all of these drawers labelled out of the one roll, and there is still a fair bit left.
Now time to get some work done and inevitably mess everything up again.

2022 Update: I've now had three or four of these, the batteries within wear out and the replacements are more expensive that the printers. I've also had one were one of the pixels on the print element went bad, but luckily I have several spare units.