Jump to content

Womble

Veteran
  • Posts

    5,644
  • Joined

  • Last visited

  • Days Won

    5

Womble last won the day on December 7 2020

Womble had the most liked content!

Personal Information

  • State
    Victoria
  • Machines in your collection
    Atari Paperboy
    Atari Vindicators
    Atari Star Wars Cockpit
    LAI Generic JAMMA Cab

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Womble's Achievements

Pinball Wizard

Pinball Wizard (16/17)

  • Great Content Rare
  • Posting Machine Rare
  • First Post
  • Collaborator
  • Conversation Starter

Recent Badges

9.2k

Reputation

1

Community Answers

  1. I don't have any spare Star Wars PCBs, but if you post a photo of what's inside the cabinet I can tell you what you are missing. All up there are 7 PCBs in an original Star Wars, 3 for the game logic, 2 for the monitor and one ARIII for power and audio amps.
  2. Yes could be, but it is worth checking on the underside of the A board underneath the RAM (rear half of the board). It's quite common to find legs that have been bent together which can short out the address lines, which would give the effect you are seeing. It's also possible that touching pins is what kills the A custom ICs as, if the power pin is one of the bent ones it's easy to squirt 5 volts up the address lines, cooking the A-custom IC.
  3. 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 VCTR 9- 8-GO CNTR 10- 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. Desoldered it... ...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. Removing R116... ...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!
  4. I'm still rocking my Xytronics DIA60 station I bought when Dick Smiths were shutting down their useful section in around 2008. Its had 3 new heads, 30 new tips, 4 new glass collectors and 2 new elements. It's getting to be like Trigger's Broom. Parts are getting hard to source so the last parts refresh may be the last, was looking at a Hakko but seemed overkill.
  5. Probably not, but anything is possible. I'd poke a scope at the control pins of the ROM it is complaining about, and check whether the signals a /CE and /OE make sense.
  6. The ROM at 9D sits at 040000 in the address space, it’s paired with 9C with each providing 8 bits to the 16 bit value read, so either could be the cause of the error. I’d start by checking the socket and the state of the legs. It could be as simple as the pins needing a polish or the legs reformed.
  7. Price drop to $1000, have removed the Raspberry Pi and replaced with the original 19-in-1 PCB, because I could see MAME support featuring heavily in my future if I sold it as a MAME cab.
  8. If you have a dead board they are usually fixable.
  9. Hi Folks Another clear out under way, so reluctantly am looking to sell my custom PacMan JAMMA cab. This is a stunning home-made cabinet made to look as close to a 1980s Pac-Man cabinet as possible. Absolutely mint inside and out. The monitor has been upgraded to a JOMAC chassis giving the original CRT look and feel, rather than the flat dull look most LCD cabinets have. Monitor orientation is Horizontal, button layout would support 2 player 3 button games - which rules out Street Fighter / Mortal Kombat as they would need 6 per player. Includes a 19-in-1 PCB giving the following games Defender Stargate Bubbles Joust Robotron Blaster Splat Rally X Battle City Mario Bros New rally X Ghost’n Goblins Solomon’s Key Gradius Sky kid Ice Climber Super Mario Bros Do! RunRun Kick Rider Cab is wired for JAMMA so will play original boards. Dimensions are H=173cm D=87cm W=63cm Weight = heavy, its built like a tank, but is on wheels. AA Price would be $1000 Pickup from Newport 3015 y
  10. It could also be stuck inputs (tied high) on whatever is downstream, for hard to replace parts its worth ruling out everything else on the wire. It's best to find a seller who can sell you a programmed PROM as at least they will be aware that these are program-once devices. It's quite common to find them being sold as new-old-stock only to find they have actually been recovered from scrap boards and contain old data, which you can't erase. Also simpler to buy one programmed to order, as very few modern burners can deal with bipolar PROMs.
  11. That's just a coil, looks pretty normal. Check that the video ground connection between the PCB and the monitor is still good. Normally its far worse than this if it is missing but if it is hanging on by a thread you can get weird effects.
  12. Looks like the degauss loop is continuously energised. With the cabinet powered off and unplugged from the wall, take a look at the monitor chassis and find the posistor like in this picture. Next to it will be the degauss coil connector, a 2 pin plug that goes to a stiff wire loop strung around the back of the screen. Unplug that and make sure it is secured somewhere. Then power up and see if the screen shaking is cured. They can be quite stiff but it's just pushed onto two pins on the board. Be very careful your hand doesn't bash into the neck when it finally lets go or you risk trashing the tube.
  13. It's been a while since I have done a write up, mainly because they can take as long as the actual repair to put together, plus most aren't that interesting as write-ups, but this one was bit fruity - a Super Hang On PCB set from a cabinet restoration that another AAer is doing. I got some detailed photos of the boards condition beforehand as Sega boards can be riddled with track rot and unfixable, but this one was pretty mint. The usual suspect on Sega PCBs from this era is the big black Hitachi module in the master CPU socket, often a FD1094A, or a FD1089B in this case. These are the infamous suicide modules, a form of 1980s copy protection, to stop operators from upgrading to a newer game by burning a different set of EPROMs. While you could copy the ROMs from one game to another you'd need a decryption module with the right key in it to actually get the game to boot. Putting in a standard 68000 CPU was no better than putting in an FD1094 bock with the wrong encryption key, unless you had a way to decrypt the code. So the only way to get the latest game was to buy the official board from Sega as even if you could get hold of a spare module you'd still need the right encryption key and a way to load it into the module. Eventually the keys were reverse engineered (in the mid 1990s), but only very recently (2018) have the modules themselves been reverse engineered, to the extent that a dead FD1089 can be revived and reprogrammed with a new key. Check out the blog post by a guy called Arcade Hacker if you want to know what's inside these blocks, its hardcore stuff. Anyway, along with lots of photos of the boards there was also a spare 68000 CPU and a set of 4 EPROMs... ...which is a de-suicide kit for the board, EPROMs containing the unencrypted game code, and a normal 68000 CPU to replace the FD1089. As it looked like these had never been fitted the owner swapped them into the board along with the 68000, to check if that was the only problem, but the board was still dead. So it arrived on the bench for some TLC. The 1089B module has a lid that's easily unclipped, unlike the FD1094 which has a metal plate glued on, but both are much the same inside, space for 3 batteries but only ever one used, and wires disappearing into the block. In this one the date code on the battery was January 1987... … so no surprise it was dead, with volts so low that this would have died a long time ago. A few things to note on first inspection, firstly a lone 27c256 EPROM in at location at IC56. This doesn't belong on the board, if it did there would need to be another ROM in the empty socket to the right, at IC74. These 6 sockets are the program code for the main CPU and each of these ROMs contributes 8 bits of data towards the 16 bits on data bus, so only having one makes no sense. It does contain code that is part of the Super Hang-On ROM set, but I'm pretty sure it for another board configuration. In fact the MAME ROM set "SHANGON" is a bit of a tangle, with all sorts of files that don't make sense for this board. It wouldn't be the cause of a dead board as the program code doesn't address the space where those ROM sockets would sit in the address space. Some good news is the board doesn't have the hugely problematic TMM2063 64KB SRAMs anywhere, instead using ASAHI brand, which gave more hope this wasn't dead due to galloping RAM failures. There were also only 3 Fujitsu TTLs on the board, again very good news from a future reliability perspective. With low numbers of Fujitsu TTLs I opt to just replace them all, dead or not. The only other oddity was a single TTL IC in a socket at IC105, socketed TTL which is usually a sign that someone has been trying to fix the board before, but this was totally original, and a handy way to disable the watchdog circuit without resorting to desoldering one end of the zero ohm resistor R5. With my power and video harness hooked up I flicked the switch and yes it was pretty dead, but not totally, the board would give very brief flashes of white lines on the screen on a regular basis. (Yep the toyroom is a mess, it's always a mess) This is the sign of a Sega board trying to reboot itself due to the watchdog circuit firing. The watchdog is a timer circuit that the game code has to constantly reset every few milliseconds or it will pull the master reset line to logic low which will reset all the CPUs on board. It's there to allow the board to recover from a game crash without needing a human to power-cycle the entire cabinet, otherwise the game sit there in a wedged state unable to slurp up players coins. For a random crash this works well, but a faulty board it will sit there constantly resetting for ever. First step was to go over the board with the oscilloscope looking at the usual suspects, but aside from a dead 74LS109 in the road section I couldn't find anything by cruising around. There are two 74LS109 on the board and neither should break the boards ability to boot, you'd get weird faults like a static road if IC102 is bad, or a road that is totally missing if IC7 bad, but the main CPU doesn't care about either of those so that wasn't the main fault I was chasing. Super Hang-On uses the same CPU board as Outrun, just paired with a simpler video board, as the game doesn't have as much sprite or object data. For some reason I ended up with 6 Outrun board sets last year in quick succession so I got to know the CPU board quite well. One major difference between Outrun and Super Hang-On is that Outrun actually draws two roads, as there are two carriageways on screen that merge into one 6 lane highway, and then diverge at the end of the level where you get to choose the left or right track. Super Hang-On only draws one road, so the left half of the road logic on the board is unused, which is why there only one road ROM and an empty socket where the left road ROM would be on an Outrun board. By swapping the Super Hang-On CPU roms to the Outrun test ROMs, and plugging it into my own Outrun video board I could quickly test the CPU board, both CPU buses, all the bus transceivers and line drivers that the CPU board uses to talk to the graphics board, basically a tonne of stuff in one go. The board passed with flying colours, mostly. The ROAD LSB and MSB errors (least and most significant bit) were just from the fault I'd already found in the road section due to the dead 74LS109, but that wasn't the fault that had downed the board. Usually you find these boards will loads of RAM errors in the Main, Sub or Palette sections, but this was all clear. This suggested that the fault was on the video board, but converting an Outrun CPU PCB to Super Hang-On and pairing it with the Super Hang On video board got me a working Super Hang-On board set. So I had just proved that the CPU board was OK and that the video board was also OK but putting them back together gave me a dead board set again. Weird! I'd already eye-balled the pins in the board interconnects as squashed or missing pins can happen, but all the connector pins were there and with no signs of corrosion. It's possible but unlikely that the Outrun code somehow doesn't touch all the areas that Super Hang-On does, especially as Outrun is much more complex, so in theory gives the hardware more of a workout. Time to wheel out the big gun, the Fluke 9010A and a 68000 pod from 1982. This is pure overkill for a lot of board repair, but for a PCB that won't boot and gives no clues as to why it is the weapon of choice. On any PCB the CPU can only execute the instructions that it can fetch from the ROMs via the PCB tracks, sockets and control logic ICs. These instructions are all very low level operations like fetching a byte, or a word in the case of the 68000 and doing something with it, such as moving things in and out or registers, reading and writing from RAM, or doing mathematical operations on numbers that the instructions have pulled in. If these instructions make sense and keep up with the housekeeping, like maintaining the stack, then the CPU will just keep working away. If the instructions don't make sense then the CPU will just crash, and end up in a hung state unable to do anything, often with the address and data lines doing odd things. On a faulty board you probably only have a few milliseconds before the crash, and then a few milliseconds of quiet time before the watchdog restarts it all, leaving you with a twitching system thrashing around in a mess, very hard to work on when using a scope or logic probe. The CPU has no choice in what it will or won't do, it just ploughs blindly on, but the Fluke 9010a lets you become the CPU and have that free will. With that control you can perform all sorts of operations with no way to lock yourself out, and run a load of built in tests, if you know the memory map for the board. You can also ignore all the things which would stop a normal CPU in its tracks, like the the watchdog pulling the /RESET line low, or the other CPUs on the board asserting the /HALT line if they see a bus error. The main benefit is that you can test exactly what a real CPU would be able to do from the actual socket it would be sat in, proving everything from the socket itself all the way through the glue logic to the RAM and ROM blocks out in the memory space. On complex boards there is a tonne of logic that controls the addressing logic, read/write modes, and output enables, where any fault can easily brick a board and being able to validate all that quickly is really useful. So I pulled out the 9010A and the 68000 CPU interface pod and ran straight into the first problem, the 315-5195 Memory Mapper IC. The problem is that these boards are software configurable, and first thing the CPU does when the board boots is to run a short piece of code in ROM that write values into certain registers within the 315-5195 to configure the board. That sets up the board so the later stages of the program can access all the blocks of RAM and ROM that aren't connected before the mapper is programmed. So if a board is so bricked that it can't run any code then it can't configure itself to the point where you could use a Fluke 9010 to test the RAM and ROM areas that a CPU on a fully working board would see. While this looks like another bear-trap for bootleggers I suspect it was an attempt by Sega to future-proof the platform, potentially make software development easier, but mainly to make the PCBs far cheaper to manufacture. Basically it is an implementation of virtual memory, allowing the CPU to think it has it's full memory space available, but in fact the mapper IC is intercepting what the CPU asks for and silently diverts it off to the right hardware, leaving the CPU unaware that most of the memory space it thinks it has doesn't actually exist in hardware. The 68000 CPU has a whopping 16MB of address space defined by the 24 pins of the address bus. Games like Outrun and SHO don't need anywhere near that amount of space, but I suspect Sega had plans to use the platform for many more titles than the four that were ever actually released for it, with future games using up more space. On System 16B hardware the logical layout is apparently divided into multiple regions, and it is probably the same for the Outrun family of boards. Region 0 - Program ROM Region 1 and 2 can be used for additional program ROMs or other hardware. Region 3 - 68000 work RAM Region 4 - Text/tile RAM Region 5 - Object RAM Region 6 - Color RAM Region 7 - I/O area So, the memory mapper IC is hooked up to the full 24 address lines and the CPU control signals, and is used to convert it into 16 bit bus and a load of chip select lines which head off to the various slabs of RAM and ROM on the board. This seems like a lot of hard work but as a 24 bit bus needs 24 address lines, and 3 of whatever octal logic is used on the bus (e.g. transceivers, line drivers, latches) a 1/3 reduction in lines and chip count is a significant saving on PCB layout and parts costs. PCB production at the time was incredibly expensive so it would have been insane to physically layout 16MB of address space, especially for a game that used less than 2MB all up. Production costs, and additional PCB layers were certainly avoided but it presented me with a problem. I had no way to know if the board was able to configure the memory mapper before crashing and the watchdog jumping in, which also resets the mapper IC. In retrospect, knowing the actual fault I'd say the board probably was able to do this, and I probably could have used the Fluke to run the board as if it was a normal CPU and let it crash. I could probably have manually taken over leaving the mapper registers intact, but I would have had to have disabled the watchdog circuit on the board. At the time I had set the Fluke up to ignore the watchdog, but the mapper IC would have been reset instantly, losing the board config. I opted to go down the rabbit hole, to dig into how the mapper sets up the board. MAME would look like a logical place to start, but I'm not sure it bothers with emulating the mapper as it solves a hardware problem which doesn't exist when the whole thing is emulated in software, especially when you have a million times more RAM than a 68000 dream of in 1987, its simpler to give it 16MB of RAM and not worry about the big gaps. Hats off to Charles Macdonald who wrote the System 16 hardware notes, cmonkey and the late Zabanitu from Italy who did document their efforts on UKVAC to understand the mapper, and what it was actually doing, their notes on UKVAC were really useful in getting my head round it. Ultimately you can work out the bytes being written to the mapper IC (if you know where the mapper physically sits in the address space) by disassembling the 68K code and looking for the section which pumps data into the registers at the mapper location, before then branching off somewhere else, to start the actual game code. In the case of SHO the mapper initialisation code is this, which is a for/next loop counting down from 15 to 0, pumping the byte pairs held in ROM at 00153e and upwards into increasing register addresses starting at $ffff20, which is where the mapper sits on the SHO/Outrun CPU board. L_001000: moveq #$0, D0 ; clear D0 moveq #$f, D1 ; initialise the loop counter lea L_00153e.l, A0 ; address of data to send to mapper registers into A0 lea $ff20.w, A1 ; address of the memory mapper configuration registers .1: move.b (A0)+, D0 ; get a byte of data and post-increment data pointer move.w D0, (A1)+ ; move a word of data to mapper registers dbra D1, .1 ; loop L_00153e: dc.b 2,0 ; map $10000 to $3ffff to main cpu EPROMs dc.b $0d,$10 ; map $100000 to $11ffff to tile/text ram dc.b 0,$12 ; map $120000 to $12ffff to palette ram dc.b 0,$13 ; map $130000 to $13ffff to sprite ram dc.b 0,$14 ; map $140000 to $14ffff to unknown?? dc.b $0f,$20 ; map sub-cpu program to $200000 to $23ffff and maps work ram dc.b 0,0 ; does nothing dc.b 0,0 ; does nothing Machine code never was my thing, but working through this did give the clue I needed to break the mystery of why two working boards couldn't work together. I didn't need to set up the full memory mapper config, just to set it up enough to get access to the main system RAM. The first two passes through the loop above write h0002 to $FFFF20 and 0000 to $FFF22, which set up the board to have 128KB of ROM (at boot it only has 64KB) and it sets the base address of Region 0 to 00000. This seems to unlock the higher addressing where the RAM sits too. After poking those values in at those locations I could then read the full 128KB of ROM space and the RAM partially appeared in the memory map at 60000-63FFE and the NVRAM at addresses 64000-67FFE. I say partially because while the Fluke has built in test scripts for exercising RAM these instantly failed when I tried to run them on the RAM space, but writing a bit pattern to the first address location and reading it back showed what the fault actually was. When the SHO CPU board and the SHO video board were connected I only had an 8 working bits on the data bus, not the full 16. The fluke is great but the strobe on the vacuum fluorescent display makes it hard to photograph... Writing 5555 at memory location 0x60000 should allow me to read it back out again. But reading the data back from 0x60000 got me 5500 instead of 5555. With the CPU board powered up solo, with no video board I had a fully working 16 bit bus, and the RAMs on the top board passed their tests, but when the boards were connected again the lower byte of the pair was unusable. Pointing the scope at the RAM chips themselves showed the /WR (write enable) signal on pin 27 of IC115 and IC114 was held high, i.e. never write enabled. I could read them fine, but I couldn't ever get them to store any data, so the CPU would have had the same issue. When reading back the lower byte would always be zeros leading to the crash. The stuck write enable line for the lower RAMs is called LWR on the schematic, while the equivalent upper byte write signal UWR was working fine. With the Fluke set up to continually write to address 60000 I could track the issue to the edge connector (which is referenced by the signals going to page 7/7). The UWR on pin 13 was active... ...but LWR on pin 15 is stuck high... ... and when the boards were powered up separately the LWR was active again. Separating the boards while powered up is a great way to blow all the line driver ICs so I didn't even attempt that test. This initially looked like a fault on the video board jamming the LWR signal high, but is actually turned out to be a line driver problem on the CPU board. All ICs have a drive capacity, in terms of how many downstream gates their output pin is able to pull low. The default logic level is high, and a drive transistor in the output stage within an IC will conduct and pull that line down to ground via current limiting resistors to prevent a dead short and magic smoke. In this case the 74LS244 at IC123 on the CPU board had a weak output drive on pin 12 and didn't have the ability to sink the enough current to drive the LWR line when it had all the gates and pull-ups on the video board connected up. Piggy backing a new IC on top of the old one gave enough drive to the line, enabled the lower /WE line and the board could finally boot! It's alive! As to why this CPU board was happy with the Outrun PCB but not its own video board, it would come down to how many gates are hanging off the LWR line. I suspect that because Outrun has a much more complicated video board it has a buffer on this line to take over some of the load, so as far as the 74LS244 chip was concern Outrun is an easier board to drive on pin 12 than the SHO video board. So it looks like the video output is clean, and the sprite system appears to be working perfectly, but I have no road, corruption in the background, and a lot of pink. Oh and no sound at all. The 7th rule of board repair is to take any help the board offers, so if it has a test mode you should use it. The 8th rule is don't trust the 7th too much, as the built-in tests can be misleading and are usually far too quick to be doing any in-depth testing, but to get to this test menu I needed some inputs to mimic the accelerator pedal and some switches. The I/O on Sega boards of this era don't share the same power supply as the rest of the PCB, so you'll find them powered down unless you pick up power from the board and feed it into the right pins on the edge connector. Word is they did this to avoid the problem of people getting free credits using a piezo clicker to shock the board as the input section is only optically connected to the actual game system. With the power plumbed in, three wires off to a potentiometer robbed from a TV chassis and two wires for Test and Start... ... I could get into the test menu. By the way, the pinout of SHO is very different to Outrun, connecting an Outrun harness to SHO will cause no end of damage. The CRT check ruled out any issues with the video output stage as all three colour channels were there and white is white, not impacted by the pink... and the RAM test... ...shows all passes except these 4 road SRAMs. Not surprising really as the the dead 74LS109 I found earlier at IC7 will break the boards ability to see those. One trip to Jaycar later for a pair of 109s... ... and a piggy backed one lit up the disconnected outputs. Piggy backing doesn't always work, but Fujitsu TTLs often lose their internal connection to their output legs, so it is as if the on-board chip isn't there. As long as it isn't shorted on its other pins a piggy backed chip will take over the work with no issue. At nearly $5 each, Jaycar is pretty expensive per chip, as an online fake will set you back about 20cents, but you can't beat instant gratification and I still find it impressive that I can walk down the road and buy a spare part for a 1986 arcade machine. Now it looked a lot better, the pink is gone... the scene has the road now drawn, just very glitchy and with aspects of the road scattered around. Hard to catch on camera but you can see some pixels scattered either side of the central rider.. This quickly got worse, probably because the new 74ls109 was driving a section of the circuit that had been disabled up to this point. Repeating the ROM and RAM test now gave the results in bright green, with a white smear down the screen, and showed only 1 RAM as bad. But it kept changing its mind as to whether that was 21 or 39. The question now was whether 21 or 39 are actually bad, or whether it is something in the tangle of 244s that make up the road logic. During attract mode, or when showing the test menu the road circuit should be quiet, as no road is needed, this is controlled by two signals /ROAD, which is buffered into /REN (Road Enable), which drives the /G pin on about a dozen LS245s and a signal called /SRD which controls the direction of the multiplexers, and feeds an LS138 which controls the /WE pin determining whether the 4x SRAM is in read or write mode. Between these two they control whether the road cicruit is active, and whether the RAMs are being loaded with the stage data, or whether they are in output mode streaming the road data outwards. I suspect /SRD means speed road as it seems to determine how fast the road is rolling. When the road is deselected the whole system should be quiet, except D3 (pin 15) on IC21 there was a very rapid uniform signal... and on IC39 a slower signal that looked much more normal for a data output pin. As these two chips are supposed to be interleaved I'd suspect the faulty one is the noisy one i.e. IC21, and IC39 is resisting it. If the two signals clash while the board is trying to read from either then it would confuse the RAM test but it could be both or neither if that signal is coming from somewhere else, the only way to find out is to remove and test it off board. It failed! With the chip off the board I fired it up and went into the diagnostics again. The RAM/ROM test gave me this.. IC39 shows as bad, and IC21 shows good, despite IC21 being an empty location now, so the testing code has the RAM location labels reversed, which is not that uncommon as I doubt the coders ever saw what the final PCB looked like. The colours look much better, but unfortunately dull green was what Sega chose for the menu system, the sky blue is only temporary. With new 6116 SRAM fitted at IC21 it looks a lot better... ...but there is still some corruption in the road. It looks minor in a still photo but this was a flickering mess in real life. Suspecting there may be more RAM faults in the bank of four RAMs I hooked the Fluke up again and ran both the short and long tests on the road ram which is mapped between 0x68000-0x68FFF in the address space. Despite the fact the road is run by the sub CPU the memory space is shared so it is testable through the main CPU socket, and the road RAM passed even the very intensive long test. While I had the Fluke connected I ran through all the address spaces I could find, had some issues with the Sprite RAM but I suspect that was down to the sprite custom IC's taking control and doing their thing while I was trying to run my tests. Read writes kept flipping between pass and fail, but as the sprites are perfect there isn't a real fault here. I suspect there are some registers I could poke to disable the sprite custom IC access, but if there are I don't know them. Cool effect when long testing the text SRAM memory bank... All the RAM tests passed but the odd tearing in the road and the column over the splash screen was starting to become a permanent fixture. This looks suspiciously like the base road, when it inst stretched for perspective purposes, without the horizon applied and when the kerb isn't chopped up into the stripes. Especially as after the attract mode has shown a desert stage the column changes to the same colour as the sandy road. This took a while as the fault would come and go, but it never happened when the board has just been power cycled. The first splash screen was always perfect, and the issue would appear after the first attract mode cycle. To make it more annoying the fault would sometimes just vanish as soon as I touched a certain pin on an IC. I've met faults before where the additional load of the scope probe annoys the issue but this was rather too clean, but was ultimately pure coincidence. As the RAM tests fine even when the fault is present the issue has to be on the read-out section of the road system, that takes data out of the ROMs and passes it off to the video system for inclusion in the final image. For a while I was stepping around the road circuit waiting for the attract mode to cycle through and hoping that the fault would symptoms would be strong when it did, but I was chasing ghosts getting nowhere. The fault then suddenly vanished, for days, with both cold and warm restarts. I'd leave the board running for hours while I was working and I'd catch the odd flicker out of the corner of my eye but nothing I could catch with the scope. Thankfully the problem finally came back in a major way after 3 days, with the column of crap starting to appear as a few sparkly lines before gradually getting worse to the extent the stripe was nearly filled in fully. With the fault now present all the time the issue was easier to find with the scope... ...output pin 4 on the 74LS257 multiplexer at IC46 had turned to crap. Intermittent faults like this are pain, as when the image was fine this chip was behaving normally, and until it failed again there was no way to track it down. Shot-gunning a board this size isn't viable, plus desoldering on Sega boards is a bit of a fight sometimes, the power and ground planes are massive heat-sinks. With all the graphics bugs finally squashed the road finally looks mint! The last fault was the complete lack of sound. First port of call was the Z80 work RAM, the TMM2015 at IC87... ...whose outputs looked pretty horrific on the scope. Off it came... ..and surprisingly enough it passed an off-board test, and when fitted back to the board in a socket the sound was fine. Suspicious that the heat treatment from desoldering had revived the IC so it was retired and one from my stock went in. The last of the piggy-backed chips got replaced, the remaining two Fujitsu TTLs (the other 74ls109 and a 74S04 at IC85) were replaced with non-Fujitsu chips, and it spent a few days on soak test to ensure nothing else was about to die. All up the guilty culprits were these. With them now retired to the bin I'm calling the board fix complete!
×
×
  • Create New...