A recent visitor to the repair bench was this Star Wars PCB set, from an AAer who is about to do a restoration on a barn-find cockpit cabinet. I've fixed a few of these boards in recent years but have never attempted a write up, as I always thought they would be too long-winded. I said I'd probably write this one up when I took the repair job on, and then it turned out to be the longest of all the Star Wars PCBs I've done, so this repair log is a bit of a monster.
I apologise that some sections get a bit deep, but assembling a repair logs from months of notes can get a bit tricky, as a result some sections are a bit closer to the raw notes and harder to follow, than stuff I normally post.
Anyway, the cabinet this came out of is a long way away from being safe to power up, so the boards arrived in an untested state...
...but as suggested by the faded stickers they are faulty, and it's likely they have been faulty for many years, decades probably.
Star Wars is a three board set, a main CPU board which contains the main CPU and the "mathbox" system that handles the wire frame graphics calculations in hardware.
Underneath is the vector board, which takes the geometry data and converts it a table of vectors, which is then fed to the output stage amplifiers which create the signals that control the deflection coil amplifiers on the monitor's deflection board.
This cockpit cabinet for this board still has the original 25" Amplifone tube and the high voltage board, but not the deflection board. The HV board has the identical hacks that my cabinet had so they were probably siblings and may have been owned by the same operator originally. The Amplifone monitors were what the game PCB was designed for, but they had a reputation for failing in impressive ways, killing themselves and often the PCBs that were connected to them. So the fact the cabinet is missing the deflection board might be a clue as to what happened to this board.
The third board in the stack is a smaller sound board,which is a completely separate 6809e CPU system, that handles the POKEY sound generators, speech synthesiser and the pre-amplifiers for the 4 channel sound.
It's quite impressive that all 3 boards are original to each other, all sharing the same SD01824 serial number.
While the boards look clean, there's little point in going for a power up test. Faulty cabinets tend to have spent years in garages or sheds and the boards usually show severe corrosion across a range of ICs, being worse on the upper edge of the upper-most ICs, where the dust and dirt collected.
The degree of damage depends on what the legs are made of, so some chips are relatively unscathed, but the Atari custom AVG chips are always in a bad way.
Rusted out ICs are only part of the problem, a major issue these boards have is the early 80's single-wipe sockets. These are an old style socket that went out of use in the mid 80s in favour of the dual wipe sockets that are still around today. The single wipe ones only have one contact spring per leg, which pushes outwards on the inside face of the leg. Over time these springs lose their springyness, and/or the chip legs slowly splay out. As there is no outer contact spring to push inwards the contact pressure gets lower and lower, and the same time as oxide builds up over the decades. Add to this the fact that the metal becomes brittle and you end up with hundreds of bad contact points and probably dozens of broken pins scattered across the board, all hidden under the plastic socket housing
While I could chase down every fault, the board will never be reliable with so much corrosion and old sockets, so its just quicker and saner to replace every socket with a high quality modern dual wipe one. Machine pin sockets need not apply, they are completely unnecessary and introduce different issues, especially if you need to remove and reinsert parts more than once.
So all three boards went through a full strip, and got a set of new sockets, sound board first.
All the socketed ROMs and RAMs that had badly rusted or missing pins went in the scrap pile.
Any that looked OK went through my EPROM reader which added a few more casualties - one ROM that was in physically good condition but gave random reads, and a bad 2K SRAM IC from the vector board joined the scrap.
The 6089E CPU from the sound board and the AVG custom IC from the Vector PCB were also retired, as they both left a selection of their legs in their old sockets.
The AVG custom ICs are a high failure part, even if they keep their legs, and faulty ones can spit out vector data that can destroy an otherwise healthy vector monitor. With modern replacements available for US$25 the originals aren't worth saving, even when they aren't as wrecked as this one.
Most socket pins come off without a struggle, but some put up a real fight and had to be cut up and removed in section. On others, the pin sheered off level with the PCB surface, making it hard to desolder as you can't waggle the pin in the hole while you hit the pump. Along with the sockets I also replaced any IC that was heavily rusted or just looked rotten, and after few hours the wreckage had already started to mount up.
With the board populated with new sockets it was just a case of installing everything and filling in the gaps left by the wrecked parts. A 6809E CPU came off a trashed QIX PCB I had from the same owner, and some suitably vintage SRAMs came out of my stock. I do opt to replace a lot of parts on these boards to ensure they are reliable, but I also try to keep everything as original-looking as possible by using age appropriate spares where possible. I've installed the ESB upgrade kit for during a few of my previous repairs and as this replaces all the ROMs and PROMs, I have a collection of original parts for these boards.
The only part I didn't have a replacement for was the original AVG custom, so I just borrowed the modern replacement from my own board set, while the owner added one to his shopping list of cabinet parts from the US.
For some reason, Star Wars board sets always seem to come with a completely random set of bolts and screws rammed into the spacers and stand-offs, including snapped or cut ones. This board was no exception...
...including the stump of a snapped bolt jammed in the filter board mounting hole.
Without the correct bolts, the boards are always popping loose and flexing the rear edge-connector, creating intermittent faults to drive you mad while troubleshooting. So the stump was drilled out, the threads cleaned up with a tap, and the board fitted a set of imperial bolts that it would have had originally.
At this point I was pretty confident that the majority of the faults would have been swept away with the wreckage and I'd only be left with a handful of issues to track down. I had no idea the fun that was coming!
Time to power it up - which is easier said than done with these boards as they need a weird set of voltages
+5v for the main logic
-5v for the audio PCB op-amps
+12 for RGB output stage biasing and the audio amplifiers
+10.6v to get the reset circuit to disengage after a suitable pause
+22v & -22v to feed the voltage regulators on the X Y output amplifiers
The simplest option was actually to hook the board up to my own cabinet, just without the monitor connected initially. A faulty Star Wars board can kill an otherwise healthy Vector monitor, and a faulty monitor can kill a working board.
So before it gets hooked up to a monitor it is wise to check the output waveforms and voltages on the X and Y outputs, to see if they are within specifications. The rule is that you should see no more than 1 volt of DC on the X or Y output relative to ground, and no more than 5 volts AC. Anything outside that means something is wrong which could cause damage. So I unplugged the monitor power and video cable and powered the board up blind.
The 3 LEDs on the CPU board came on and then went out, which suggests the main CPU is running enough to pass the self-test on boot, but I'd expect to hear some signs of life from the audio system if it was a fully working board, but there was silence, not even the pop from the reset signal bouncing the POKEY sound generators.
The PCB set is designed to provide audio cues to assist troubleshooting without a monitor, but that needs a working audio system, and I didn't even have that.
To rule out the sound board I swapped in the known good sound PCB from my board set and flipped the switch and got the "May the force be with you" speech clip. I could also trigger a game using the yoke controller, getting the "Red 5 standing by" sound effect. So the main CPU board is confirmed to be OK enough to run the game code at least. I was wary of using my sound board as a donor for repair as each board contain four POKEY sound chips, and these are getting rarer by the day. Currently they are about USD$50 each, if you can find anywhere with them in stock.
The prime suspect for a non-responsive sound board is the R6532 RIOT chip as this handles the communication between the main CPU system and the sound CPU system.
It's easy to rule out by swapping in the 6532 from my sound board, and with that on board I got the audio pop on reset, and the "May the force be with you" speech. With a working audio board I grounded the test pin to kick off the audio system tests. This tests each of the four POKEY chips, and steps through all the sound effects, speech clips and plays all the music from the game. All 4 POKEYs reported as good and the sound board passed all tests.
A working CPU board, and a working sound board let me run through the main system tests, which gives 16 beeps, any low tone beeps denote a specific failure, but in this case I got 16 high tones meaning no faults were found. This is a long way from an exhaustive test but it means all the ROMs and RAMs on the board are confirmed as working.
On exit from sound test I couldn't start a game any more, which had me scratching my head for a bit, until I realised the board probably wasn't in free play so I needed to add a credit via the Aux switch inside the cabinet, before the controller would respond again. I'm not sure why it booted up with a credit the first time, but this just highlights that working without a video output is a pain. So, onto the video outputs to see if they were healthy enough to try a monitor - they weren't.
The X-out voltage was far too high, showing between 1-2 volts of DC and 5-7.5 volts of AC. Healthy readings should be no more than 1 volt of DC and 5 volts of AC.
X-out was active at least...
But the Y-out was silent, giving just a flat line on the scope.
The Y signal goes through a few TL082 op-amp stages in the analogue stage, leaving the digital domain at the inputs to AM6012 current DAC at 6E, the output is combined with the YBIP signal coming in as a current reference and then goes through one of two gated pathways, depending on whether the Y-Invert pin is pulled low, or left high. I had what looked like normal activity on the DVY signals into the DAC, so the fault lies somewhere in here...
I could verify that the digital signals were getting to the inputs on the Y stage AM6012 DAC (although they were very noisy), but the output from, the DAC s a current-modulated signal, which will just show up as a flat line on the scope. The next sign of life should be at the op-amp outputs where the voltages that head to the monitor start to be built up. With a working X section I could at least compare the X and the Y to see where the activity stopped.
It was worth noting that the AM6012 at 6E for the Y section was original to the board, while the one in the X section at 6A had already been replaced.
The Y section one had also taken a beating at some point.
While the legs look like they are falling off it is actually just the plating, underneath they were still strong, and the black tarnish is highly conductive so it isn't as much of a problem as it looks. A dead AM6012 fpr th Y section would certainly give me the fault I was seeing, but they aren't a part I had in stock and I didn't want to start pulling parts off my working board.
So I took the only option I had which was to remove the AM6012 from both the X and Y section, fit sockets and swap them over. If the DAC at 6E was bad I should end up with a working Y output, and a dead X output. What I ended up with was the same fault as before, the X was still alive, giving the same dodgy voltages and Y was still stone dead. Whatever is jamming the Y signal wasn't the DAC, but this hadn't proved either of the DACs are healthy. To be on the safe side I ordered some spares from Ebay and hoped the ones delivered were the vintage looking mix of chips the seller actually had in the listing. ETA was 10 weeks, gotta love the post COVID delivery times.
With the 6110 DACs on order, but confirmed not to be cause of the silent output, I moved onto the other candidates in the circuit, the 2 TL082 op-amps, an LF13201 CMOS switch, and a bunch of passive parts as the remaining candidates, plus the PCB itself.
I started poking around the op-amp sections, comparing both X and Y with the scope, and then the board just died on me.
The input signals to the X and Y section went silent, and the ACT LED on the AVG replacement module went from being permanently on to pulsing slowly. There's nothing I could kill in the final output stage that would brick the board, so something else had failed. The CPU board could still boot, as indicated by the 3 LEDs going out, but the board would rarely run for long before resetting, due to the watchdog kicking in.
To rule out the RAMs and ROMs again I put them all through my EPROM tester for a second time, finding an EPROM at 1L was bad, giving random reads instead of the data it held not long beforehand.
With a newly burned ROM installed this fixed .... nothing. The board was still resetting sporadically and the vector board was quiet.
I had put off swapping in boards from my board set, to prove which of these boards were faulty, and hopefully which fault lived where, as mine has the ESB multi-game kit which is a pain to remove. I'd have to remove the kit, re-populate all the ROMs and PROMs that the kit replaces and put the board back to stock, but at this point, with limited clues from the scope poking, and faced with camping on the floor behind my cabinet, it seemed like a good option.
So pairing the patient CPU board, with my vector board, I checked the voltages (which were normal) and hooked up the monitor. The game would run, but with all the stars and ships drawn in the far distance as dots whirling around.
I could start a game with the trigger buttons but had no yoke controls. The likely candidate for this fault is the ADC0809 chip at 9K as that converts the analogue position of the yoke into a binary number, the buttons are already binary, either on or off so they bypass the ADC entirely. Borrowing the ADC from my board restored the yoke controls. Another IC for the scrap pile, but not the one that shut down the Vector board. I added some ADC0809s to the shopping list and moved one.
Running through test mode gives a load of mathbox divider errors in the section of the CPU board that handles the binary maths behind the wire frame graphics and the star field, basically anything that moves in the 3D space.
To rule out ROM-set mismatches (I'd no idea of the history of this board) I paired my vector board, with my CPU board, and the ROM set from this board, including the bipolar proms, and got no faults at all. GFX normal, and all tests passed.
ThenI put the vector board back on my CPU board and all the ROMs/PROMs from the patient board-set, and got the same fault as before - no video, and the AVG ACT light blinking again.
That all proved that
1) The CPU board has mathbox errors, but does run enough to work with my Vector board.
2) The Vector board has a new fault in the digital section (that shut everything down) as well as a fault in the analog output section.
Half the problem with this repair so far is the need to be sat on the floor, in bad light, behind my cabinet with the board propped up against the cabinet, as I had no way to power it up on the bench.
Adding the Fluke 9010 to the party with a 6809e pod (my precious!!) let me validate everything that the CPU should be able to see in the 64K address space, which spans both the CPU and Vector boards...
...but even with the in depth version of the RAM tests all the tests passed, so communications between the CPU board and the Vector board were fine. This just leaves the control signals that are external to the address space, as the CPU board seems able to control my Vector board, so maybe the Vector board has a fault in the circuits that accept the control signals.
By poking around the AVG chip I could see activity on many pins that stop and start in line with the flashing Act light. One suspicious signal is pin 6, called /VGGO on the schematic, it's active when low, but was always high, with glitches that looked like attempts the transition to low that never get there. One thing this Vector board isn't showing is any signs of "GO", so I followed it back up the path.
This tracks back to the LS244 at 1P, the output on pin 16 was the same, but the input pin 4 is a ragged mess.
As this is an input pin you would think the fault is upstream, but this signal comes from the CPU board, which works fine when paired with my Vector board, so unless this is a threshold fault the issue is likely elsewhere. Or this is a new fault that didn't exist 30 minutes prior.
I was also seeing twitching on pins 1 and 19 which are tied to ground, so I actually suspect something is wrong with the 74LS244 IC itself.
So 1P came off the board ...
...and tested ok, I fitted a socket so I could test without a chip on-board, then drop one in without pulling it all apart again, lifting individual legs if needed. Without 1P on the board the signal at pin 4 was still just as much of a mess so the source is further upstream, except that signal comes from on the CPU board, a signal called EVGGO
This instantly starts to smell like a red-herring, the swap tests confirmed that the fault wasn't on the CPU board, but the first sign of fault takes me straight back to the CPU board. So unless this really was a threshold issue I didn't have much hope I was on the right path. This signal comes off an LS138 address decoder 74ls138 at 8M, on pin 15 and goes straight to the board interconnect on pins 71 and 72.
This LS138 controls a few other things, including ADCSTART signal which briefly had me wondering if the controller input ADC had been killed by a fault in this area.
Inputs to the LS138 looked OK, but the output on pin 15 was a mess, as is 14 (compressed high), so 8M came off the board, and unsurprisingly tested fine. Interestingly the noise on pin 15 is still there with the chip removed, and nothing at 1P on the vector board, so it looks like this is just impulse noise as the track run from the CPU board 8M pin 15 to pin 4 on 1P Vector side is very long, passing by a tonne of other stuff to pick up noise from.
A week or so passed before I came back to this, and I couldn't shake the feeling that this was a new fault that had appeared on the CPU board, so I pulled my board set apart again and repeated the divide and conquer attempt.
My Main PCB, with all the repair boards RAM/ROM/PROMs, and the patient Vector board gave me the blinking ACT light fault, and pin 4 of 1P on the patient Vector board, looks equally messy and that's all coming from my CPU board, so the fault is 100% on the vector board and I was on a wild goose chase before.
Pairing the CPU board and my known-good vector board, the patient sound board, my 6532 and ADC chips gets me a playable game, with all sounds, music and controls, but except all moving items are now drawn as a single spot...
...and maths box errors have changed.
So whatever fault is causing that has gotten worse, but the inactivity on the Vector board still isn't caused by the CPU board, so it is something on the vector board itself.
After poking around for ages I couldn't find anything clearly wrong, and my notes get a bit hard to follow in retrospect.
The on/off pulsing of the Act light is in time with pin 5 on the AVG chip, which is signal /OP2, which comes from LS32 at 5J, which ANDs the SA and /OP2 signals. SA seems to be inverted 5V by pins 8/9 on a 74LS04 at 6K, so stable as a LOW, and /OP2 comes from the 74LS175 at 4H. It is also bouncing but so is pin 1 (clear) which should be tied high via PU Resistor 110. On the 5 V side this is high and stable, but on the chip side of the resistor it is glitchy. So what else uses PUR110 to attain a logic high? Turns out dozens of other ICs,
4H LS75 pin 1
Vector Data Shifters
5A/5B/5C/5F/5H/6H LS194 Varied Pins
Op Code and Intensity Latches
/LATCH 1 - signal comes and goes perfectly in time with the ACT LED, otherwise HI
/LATCH 3 - silent in and HI
Latch signals come from State Machine which probably should not be silent
HALT is firing in time.
Which tracks me back to the 74LS42 at 3D, with some output pins looking unhappy.
Pin 3 struggling to pull low (Latch 2)
Pin 4 Stuck high stable (Latch 3)
Pin 6 struggling to pull low (Strobe 1)
I wasn't convinced that the LS42 was bad and in all likelihood this was another wasted evening's wild-goose chase through the logic, , so at this point I hung up the scope for a few more days to clear my head.
After a few days off I hooked up the HP logic comparator to the LS42 and it didn't flag any mismatched pins. However after removing the comparator the ACT light stayed lit, but now the board was even quieter, as if it had died a bit more and isn't even trying to start any more. Getting more faulty sounds bad, but it is actually is quite helpful, as it is much easier to spot IC that is doing nothing when it should be doing something, than it is to catch them doing something but the wrong thing.
I worked back and ended up at a bank 74LS161s in the Vector Timer circuit and something was clearly wrong, I had the 12Mhz clock signal going in , but the outputs were counting extremely slowly. I just replaced all 4 74LS161s with Jaycar's finest, it cleaned up the signals and fixed the counting output issue, but didn't cure the problem.
At this point I finally ran out of patience troubleshooting on the floor, hanging out the back of my cabinet in the shadows and ordered the bits to make up a proper test harness so I could work on this at the bench. The CPU and Vector boards don't need anything too fruity, just 5V and 12V, plus a 10.6v feed which the PCB uses to determine that the power supplies have stabilised enough to come out of reset.
While those parts bounced through the postal system from China the board sat quietly on a shelf, acquiring new faults for me to find.
Once I finally had it powered up again, the board was now dead, stuck in reset and wouldn't even boot. Initially this was due to my voltage divider not giving me the 10.6v I was expecting, so I fitted a variable resistor to the harness to tune the voltage level to the point that the logic level at pin 11 of the LS14 at 10R was high enough for the output on pin 10 to go logic low.
This should have released the board from reset but it was still stuck. The issue seems to somewhere around the 393s in the watchdog and master clock circuits at 2R and 2P.
WD-CLR comes direct from an LS138 output pin 13 on 8M and this seemed to be triggered correctly, which should be the CPU writing to that address to try to prevent the watchdog from barking in normal operation.
The master clocks are derived from an LS161 at 2N, which is run as a pure counter, taking in a 12Mhz clock and spitting out a 6Mhz, 3Mhz which goes to a the 74LS74 which feeds the CPU clock, a 1.5Mhz clock and a 750kHz clock which goes into the watchdog counters at pin 13 (A) on LS393 2P, and the last of the 4 outputs divides it by 4 to a 46Khz signal
There are 4 counters in the clock chain, two in each of the 74LS393 ICs at 2P and 2R.
Annoyingly, 2P looked pretty normal on the scope but the comparator said it was bad, and 2R looked too quiet on the scope but the comparator said it was fine.
2R counts when WDDIS is grounded, but doesn't count when WDDIS is pulled high by the pull-up, which is weird as there should be no dependency, the counting output should just be ignored by the downstream 74LS74 at 6R which has a very noisy on pin6, the /Q output which is the master reset signal which goes all over the place, including to the Vector board via pin V on the board interconnect.
So I removed the Vector board again and ran the CPU board solo, the reset line released and the board booted, so the new reset fault is another fault on the Vector board.
All this madness kept tracking back to the 74LS244 at 1P on the Vector board, that handles signals going to and from the CPU board, an IC I had already removed, socketed and replaced. With the board set back together I pulled 1P out of the socket and left it empty. On power up the board booted, passed self tests and gave the "Force be with you speech".
So whatever is jamming this board was passing through 1P. Running over the empty socket with scope landed on pin 18 (VGHALT), looks jagged and floating
Even the probe impedance on pin 18 put the board back into jammed reset mode. Whatever is on the end of VGHALT is either unhappy or the signal created as VGHALT is wrong, or weak.
VGHALT signal goes straight to pins 61 and 62 on the board interconnect, and straight back to the CPU board, which isn't faulty, to input pin 6 on LS244 9H on the CPU board.
This was getting annoying, the board swap tests proved it wasn't the CPU board, but all signs of the fault kept leading me straight back to the CPU board. Both 1P on the vector board, and 9H on the CPU board are octal buffer ICs, they just pass the 8 signals on, they just beef them up for transmission across longer trace runs, or to allowing it to drive more downstream logic, called the "fan out" load. To rule out issues with 9H being the cause of the messy signal I replaced it, this tidied things up a bit more, but didn't cure the issue.
The signal exiting on pin 18 should be the same as the signal entering on pin 2, which is the /HALT signal generated by the 74ls74 at 1H.
This is a flip flop IC which was held in reset by the /VGRST signal on pin 10 which is logic low. With this low the output will never change, but it should be a sensible logic level at least. The /VGRST signal comes from our friend 1P again, on a different buffer, exiting on pin 3, which should be passing the signal it gets in at pin 17, out on pin 3, just beefed up. Pin 17 had a healthy looking signal (from the CPU board), but pin 3 was low, worse than that in fact it was shorted to ground. Bingo - that's the fault, now to find where it actually is.
/VGRST fans out to a number of ICs on the Vector board and the body-count on that signal line was impressive.
1H 74LS74 pin 10 Page 13A Halt Flag Section BAD
5L 74LS175 pin 1 Page 14B RBG Output Section BAD
3B 74LS174 pin 1 Page 13B State Machine Section BAD
8N 74 LS164 pin 9 page 14B Z Intensity OK but retired
5E 74LS273 pin 1 Page 14B DAC Reference Section OK but retired
The actual culprit was the very last chip I got to
6L 74LS175 pin 1 shorted to ground!
With all those ICs replaced, and a new 74LS244 at both ends of the inter-board conversation the board would now come out of reset on power up, but I still had the blinking AVG LED issue
So I started to poke around the vector section to see what was running and what wasn't. The state clock was running, the halt flag was not set (i.e. good) but the Vector timer wasn't running, as the Go signal needs to be high on pins 10 and 7, currently low.
Go is the output 3 of an OR gate on LS32 at 2E
All are Low - Go will go high if either or both VCTR and CNTR are high.
VCTR comes off Q (pin 10) of 74ls109 at 2F
CNTR comes of Q (Pin 6) of same 109 at 2F
So I ended up tracking back through the logic that generates those signals.
1E 74LS02 tested ok on comparator
2F 74LS109 tested ok on comparator
2E 74LS32 tested ok on comparator but doesn't make sense on scope
3D 74LS42 looked rough, replaced, no change.
3E 74S02 comparator complained about pin 4 and pin 10 but as I was comparing an S family IC to an LS type I couldn't really trust it.
1F 74LS27 tested ok on comparator
And I ended up here - the 74LS157s at 4C whose outputs were either stuck, shorted, or weak. Pin 12 (an output) was stuck high, which should drive an address pin on the 82S129 PROM at 4B.
With any signal line you have the question of whether the driving IC has lost the ability to drive the line or whether the downstream IC has a jammed input pin.
All outputs on the PROM looked bad too, pin 1 tied high, and pins 3 and 4 appear floating but there are flickers on the scope which look identical, not surprising as pins 3 and 4 were shorted together, they shouldn't even be connected.
The suspects for this are either the 74LS157s, a very common IC, the PCB tracks, or worse case scenario the custom Atari PROM itself.
Once the 74LS157s were removed 4C tested as bad, but pins 3 and 4 on the PROM were still shorted, so off comes the PROM, and the board short is gone.
The slight charring under these is normal, as they run very hot, less surprising was that pins 3 and 4 on the PROM were still shorted together. Sadly though, this PROM aint a PROM any more, and I need to find a replacement.
PROMs are very high speed (for the era) small capacity ROMs but sadly are single-use devices, as programming them involves blowing internal fuses to set the bit pattern required. Once these are programmed they can't be erased and used again, which makes buying these as new-old-stock a nightmare. Online sellers rarely check whether they are blank (they probably don't have the tools as only the very high end modern programmers will deal with these) or they don't know or care that they can't be reprogrammed. My last batch of 20 were all in mint condition, but had been programmed for something else, so were useless and went in the bin.
Half the problem is you either need a multi-thousand dollar modern programmer that can handle these, or an age appropriate programmer from the era, which would have been multi thousands of dollars at the time. In my case its a DataIO 29B with a Unipak 2 module that I picked up boxed and faulty on eBay some years back.
My very last blank PROM in stock turned out to be the right type, and this one had been waiting since August 1984 to be used.
With two new 74LS157s and the PROM installed, the Vector system finally lit up again, and I was back to the original fault from literally months beforehand, an active but wonky X output and silence on the Y output.
While these rolling failures are annoying, it is best they happen now. This board probably hasn't seen power for ten or twenty years,so I'd expect there to be a surge of failures as everything half-dead finally lets go.
For now I was back to poking around in the Y-Axis out section.
I'd been looking at the TL082 at 7D before, but everything was completely silent there. I'd proved the AM6012 DAC was probably ok, by swapping the X and Y DAC over without moving the fault, which left the TL082 at 7D or the LF13201 quad analogue switch at 7E
The simplest option was to remove the TL082 at 7D to see what effect fragmenting the circuit had, I fitted a temporary socket so I could swap in a new op-amp IC, but with it completely removed (leaving an empty socket) the input signal at pin 6 lit up, so I had something coming in at least. I also have the same signal at pin position 7 and pad 1, which points to the quad switch at 7E being faulty. The only explanation for this is that both the circuit paths for Inverted and Non-Inverted Y output are switched together, so the signals cancel each other out, leaving silence on the final output.
The invert or not-invert selection should be controlled by the /InvertY signal, which is pulled high by default, via the pull-up resistor R113 which connects to the 5v rail. This signal goes to the enable pin 1 of the gate across pins 3 and 2, while an inverted version (due to an in path LS04 inverter gate on 6K) goes to the switch control pin 16, which controls whether the path between 14 and 15 is conducting.
If either the CMOS switch IC is bad, or the pin 1-2 gate on the LS04 is bad then it's possible that the switch is conducting on both these gates, which would feed an inverted signal back to the start of the circuit to squash the incoming signal. The LS04 looked fine on the scope, and the switch gates had signal bleed-through noise, on the inputs and outputs...
... regardless of what logic state the control pins were - a strong suggestion that the IC is knackered.
So it came off the board...
...and as these are really weird archaic devices the only option for spares was online, so I ordered some on eBay, crossed my fingers, and put the board back on the shelf.
Four weeks later they arrived, and I dropped in a new/old HI3-201 IC at 7E and flicked the power on...
...and the missing Y output finally lit up.
The voltages were just as bad as the X-out, so unsuitable to hook up to my monitor yet, but with my scope set to XY mode I could finally get an image of sorts.
This is a somewhat mangled attempt at the text that appears during attract mode, either the scrolling text or the high score table. It is badly offset on the X axis, and no attempt to centre it on the scope gave an image that made much sense.
So I swapped around the AM6012s to see if I could prove the originals as bad. It turns out the non-original AM6012 on the board was bad, while the bashed up ceramic IC was still working. It seemed safer to replace both with a matched pair.
With a new 6012 DAC at in the X section...
...the centering of the screen came good, as did the image.
It's progress but the voltages on the outputs were still way outside of the safe ranges, and worse than before. The DC reading had improved but I was still getting over 7 volts when measuring AC. This AC is the deflection range and can be seen on the screen by the fact the graphics are fairly small relative to the spread of artefacts on the screen, out to the extremities, these are the spikes that overdrive deflection boards. It is possible this is the fault that killed the monitor in the first place.
Tracking this issue down proved to be hugely time consuming, as I was looking in the wrong place, tracing back from video output section and all the way into the vector logic looking for the signals that were causing the video output to swing so far on both the X and the Y. As the issue was affecting both the X and the Y, it seemed logical that it would be a single fault that affects both, rather than two identical faults in two separate sections. I went through the entire DAC Reference and Bipolar Current Source circuit as a fault or instability here could impact the magnitude of the signals coming out of both the AM6012s.
I followed this back through another set of op-amps into the logic that generated the VCTR signal, and to the 74LS109 at 2F. This tested fine, and it's input signals tracked deep back into the vector PCB logic that was most likely working fine, as I had an actual image. All the information I could find on Vector board troubleshooting pointed to output voltage issues stemming from the final stage op-amps and the DACs on the Vector board. After multiple attempts I had exhausted every avenue bar the DAC08 IC at 6D...
.... which I couldn't test. It looked like this chip had been removed in the past, as the solder work wasn't original. It had the same date code as the other DAC08 on board so it had been put back on, I suspect this was someone else on the same path as me, many moons ago.
Again these are archaic ICs that required shipping from overseas, so I ordered a few from eBay China, desoldered the old one and waited again.
When they finally arrived I dropped one in and flicked the switch, fairly confident this would be the final fix, but no.
No change at all, voltages still screwy and the image still lost in a sea of crap.
The only option here was to stop looking where it wasn't, and it didn't seem to be anywhere on the Vector PCB, which only left the CPU board as the holder of the fault. I had originally proven that the CPU board worked with my Vector board, but that was a couple of months ago by this point and this board has shown a habit of developing new faults while it waits for the postman to bring me parts from China.
I knew I had a degenerating mathbox error on this main board, so I started there. A quick scoot around the instruction PROMs didn't really give me much of a clue, with all the input and output signals looking clean. These PROMs contain the instructions which feed the binary maths logic that handles wire-frame enemies, plus the star field which is just a load of lines so short they are just dots.
As you can get good clues by pulling ROMs out and seeing what changes I tried that, and found with any of the PROMs removed the fault cleared up, probably because this stops the mathbox from working.
Either way, without a full set of PROMs the output voltages on the X and Y outs were completely normal. So I had a killer mathbox fault on the CPU board, not a killer fault on the vector PCB. The retrace lines here are normal as I didn't have the Z blanking connected to the scope.
I knew I had divider errors from the prior test I started at the divisor stage just inland from the difference latch.
The logic here is that the first test that this board failed is checking for the result of 15 pulses going to the LS74 at 6R according to Atari's doco. The board can't count these pulses but it is looking for the right number to be shifted into the latches at 4M and 5M after the 15 stages of the cycle, which would then be available to the CPU on the data bus. The number it found wasn't what it was expecting, so the adder section seemed like a good place to start. The 15 pulses are the carry bits (C16) from the end of the adder chain which should come out of the last of the LS83 adders ICs at 5N pin 14 - except it doesn't, as pin 15 was floating, and all the other outputs were stuck either high or low.
...and tested bad off board.
My programmer actually doesn't support LS83s as their pinout is bizarre, but the LS283 is the same IC following the more modern pinout standards of the rest of the 74 series with respect to where the power and ground pins are placed. So I use a home-made adaptor to test 74LS83 as 74LS283s.
With a new one installed (well kinda new, new old stock from 1979) the spikes around the image was gone, and the voltages were back in the normal range, which meant I could finally risk powering it up in my cabinet.
Err - ok, not what I was expecting, bright green and it looks like the Z blanking isn't working, as retrace lines are being drawn. On a Vector monitor the beam is moved around the screen to draw each line individually, and the board should turn the beam off while the point is moved from the end of one line, to the start of where the next one to be drawn starts. If that isn't working you get everything joined up.
With the board back on the bench I moved onto the colour output stages and poked the scope at the colour outputs.
Unsurprising the green signal was fully on at the test-point, blue was 0v and red was a buzzing thin line which looked like the right data, just at the wrong logic level. At the collector of the 3 2N3094 transistors Q4, Q5 & Q6 the input signal was fine, and the section has the 12v power supply in all the right places, but the signals at the emitter pins were where the faults started. So each of them came off the board, and all tested as bad.
The green transistor tested as a 25 ohm resistor, pretty close to a dead short.
The red and the blue tested as dual diode packages, or blown transistors.
I suspect this section took a hit from the dying Amplifone monitor in it's own cabinet, but as they are just 2N3904 signal transistors they are easily replaced, even Jaycar still sell this type. All 3 were replaced from a set salvaged from an old pokie machine board.
Which restored the colours, kinda.
Now we have colour, but it looked like the Z-blanking on blue was still bad and the colour intensity is wrong in the red and the yellow, in fact it looked like the issue was the blue signal isn't quite lining up with what is being drawn. The actual fault is pretty clear now I look at this screen with the benefit of hindsight, but I went off on a long wild-goose chase, based on a fairly logical assumption, which turned out to be wrong.
I suspected I still had two issues here, the CPU board was OK on my AVG board, suggesting I've got a colour intensity and or Z-blanking fault on this vector PCB, plus I still have another mathbox error on the CPU board.
The Z-blanking is correct for the red and the green channel as there are no interconnecting lines in those colours, and I have a blue signal.
From the 3 dead transistors it's clearing something exciting happened upstream in the original monitor, so I needed to suspect everything in the final stage as it is possible the transistors let something through. Next inland is the 7407, which looked ok on the scope, but I just replaced it.
It tested fine off board and a replacement didn't change anything. Normally I put original parts back, but in this case it had been close to violence so it was retired.
The other signal inland is the Z REF signal which comes out of the TL082 op-amp at 9F, this is a dual op-amp that is dedicated to the Z intensity, it doesn't seem to be doing anything much on the scope, which may be normal if all it does is set a stable reference, but it would look much the same if completely dead.
Of more concern was that the outputs on the 74LS273 at 6F are struggling, the inputs look clean, and STATCLK is running. There is no output on the DAC at 8Fs IO pins either, with pin 4 low.
Suspecting the DAC08 is bad, and it is tying the output pins of the ls273 (as that is a new chip, replaced during the de-rust replacement stages, while possible it is bad it's less likely) I removed the DAC, to see if that released things.
I fitted a socket so I could probe the empty pins and then easily install the DAC, but nothing changed, so I took the 74LS273 off the board and it also tested fine, I swapped it with another one from my stock to make 100% sure, only to find the board wouldn't boot when I tried to power it back up. In fact it would boot about one in ten attempts, but not into a stable state, as it would usually reset itself after a few seconds.
The only component that could do this in the DAC section I was poking when it died, was the 74LS273, as it has access to the system bus, so I checked for solder bridges (none) and then removed it again. Leaving it off the board should let the board boot if the fault is there, as all it does is latch data from the main bus, based on the /STATCLK signal timing, but it didn't change anything. So something else had died, and it was unrelated to what I'd been doing at the time it died.
There's a simple way to partially check which board is the problem here, as the CPU board can run solo. The three test LEDs will go out if the board passes the self test, and if they stay off then the board is running, otherwise the watchdog would catch it, reboot and cause the LEDs to come back on again. In my case the LEDs start on, go off as the test passes, then come back on after 5-6 seconds, so the CPU board has a new fault, as it boots, hangs and the watchdog barks.
I would always rather parts that are about to fail do so while I have it on the bench, rather than a day after the owner gets the board back, but this was getting pretty tedious. To quickly rule out the RAM, ROM and CPU logic I wheeled the Fluke 9010 out again...
... and found all the ROM tests passed, but now the RAM tests failed - so I poked around the control signals, the output enable, write enable, and chip enable - /OE /WE and /CE
Both /OE and /WE were active, but /CE was high. The /CE pin controls whether the chip is enabled, and it is active low, as it is stuck high the RAM is disabled, while the board is trying to use it. The /CE pin is fed with a signal called /RAM on the schematic, which comes from the 74LS139 at 2J...
...which is based on 3 input signals into the LS139, the /E (enable) from the 74LS138 at 0B/C...
...and two address lines, AB11 and AB12 that come straight from the main 6809e CPU.
The /E signal is held high, with regular attempts to go low but it never makes it...
...so the suspects here would either be the 74LS138 that has lost the ability to drive the line, or a failed 74LS139 that is jamming the line. My money was on the 139 as the 138 was working enough to correctly select all the ROMs during the individual ROM tests that just passed. So I removed the LS139, and it tested fine off-board, but a new one dropped in restored the boards ability to boot again.
I moved on to fix the Mathbox issue thinking it may be involved in the blue retrace issue, not very likely, but I'd need to fix it at some point anyway, but instead of getting the Mathbox error report, I was now getting a BAD MATHBOX READY LINE error. Never seen that before.
It's not clear from the schematic what line this actually refers to, but the troubleshooting guide suggests this can be caused when the mathbox is given junk instructions, so I started back at the PROMs, swapping in a known good set again, which surprisingly cleared the issue, at least this new fault was a quick one. Subsequent swapping back and forth showed that the 111 PROM at 7J was the culprit, sometimes it works, sometimes it doesn't, it was retired to the bin and one from my Star Wars spares collection went onto the board.
With the mathbox running again this got me back to the actual test results.
The Atari manual goes really deep on the mathbox tests, and the first test is still the one looking for the right number after 15 pulses or stages of a seed number through the adder system. It seems I was getting 14 pulses, rather than 15 at the 74LS109 at 8P.
Instead of going deep I just went looking for more bad 74LS38s and quickly found 6M with it's output pin 2 stuck low.
With that replaced the stuck line lit up and all the mathbox errors cleared. With a 50% failure rate of the original 74LS83s, and one dying in a way that kills monitors, I retired the remaing pair of SA chips too.
All this had no impact on the blue signal being drawn incorrectly. So I went tracking back through the blanking logic, and finding nothing that looked wrong, I ended up back at the signal outputs again, and the blanking signals seemed to be completely normal there too, as far as I could tell.
Being a vector board the video output is unusual, in that the beam control (the X and Y voltages), the RBG signals, and the Z-blanking are all separate systems. The blanking circuit drags the RGB signals down to the ZREF voltage when the beam should be shut-off, in the time gap while the XY signals are moving from the end of one line drawn to the start of the next one, and I had all of the RGB channels as I had all the colours on the screen.
So the fact that Red and Green were blanked correctly and I couldn't find any issues in the Z=blanking system left only the the output circuit itself. The only remaining option I could see was an inability for a correct blanking signal to correctly squash the blue signal when required, which comes down to two resistors, R22 and R116. My thinking was that if the value relationship between them was incorrect you could get a situation where the beam was always off, or always on, even though the z-blanking signal was correct. This took me to the final fault, but not at all for the reason I thought.
R22 tested fine as a 470 ohm resistor, that sits between the drive transistor emitter and ground, but I couldn't get a reading on R116 at all. It should be a 100 Ohm, and I could read 100 Ohms for R114 and R115 on the Red and Green channels, but nothing on R116, completely open circuit.
With an open circuit R116 it physically disconnects the blue signal from the monitor, yet the monitor was drawing blue, fully turned-on glorious blue, all the time. So now I know that unlike raster monitors where you need at blue signal to draw blue, on vector monitors the RGB signals actually turn down the intensity, or turn off the colour entirely. If the colour "feed" is missing then the monitor will default to 100% on the missing olour channel, all the time, joining everything up. With Red and Green intensity being correctly driven I was just left with full-on blue, which explained why I had the retrace lines and why the other colours were slightly off, too much blue everywhere!
I'd also been measuring the colour signals at the colour test tabs, not at the edge connector, but they are downstream of an inductor and a the final resistor on each of the colour outputs, and it was the final stage resistor for the blue that was open circuit. Seems a daft place for Atari to put the test tabs if they aren't actually representative of the board output.
...and dropping in a salvaged one from the old pokie board...
...cured the last fault.
The game looks and plays perfectly!
The faulty stickers of shame were removed and it was finally handed over to the resident test pilot.
Fast forward two and a half weeks and the board hasn't missed a beat. It has been living in my cockpit cabinet getting some long runs in attract-mode and plenty of cold and warm starts, to see if anything else felt like failing. So far no more faults have appeared, so I'm calling this one fixed!