Here we have another Commodore 8032 in for repair, this one looks in reasonable condition this time.
Although I was a little worried when I opened the box, bare boards in polystyrene is probably not a good idea for a static point of view. However it did at least provide good mechanical protection during shipping.
This is the first time I've seen one that appears to have been bolted on from new, including what I'm sure are the original untouched TIP29 datasette power transistors. I see no reason why anyone would drill the rivets out and replace them with bolts if they weren't faulty. Later PET boards (and all the VIC20 and C64 machines) had the regulators 'flapping about in the breeze', presumably to add a little air cooling rather than heating up the PCB.
The rest of the board looks fine. Like the previous post, this one is from Germany, so has an alternate editor ROM and character ROM to support some inflected letters.
The fault report (helpfully taped to the board) on this one is it beeps (a good start, the CPU, address decoding, KERNAL and editor ROMs and at least some of the RAM and IO chips are working), but it is displaying 'some random characters'.
The results are interesting, time for some analysis.
So again, many things are working to get this far. When you see a garbled display like that, it's normal the multiplexor chips that have failed. The 74LS157 switch very quickly between the processor address bus and the video address bus (generated by the 6545 CRTC). This is the later 'universal dynamic PET' board, which can be 40 or 80 column by changing that row of jumpers (old blog post on converting an 8032 to a 4032).
What normally happens is they some of the bits get stuck, and you work out which ones by counting the size of the blocks of repetition or blanks. Here you can see we get 16 characters then a repeat, then 16 OK, the repeat etc. That would point to bit 4. being stuck, and I think there is another error higher up. The video RAM is testing OK though (I think I can read that amongst the rest), and there are various RAM faults as well.
I replaced all three mux chips. When one goes, there's a fair chance more will go. They also have a tendency to fail as they work quite hard.
Unfortunately, that didn't fix it. It cleared up part of the problem, but not all of it. I checked over the work, no shorts, everything testing fine, and the chips were new from the tube. I couldn't see anything wrong there, so I looked further up the food chain. The 157s switches the addresses generated by the 6545 CRTC. The 40 pin chips on this board are socketed, so it was a simple matter of replacing the the 6545 to see if it was that.
Well what do you know, faulty 6545, and probably at least one faulty 157. I need to build a proper tester for these. They usually pass on the chip tester built into EPROM programmers as they test at quite low speeds, and these things tend to do OK at low speed, but in their old age can't do things as fast as they used to be able to do (happens to us all).
I don't like running boards too long in this sort of state, if there are faulty chips writing to the databus when they shouldn't, that can burn out other parts on the same bus, the strongest driver transistors win. I noticed the number of RAM faults wasn't constant, but was worse than the previous photo. I did have time to finish probing around the board, and I found the culprit.
This is the 7905 regulator which generates a -5V reference voltage for the 4116 RAM chips. They always seem to be at jaunty angles and are not bolted or riveted down as the tab is connected to the input voltage, rather than to 0V on the 78xx versions. If you do bolt one down and connect the tab to the voltage rail bad things will happen. It looks like the right hand leg has some extra solder on, as if it had been repaired in the past.
The central leg was sort of touching the pad, but wasn't actually connected. When I had first powered on the board, one of the first things I do is check the supply rails, and -5V was present then, but it's not now. Rather than replace this with a similar part, similarly lacking support, it could snap off again, or vibrate around in shipping. I prefer to replace them with an alternative version of the 7905.
This has a plastic cover all around the tab, so it can be mounted flat on the board without shorting out. There is no problem here with heat, as the -5V is only a reference, and it looks like the board has pads for a small TO18 packaged version. I don't think they make those any more.
Everything is now passing. The editor ROM is consistent CRC, but not a version I recognise. The normal DIN versions are 4K ROMs, but this is on a 2716 EPROM, so it's only 2K. It appears to have a different keyboard mapping to the previous German DIN editor ROM. I'll add it to the list of known CRCs.
It took a while to guess which keys to press again, but I got it to load from tape and seemed to be running well. I couldn't get it to load from IEEE-488, but a closer inspection around the IEEE-488 connector explained that.
These were not fitted from the factory on later models, It looks like someone has fitted a connector to the normally empty pads, but has unfortunately damaged some of the through hole plating in the process.
I did what I could to patch up the broken continuity and got the edge connector active again, and looking extra shinny with a touch of contact cleaner and fibreglass pen.
A Commodore PET 8032 board in for repair today. This is an early 8032, the dedicated 80 column board, not the usual universal 40/80 one. This one looks interesting, my favourite, a board that has previously been worked on. It's always fun having to retest all the previous work.
Firstly, the 6502 is missing, the owner had removed it before shipping (?). Several of the ROM chips have been replaced with EPROMs, including one shrouded in mystery covered in tape, and another that looks to have had some pins broken and soldered into some stand off pins.
Above are two original mask ROM chips, but it looks like they are the wrong way around. The original sequence was three BASIC ROMs, 901465-19, 901465-20 and 901465-21. Then the editor (various versions depending on screen, keyboard and language). Finally, the KERNAL, 901465-22. A bug was discovered in the 901465-19 ROM, so all but the very earliest 8032s come with that chip replaced with 901465-23. So the correct order of chips should be 901465-23, -20, -21, editor, -22, so those two are the wrong way around.
The other noticeable issue is that the two 7805 (or LM340) 5V regulators have been replaced, and instead of the original round metal TO3 packages, they are rectangular TO220 versions.
I'm not too happy with that aesthetically, but also the 0V lines appear to be connected to the frame ground connection on the IEEE-488 port. That is different from the 0V rail, and the 56R resistor connects the two together and that is the path to ground.
When bolted into the case, that will eventually get back to 0V via the metal case connection back to the centre tap on the transformer, but that's not the best place to reference it. For the moment, I shorted out that resistor to tie the 7805 ground pins to the PETs OV rail. There is also a track, which is the 5V output, that appears to have been cut on the back of the board, but is still making contact.
I powered on and all the voltage rails were present and correct, nothing was particularly hot, so I'll leave those for the moment and get on with the rest of the testing. On power on, the board chirped as normal and the screen was initialised and blanked, but nothing happened. That usually indicates a fault with the BASIC ROMs or a partial RAM failure - enough RAM for the KERNAL to get so far, but not enough for BASIC to print up the READY message.
Time to get out the PET Diagnostics board and fit that in place of the 6502. That should generate a display and test the system ROM and RAM, even when there are ROM and RAM faults. (these are now available on my Tindie store)
That also got a beep and the display fired up and was filled with text, but it was clear there were some video problems. It looks like the main RAM is OK, but there is a video fault, and some ROM issues. To get a clearer result, I switched to the PET LCD board with PET diagnostics plugged into that.
That showed the ROM chip in socket D10 (marked 901465-20) was faulty, giving an unknown CRC. and the chip in D9 (marked 901465-23) was the working, but in the wrong socket (it is the B000-BFFF ROM so should be in D10). I swapped those around and went back to a 6502 to see if it would boot, just in case it was somehow a different variant of the 901465-20 ROM. That got no further, still a blank screen.
The ROM sockets on the PET do not conform to the standard 2732 EPROM pinout, but it can take 2532 EPROMs, and I have a few of those. Most modern programmers don't support the 2532, but I keep my Stag P301 programmer around for things like that (as a follow up to that blog post, the Fujitsu NiMH batteries are still going strong).
I printed a label for the new EPROM, and decided to also label up the other EPROMs, since the editor ROM was uncovered and should have something over it's window to prevent it being erased. The one hidden under the tape was also a TMS2532 replacement. The editor is the German DIN version of the editor ROM.
Checking those with PET Diagnostics, there was now a full set of BASIC 4 ROMs. I wanted to get those fixed, in case that was contributing to the display issue, but that is still present.
The tests show errors in bits 4 and 5 of the even video RAM. Time for a process of elimination. The 80 column PETs have the video RAM split into odd and even bytes, as apparently they were not fast enough to keep up if they were used sequentially. This means the video circuitry is split into odd and even halves. The odd video RAM seems to test OK, and every alternate character does appear correct, so that rules out the common elements such as the character ROM and the output shift register.
It is only affecting bits 4 and 5, so that rules out one of the RAM chips (UC4), and one of the 244 buffers (UB4), as they only connect to bits 0,1,2 and 3. That still leaves the other 244 buffer (UB5) that allows bits 4,5,6 and 7 of the even video RAM to be written (and also read) by the CPU. It also leaves the RAM itself (UC5) and the 373 latch (UB3) that stores the output of the selected byte of RAM to feed the character ROM address lines. To narrow that down, it's time to get the 'scope out and probe the pins.
Probing the even data lines, bits 0,1,2,3 and 6 and 7 were changing, but bits 4 and 5 were doing nothing. That points at the input buffer, as nothing is getting into the circuit. With a replacement 74LS244 at UB5, time to test the theory.
Success, also note the previous 'inconsistent CRC' messages are now missing and the empty sockets are correctly detected as empty. When testing the CRC, all bits should read high, but when something on the bus is misbehaving and writing to the databus when it shouldn't, some different values are read. In this case it seems the LS244 was causing some output on the databus when it wasn't meant to be. The border around the screen is meant to be a solid line, but the DIN PETs have a different character set, so don't have the line drawing characters.
The only thing left to do now was sort out those regulators and the damaged track. I have some of the right kind, but originally they were riveted to the heatsink. I could bolt them in, but let's do this properly. It's been a while since I riveted anything, but I still have a rivet gun somewhere.
These 7805s were particularly thick, so I had to get some longer rivets, to fit through the PCB, the heatsink and the regulator flange.
Not bad, I think I did OK there, seems to be making good mechanical and electrical contact, don't think they are going anywhere.
That's better, how it was meant to look, the original 7812 and the two new 7805s.
On the back, I scraped away a bit of the solder mask and flowed some solder onto the track where the scratch was. The rivets look nice and clean, I'm quite pleased with the way they turned out.
That's all back together, ready for testing. It chirped, and up came the ready prompt. It was a little tricky running test programs as the DIN keyboard layout is slightly different to the normal UK/US business keyboard, so it was a little trial and error on some of the punctuation symbols.
All looking good, loading programs from tape and IEEE-488 port, and running a BASIC memory test program. A bit more soak testing then it's on it's way back to it's owner.
I suppose so, but I wouldn't recommend it unless you actually have an old CRT monitor with proper separate chrominance and luminance inputs. Many modern LCDs can make S-Video look worse that composite.
The circuitry inside the Atari 400 is similar to that in most other Atari 8 bit products, the signal is produced from separate sync, chrominance and a number of luminance outputs feeding a resistor ladder to generate different output levels.
The Atari 800 is a good reference at this point as it does actually have S-Video output from the same set of chips.
There is a lot going on with the Atari 800, so my plan was to replicate the parts necessary to generate the clean luminance and chrominance signals, but remove the circuitry which combines these to generate a composite signal, to reduce interference.
As with the composite video modification, the audio modulator oscillator transistor and variable inductor are removed to stop this interfering with the video signal. The conversion is a little more complicated, as the chrominance and luminance need to be split, then separately amplified.
To do that, I used two TFW8b.com video buffer boards, one for the luminance signal, and one for the chrominance. The ground and 5V lines are commoned, red and black for power and white for audio as usual. Yellow is used for luminance, and green for chrominance.
I stuck these boards to the inside of the internal metal shielding box. It's easy to connect to the mainboard from inside there, but there isn't an easy path to run the wires to the outside of the case.
To keep the Atari 400 modular, I had used connectors for the main board, and I thought the best option was to fit a 5 pin DIN socket to the side of the case to maintain the shielding but give a route for the output cables.
I went through a few variations on the circuit, trying to get a good S-video signal, and it ended up that the back of the DIN socket was a convenient place to add some extra bodge resistors.
That is a 75 ohm resistor in series with the luminance signal, and a potential divider with a 270 ohm and a 75 ohm to reduce the level of the chrominance signal.
The original plan was to use this to attach the final external cable, using a 5 pin DIN to 4 phono plug lead. Two for audio, one for chrominance and one for luminance, or possibly cutting off those two and fitting a 4 pin mini DIN plug for the SVideo. This ran out of the bottom of the case where the RF lead went. (I did consider making this the same pinout as the Atari 800, but decided the extra audio connection would be more useful).
I don't like to drill holes in cases, but was specifically asked to do so, rather than supplying a flying lead like that. I still used the pre-wired DIN lead, but now a little shorter than planned, to attach to the new 4 pin mini DIN S-Video socket and phono audio socket added to the case. The forth wire is not connected, that was a second audio jack, which is no longer required.
Inside, there are a few more changes, a 10uF capacitor has been fitted in place of C183 to provide a decoupled audio signal. Various parts have been removed and some of the resistor ladder has been modified to match the cutdown 800 schematic, including the additional diode in series with R176. Several 0.1" header pins have been fitted in the holes left by removing parts to pick up the output signals. I was going to use individual connectors, but these lined up nicely, so I used longer connectors to get the two power cables on one lead and the three signals on another. This allows the board could be disconnected from the case so it's not all hard wired together.
The connectors from the video buffer boards plug onto this as the system is being reassembled. See also the 48K RAM board in the background.
There isn't much to do on the power / output board, other than to remove the RF modulator.
For testing, I've wired this up to my Commodore 1901 monitor.
The picture is good, but I can't honestly say I saw much difference over composite. It is probably slightly better, your mileage may vary, but it's certainly a lot more work to do than the composite mod.