Thursday 26 May 2016

Vintage Computers - an ebay buyers guide

Ebay is a good source of old computers, and I buy quite a lot from there. I usually go for the unwanted, unloved, un-bid-on items that need a bit of TLC. Over the years you get to see patterns in what is listed and what actually arrives.

I was pointed at a listing last week which stated:
Does not power on - item was working then one day it just stopped.
Everything was probably working one day, the day before it broke for example. It doesn't change the fact that it is currently broken. It was probably working before they tried to power it from the wrong mains adapter. Probably working before they tried a composite video mod with a plumbers soldering iron. Probably working before it got put into the washing machine. Probably working before the all night Donkey Kong session with the ventilation holes covered. Probably working before it had beer spilled on it. Probably working before they opened it up to see how it worked and damaged the membrane tails etc.

Elvis was fine, then one day he just stopped working. No, Elvis is dead. Sorry to break the bad news, but you should have heard by now.

For reference, here is a translation of what many of the terms used on ebay listings actually mean:

  • "Tested and working"  - the light came on. 
  • "Untested"  - the light didn't come on.
  • "Probably a simple fix"  - probably won't be a simple fix
  • "Could be the fuse"  - I tried the fuse and it wasn't that
  • "Working when put away"  - Now broken
  • "Can't test as I don't have the power supply"  - Tested and broken (the power supply will be listed next week)
  • "Sold as seen" - Broken, probably with bits missing inside or damage carefully cropped out of the photos.
  • "Will be well packed"  - Will be wrapped in a black bin liner and thrown at the cheapest courier service.
  • "Rare" - Common as muck
  • "UK Seller" - Chinese Seller

You see the pattern developing there? Caveat Emptor. I hate to go all Fox Mulder, but Trust No One. I buy a lot of stuff from ebay (this is me now, not Fox), and usually approach it with the expectation that it is going to be bad.
Certainly be wary of power supplies, I've had several Atari 2600's both ebay purchases, and ones sent in for repair (that were probably ebay purchases) which came with the wrong mains adapters, and worked fine with the right power supply. Mains plugs are definitely worth checking. They almost always have 13A fuses fitted, the screws inside loose and sometimes the odd wire reversed.
I've also had Spectrums, and recently an Oric-1, where the internal regulators had been bypassed. Always worth a look inside, you never known what you are going to find, or not find in the case of this Spectrum +2 which was looking a little short on the RAM front. This was listed as 'was working when put away'...
To balance those out, sometimes you do get extras. I found a nice selection of springs inside a Commodore PET 8032-SK. Very kind of the seller to include them, but not the best for the address bus drivers.
I had a guitar amp in for repair that I think had come from ebay. The lights were on, but only a loud buzzing sound. As well as a lifetime supply of cat hair, inside I found a bonus free guitar case key wedged between a MOSFET and some wire links. Worked a lot better with that removed.
On the plus side, it's always a bit disappointing when you buy something and it is in perfect condition and works first time. It is much more interesting to fix things, so I prefer the broken ones, and I am rarely disappointed.

Sunday 22 May 2016

Oric-1 Repair Part 1 - Reset circuitry

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

This is the first part of an Oric-1 repair. I'll describe it's initial condition again, and cut down that section in the previous article. The repair starts after that.
This Oric-1 was 'untested' in ebay terminology - i.e. broken. I never plug anything in before checking it out. This is a case in point as to why that is a good policy.
Inside there is a 3 terminal regulator missing. Not the usual 7805 I was expecting, but for some reason the Oric-1 uses a 7905 regulator. The 7905 is designed to take -9V DC and generate -5V. Here it's wired slightly oddly to take +9V and generate +5V. Why they didn't use the normal version I don't know.
This arrangement means that in normal operation the 0V rail inside the Oric is about 4V above the 0V rail of the power supply. If you happened to have a power supply where 0V was tied to mains earth (which is not unreasonable), and you plugged it into a TV or monitor with it's ground referenced to mains earth (which is quite possible), it would short out the 4V differential and the board would be running at 9V?
Anyway, it turns out a previous owner had bypassed the 7905 making it a 5V DC input  That would make more sense, as long as it is clearly labelled, which it wasn't. There are also a few other suspicious mods, various extra capacitors scattered around the board, and some strange resistor and capacitor mod to the power feed to the modulator.
The Oric-1 originally had two 8K ROM chips. Later models had a single 16k chip. The board was designed for either arrangement, it was fitted with either two 8K ROMs and IC11, a 74LS00, or a single ROM and LK2 jumper link. This looks to have started as the two ROM version and been modified to a single ROM. The ROM fitted is an Oric-1 BASIC 1.0 mask ROM, so another machine has been involved. That may now be running with the two original ROM chips from this board.
The CPU is also not original and I'd hazard a guess it came from a mark 1 VIC20, as it is a 1980's date code MOS part, and I've seen blue stickers like that on many VICs. Looking again at these pictures, the date codes are all over the place, from 1980 to 1984. Many of the chips look to have been replaced at some point.
Feeding the board with 5V directly, it is not working, there is a nice pattern on the TV though. In these sort of situations, I tend not to trust previous repair work, when there is flux residue on lots of chips on the back of the board, you know someone has been messing around in there.
When chips have been removed and resoldered without sockets, it is sometimes difficult to know if any tracks or through hole vias have been damaged. These is some damage around where the 74LS00 was removed and not replaced, so I decided the best option was to remove the other chips which had been replaced in the past and check out the board.
Once the board was cleaned up, it was actually in reasonable condition, so I fitted sockets for the larger chips. I tested and replaced the TTL chips that had been removed, all were fine. I also removed the two ROM sockets and fitted a single socket since I would never be using a pair of 8K ROMs.
There were only meant to be a few electrolytic capacitors on the board, so I replaced those. I may install a 7905 (with additional heatsinking) or a switch mode replacement, but at this point I just tidied up the 7905 bypass. A large label will be attached to the case if I leave it like that.
I installed a set of known working set of chips (thanks to @futurewas8bit for the ROM images).
Retesting again it was still just showing the black and white boxes.
Back to first principles, power, reset, clock. The power is OK, 5V getting to all the chips, a bit of ripple, but not much. I tried adding some additional capacitance, but it didn't change that much and still showed the black and white bars. Slightly better now, with a temporary composite video modification.
The clock was also fine, 1MHz into and out of the 6502. The reset pulse didn't seem to be there, it was going high too fast and the CPU was not resetting. I shorted out the reset pin and it booted up!
I tried many times, but could not get it to start up itself without forcing a reset. The reset circuitry on the Oric-1 is as basic as you can get, a capacitor is charged up by a resistor and the voltage across it should initially be low enough to start the reset cycle, and after a second or so be high enough to complete it and start the chip running.
This wasn't working. I had already replaced the 1uF capacitor, but that and the original had tested fine. I did manage to get it partially working with a 10uF capacitor, sometimes it would start after about 5 seconds, other times it wouldn't. I tried several versions of the 6502 and with both the 6522 and AY-3-8912 removed as they both have reset connections, but it wouldn't start up without a kick.
Most of the other 6502 based systems I can think of use a 555 timer based reset circuit. The same RC circuit is used to trigger the 555 and generate a clean reset pulse of a defined period. As far as I can see all the Commodore 65xx based systems from the very first KIM-1 through to the Commodore 128 all used a 555, or half of a 556 to generate a clean reset pulse.
The BBC micro also uses a similar circuit. It is only the original Atari 2600 I can think of that used the RC circuit. In the later 2600 Jr and 400/800 series at least they use a logic gate to buffer the R/C signal.
Apparently the original design for the Commodore 264 series (plus/4, C16 etc.) used an RC, but the 555 circuit was reinstated when Bil Herd took over that project. Given the 555 one shot timer circuit had survived through so many machines and cost reduction exercises in Commodore, a company not known for extravagant additional circuitry, it must be necessary?
But the Oric-1 only has an RC on the reset pin. It seemed the thing to do was to fit a 555 based one-shot time circuit to generate a reset pulse. The output of the 555 is high during the pulse, then low, so the plan was to use a transistor on the output to pull the reset line low, connected where the capacitor was, leaving the resistor in place to pull it high in normal operation.
I tried to think of a way of adding that neatly. but one 8 pin chip, three resistors, three capacitor and a transistor are a little difficult to hide. I then decided to cheat.
It's still an 8 pin chip, an ATtiny25 microcontroller, but doesn't need all the other items, I've added a decoupling capacitor, force of habit. That will be setup to enable pin PB1 as an output, and drive it low. Wait 100mS then set it as an input. The existing 2K2 pullup resistor will then pull reset line high, the CPU will start up and the microcontroller will go to sleep. I've set it as an input rather than driving it high so that reset can still be pulled low by an external add on or reset switch.
I think it took longer to write that description than it did to write the code itself. With the chip programmed and the fuses set for brown out detection and the low power internal 128KHz RC oscillator divided by 8, it shouldn't draw much power or create any noise. To fit it to the board, I looked to the pads left when IC11 was removed.
IC11 was a 74LS00 quad two input NAND gate used to derive the chip select for the ROM chips when two 8K ROMs were used. It has 5V and ground, and several connections that just connect to other gates in the same chip. Only three pins on the microcontroller are need. The two power pins, pin 4 is ground, pin 8 is VCC, are fixed, but of the remaining six, any could be used as the output, and the rest set as high impedance inputs.
Ground is in the right place with the chip aligned to the right and the other two pins are connected to pads that were wired only to other pins on IC11. No tracks to cut, just 5V to apply to pin 8 and I can use pin 6 as reset, which I wired directly to pin 40 on the 6502. I added the decoupling capacitor on the back, directly across the chip.
I did try to use a ATtiny44, a 14 pin chip that would have fitted the original footprint, but the pins were in the wrong placed and I didn't want to cut any tracks. I don't think you would spot it unless you were looking for it, fits in quite nicely. The original capacitor on the reset circuit (C21) is removed.
With that fitted, it is now starting up every time. I initially used a 1 second delay, and dropped it down to the 100mS shown above, and it still seems fine. That is about what the BBC used, the Commodore PET had 1 second, and the C64 500mS.
Next step is to try to reinstate the original chips, fix the power supply and improve the video output with a permanent composite video modification or RGB to SCART.

Update - see Part 2.

Friday 13 May 2016

Colecovision repair

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

This is a Colecovision, or CBS Colecovision as it was in the UK. It's one I picked up a while ago, but have not got around to restoring yet. It's not the one I am going to be repairing, just setting the scene.
This is the board I have been sent to be repaired, which has already been removed from its case.
Nothing looks immediately wrong, other than some suspicious flux reside on the back indiciating the TMS9929A video processor has been replaced at some point.
It powers on OK, and displays a screen. It is UHF out, and my LCD's UHF tuner isn't very good. I keep a small black and white TV for UHF testing as it is old enough to cope with the rough approximation of a video signal that ZX80's and ZX81's put out.
To test properly, I clipped on a temporary composite video modification so I could view it on a modern LCD TV.
Audio and 5V come from the modulator, composite video is on the blue wire, temporarily desoldered from the modulator. The PCB has a simple transistor video buffer on it. The resistor values need adjusting to suit the Colecovision, and the cables are a bit long, so it's not perfect, but we're now getting a picture. Something's not quite right though. Is that Welsh?
A few power cycles and checking clocks and voltages, all looks right and those errors are reasonably consistent, although the N of TURN is flickering between an L and an N. This is what the screen is supposed to look like.
Many of the letters are correct, but some are consistently wrong (E always shows as G, F as D etc.). Assuming the Colecovision uses ASCII or something similar, I looked at the ASCII values of the letters. The higher 4 bits were always right, but the lower were wrong.
U -> W  55 -> 57  0101 -> 0111
R -> P  52 -> 50  0010 -> 0000
N -> L  4E -> 4C  1110 -> 1100
M -> O  4D -> 4F  1101 -> 1111
E -> G  45 -> 47  0101 -> 0111
F -> D  46 -> 44  0110 -> 0100
Of those bits, it was only ever bit 1 which was at fault. In these situations, it's often stuck high or low, but here it is just consistently wrong? The Colecovision has two sets of RAM, 2x2114 giving 1K main RAM, and 8x4116 giving 16K of video RAM. Looks like a video RAM fault, and each bit is handled by a single chip, Time to remove the RAM chip connected to 9928 pin RD1 (video RAM data 1) and test it.
My ZX Spectrum based 4116 tester showed the chip was fine? This confused me for a while, until I realised that for some reason better known to themselves, Texas Instruments used the label RD0 as the MSB, the most significant bit, or D7 as everybody else calls it. It is actually RD6 that is D1, the second least significant digit, the one that is (presumaby) faulty.
I removed that chip and it did fail the RAM test. I sorted through my collection of spare 4116 chips and found one of the same type and speed, so it would be a good match for the remaining RAM. Can you spot the replacement?
With that in place, time to retest, and it is now showing the correct characters (yes, it is the same picture I used before).
That's just the built in test screen, time for a cartridge, the compulsory 'came bundled with the system' Donkey Kong.
That's playing nicely, all sorted. I think the sound is a bit slow compared to other Donkey Kong ports. It seems the 50Hz system may simply be running slower than the 60Hz systems it was designed for?
I did try both a standard US Colecovision and a CBS branded one which was specifically marked as PAL, in case they had altered the timing for the PAL release, but both sound the same. No big issue, I guess I'm just so familiar with the arcade and other ports this one stands out as different.

Tuesday 10 May 2016

VIC20 Diagnostics user guide

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

Following on from the previous posts on the VIC20 Diagnosics cartridge and test harness, here is a bit more information covering their use.
To start with, plug in all the connectors. Most will only fit one way. The edge connectors go with the test facing upwards, as shown. There is a pin missing on the keyboard connector, match this to the loopback plug.
Make sure you are using a good, known working power supply, or test it with a dummy load and a meter before going near your precious Commodore kit. As soon as you turn the power on and the testing should start. There are a few things that need to be working to some extent at least, the power supply, the CPU, the VIC, and the kernal ROM. Without those you would get a black screen or random garbage if it is the VIC chip. These things are often socketed, so if you don't get anything on the screen, and the usual checks (power, reset, clock) are OK, then try swapping those with good parts.
When the test is running, it isn't always clear what the error codes in the Commodore Diagnostics program mean. These are the results of my testing by removing certain parts, or swapping in bad parts. The first test is RAM. The VIC20 has all sorts of RAM in all sorts of places. The original has various sets of 2114 chips, too many to count. OK, I counted, there are 11, giving a total of 5.5K. Yes, you can have half a K. One of them is used as 4 bit wide colour RAM, the rest is pairs of 4 bit 1K 2114 chips giving 5K * 8 bits as normal. 
The later VIC20-CR  has four sets of RAM, 2x 2K 6116 chips giving 4K, a pair of 2114 chips giving 1K, and the single 2114 giving 1K x 4 bits for the colour RAM. There is also 1K of RAM in the diagnostics cartridge, which is required for it to run, and isn't actually tested.  Some of that RAM needs to be present for it to run. 
If there is a fault in the colour RAM, the display will be a bit flickery, and it will show the error. If one of the 6116 chips are faulty, it will show an error. If one of the pair of 2114 chips is faulty, it will just show a black screen.
Next comes the ROM tests. These are even more cryptic. If all is well, three numbers will be shown. These are, in order:
  • Character ROM checksum (should be FF)
  • Kernal ROM checksum (should be E0)
  • BASIC ROM checksum (should be C0)

If any of these fail, the actual checksum is shown. If the character ROM is bad, the first line will show an error, the second line will show an error if the Kernal ROM is bad, and if the the third line shows bad, it is the BASIC ROM at fault, as shown below. The checksum should be C0, but it was calculated as 0A. Sometimes, the number calculated changes each time you run the test indicating an intermittent fault.
Both the PAL and NTSC versions looks for the same checksums, so it appears the checksum should be the same for all versions of the ROM. Commodore presumably modified an spare byte until the checksum came out the same. ROMs that work but have different checksums (e.g. JiffyDOS) will fail as they haven't been adjusted (I think that gives 6B).
I have now seen a couple of cases of ROMs which initially pass, but then fail after a few minutes. Here it is the character ROM which is failing. I swapped it out for a replacement ROM and it ran fine for several hours. Putting the old ROM it failed again after 3 minutes, so I'm happy to conclude that ROM is bad. It was working OK in operation, but I think it's time to swap it for a good one.
The rest of the tests are the I/O ports, handled by the two 6522 VIAs. The keyboard test will pass if the first 6522 is good, even in the keyboard loopback is not installed. I presume this is intentional, so you can test without opening the case. If the loopback plug in installed and there are problems with the first 6522, you will get a keyboard error.

  • The keyboard tests are down to the first 6522 (nearest the keyboard)
  • The serial bus problems are usually down to the 7406 or the second 6522 (nearest the serial port).
  • Cassette port tests fails can be caused by the second 6522, or the TIP29 cassette motor drive transistor.
  • Joystick errors are down to the VIC chip or the second 6522.
  • User port errors are again down to the second 6522.
  • The pos/neg edge tests are to do with (guess what?) the second 6522 (it's really getting a work out). They refer to edge triggering I/O and interrupts on the control lines via the user port.
  • The timer tests refer to both 6522 VIAs
  • The sound test should get the VIC chip to play a sound.
 Next come a couple of test card screens, you can check for colour or alignment issues. 
The test then loops around and repeats until something fails or the power is removed.
N.B. Through out this, read all of these are suggestions of what may be at fault. Many problems can also be caused by address decoding, buffering (particularly on the RAM on the original VIC), power supply problems etc. or interaction between parts. One bad 6522 VIA can cause problems with the other. You can also swap the 6522s around and see if the user port fault changes to a keyboard fault etc. One bad ROM can cause others to fail. VIC20s usually only have a few chips socketed, but these can suffer from bad contacts.

Diagnostic boards and loopback cable are available from my Tindie store, either as PCBs, kits of parts, or assembled and tested sets.

2022 Update: The VIC20 Penultimate Cartridge includes a built in Dead Test and is now available from  The Future Was 8 bit