Back in the day, around 1983, there was a corner stationary store that got a couple arcade games near the back door. I remember riding my bike to this store and spending lots of quarters. The games seemed to change with pretty good frequency. I remember playing Missile Command, Frogger, Donkey Kong Jr., Dig Dug, Elevator Action and many others at this place. The one I recall the most, however, was Atari's Star Wars. I don't think Star Wars was there any longer than any other game, but it left a strong impression.
On and off, I'd been looking for a Star Wars for a couple of years. When I picked up my DE Simpson's pinball, when I got there I found the guy also had an Atari Star Wars vid. But I was already picking up the pin and didn't want to over do it, so I declined. About two years later, the same guy came cross another Star Wars and offered it to me for a quick sale. The timing was terrible, however, since I was out of town. He ended up selling it to another guy before I was able to commit.
In 2011 I came across a DE Star Wars pin and picked it up. I did a bunch of repairs, it turned out nice. Ultimately, however, it didn't get a lot of play. In 2011 I decided to try and trade my DE Star Wars pin for an Atari Star Wars vid. I wasn't able to arrange a trade, but I found a guy who wanted to purchase the Star Wars pin and a different guy who had a Star Wars vid for sale. That's pretty much the same thing as a trade, except for a little addition effort.
I ended up with a nice Atari Star Wars. Some aspects are listed below
Cabinet and art are in great shape. Just a few dings in a couple of places
Empire Strikes Back kit installed, allowing the game to play either the original Star Wars or the Empire Strikes Back sequel.
I can list off several items.
It's a vector. Vector's are very unique in 2011
It was an amazing game for its time. 3D graphics! Imagine all the matrix math going on there
Game play, audio and video capture the Star Wars experience very well
Great yoke controller. It has amazing feel. Not many games have such a great controller
Looks great. Cabinet looks cool, side art is very attractive, front has unique plastic molding
In the late 1970's and early 1980's, several video arcade companies utilized vector monitors over the common, by today's standards, raster monitors. Vector monitors are capable of drawing a line from one point of the screen to any other point on the screen in a single fluid motion. The generated line is very smooth and is not composed of pixels. Vector games don't have pixels, rather they have smoothly draw lines. Games utilizing vector monitors would typically draw outlines of objects rather than objects with detailed interiors. Battlezone, Asteroids and Tempest are examples of classic vector games.
Atari's Star Wars had been mostly trouble free since I acquired it about 4 years ago. This changed the evening that several people were over and, at the end of the evening, I noticed Star Wars was playing blind. "Playing Bind" means that the game was running and playing sounds but no video was displayed.
When I took a look at the game, I quickly noticed that fuse F1 on the Amplifone deflection board was blown. I was hopeful the fuse was simply old and had reached the end of its useful life rather than some other (and more serious) problem. When I replaced the 3 Amp 250V Fast Blow fuse with a new one, the fuse immediately blew again when I powered on the game. So much for a simple fix.
The Amplifone deflection board is the monitor's controller. It manipulates the electron beams that draw the image on the monitor's phosphor. It controls the position of the beam along with the intensity of the component red, green and blue beams. The Atari Star Wars game logic boards output vector display signals that are received by the deflection board. When the deflection board receives these signals, it controls the monitor to display the requested images. If an Atari Star Wars is playing blind, the deflection board is a likely culprit.
Below is a picture of the Amplifone deflection board.
The Amplifone deflection circuit uses a push-pull design to send current to the monitor's yoke and move the electron beam. Fuse F1 is connected to the Y-axis push-pull transistor pair. Either Q6 or Q7 (but not both) allow current to flow from the +35VDC / -35VDC power supply and through F1. I figured that one or both of these transistors (Q6 2n3716 and Q7 2n3792) had gone bad. I ordered these transistors as well as their associated control transistors (Q4 MPSU57 and Q5 MPSU07). While waiting for the parts to arrive I tested the original transistors that drive the Y-axis and, while I didn't record the results, I believe both the 2n3716 and 2n3792 were bad as well as one of the MPSUx7 transistors.
A few days later the parts arrived, I replaced the transistors and tested it out. Fuse F1 blew up again. That was disappointing. Not only had F1 blown up, but I would find out that several of the newly replaced transistors also blew up.
Over the next 2 weeks or so, variations of this process repeated. Since transistors were blowing up, I needed to order more parts. Unfortunately these transistors are becoming harder to locate and are no longer inexpensive. The 2n37XX parts cost about $4 each and the MPSUx7 parts cost about $5 each. I ended up with 8 or 10 destroyed transistors before I repaired the deflection board. This was from 3 or 4 failed attempts.
I learned from my initial failures that one needs to be careful when repairing an Amplifone deflection board. Unlike many hardware failures that simply cause the game to not work and there is no harm in powering up the game to see if a repair was successful, powering on a partially repaired Amplifone deflection board can cause parts, even newly replaced parts, to break. After my multiple failures, I decided that a very methodical approachwas needed.
As part of my methodical approach I checked every part on the Y-axis deflection circuit. This involved checking capacitors, resistors, diodes and transistors. Checking many parts, such as capacitors, required required one leg from the circuit. Because of the circuit design, the transistors and a few of the resistors also needed to be removed from the circuit to properly test. Not surprisingly, I found parts in addition to the 2n37XX and MPSUx7 transistors that were bad. I maintained a list of all the Y=axis parts I checked and their tested results. The list is shown below.
|C1||0.1 uF||Tested 187 nF (0.187 uF)
Perhaps could have replaced.
|C2||0.0047 uF||Tested 5 nF (0.005 uF)|
|C3||0.47 uF||Tested 466 nF (0.466 uF)|
|C4||0.1 uF||Tested 106 nF (0.106 uF)|
|C5||0.1 uF||Tested 104 nF (0.104 uF)|
|C6||0.1 uF||Tested 98 nF (0.98 uF)|
Failed. Always open
|CR3||1N914||Passed diode test|
|CR4||1N914||Passed diode test|
|F1||3 Amp 250V
Failed testing using diode method
Failed testing using diode method
Failed testing using diode method
Failed testing using diode method
Failed testing using diode method
|R1||1.2 KOhm||Tested 1.06 KOhm|
|R10||4.7 KOhm||Tested 4.5 KOhm|
|R11||100 Ohm||Tested 100 Ohm|
|R12||15 Ohm||Tested 10.5 Ohm
Factory installed resistor markings show 10 Ohm (Brown Black Black Gold).
Schematic shows 15 Ohm. Did not replace because factory original still meets specification
|R13||3.3 Ohm||Tested 3.5 Ohm|
|R14||1.2 KOhm||Tested 1.176 KOhm|
|R2||1.6K Ohm||Tested 1.5 KOhm|
|R3||390 Ohm||Tested 393 Ohm|
|R4||2.7 KOhm||Tested 2.6 KOhm|
|R5||390 Ohm||Tested 387 Ohm|
|R6||1.5 Ohm||Tested 1.7 Ohm|
Inconsistent and out of range behavior during sweep test
Tested 7.7 Ohm / Looked burnt
|R9||91 Ohm||Tested 88 Ohm|
Not part of the Y-axis circuit but I found it was bad.
In addition to the Y-axis parts covered above, I replaced Q14, Q15, Q16 and Q17 on the X-axis circuit. I believe these parts were fine but decided to put new parts in while I was working on the board.
After methodically checking and replacing the bad parts, I installed the deflection board and powered up Atari's Star Wars. After 2 weeks of down time and various blown parts, Star Wars displayed a proper image! One of the first images from the repaired deflection board is shown below.
If you are repairing an Amplifone deflection board please learn from my mistakes. Approach this problem very methodically by checking all parts and replacing the bad ones before testing out the board. This will save you time and money.
Does Atari Star Wars have the best cabinet side art of all time? Perhaps. See for yourself below.
The machine's cabinet is cool all around, not just the side art. Below is a off-center picture of the game's front.
The Star Wars yoke controller is auto calibrating. If you move the cross hair to all 4 corners of the screen, the game does a pretty good job of determining where the center is. In addition to this auto calibration, Star Wars has a diagnostic screen that shows how the potentiometers are reading the controller's position.
I first realized that my Star Wars controller wasn't mechanically aligned correctly because the highlighted item in the diagnostic screen would always scroll down even when the yoke was neutral. This was also supported by the game's diagnostics. Below is a picture showing the neutral position.
You can see a line with an endpoint in the middle of 3 squares below "POT TEST". The endpoint that is not in the small square represents the current controller reading. According to the Star Wars manual, when aligned properly the line will be a small dot within the small square. I opened up the controller to make the necessary adjustments. The picture below shows how the control panel opens and reveals the gears for the X axis.
Below is a close up of the same gears.
You don't need to open up the control panel to access the gears for the Y axis, but I think it gives you some helpful flexibility. These gears are housed inside the "cube-like" part of the yoke that protrudes from the control panel. To access the Y axis you need to remove 4 security screws from the externally visible controller. The picture below shows the inside of the Y axis.
After adjusting the gears, I was able to get perfect calibration from the diagnostics! You can see the resulting diagnostics below. The dot returns to the center of the small square even after turning the controller away and letting it spring back to neutral.
To my surprise, even with this perfect manual calibration the game still required an auto calibration each time it is powered on! When powered on, the cross hair will end up in the position shown in the two pictures below.
After moving it to all four corners, it is perfectly centered. The image below shows the cross hair after auto calibration. I was surprised this step was necessary each time the game is powered on.
While several Star Wars owners indicated this behavior was normal, I always questioned why this would be the case. I eventually learned this behavior isn't normal! I'm guessing that Star Wars owners that need to calibrate on each power cycle also have a x2212 persistent memory issue.
My Star Wars had an issue with storing persistent settings (the x2212 access). See other parts of this page for information on that issue and the resolution. The key takeaway is that once I fixed the persistent setting issue, my Star Wars (and Empire Strikes Back) did store the calibration. On valid concern that suggested Star Wars might not store this calibration was that the number of writes to the persistent memory is limited. If the game wrote the calibration data each time it changed, that would consume the persistent memory lifespan quickly. However, having spent time looking at the Star Wars schematics I now know that Star Wars writes to the x2212 chip each time the game is powered off. Since the game is going to write to the x2212, it may as well write the calibration data.
Below is a picture of the cross-hair after power on and starting a Star Wars game. Below that is a picture of the initial cross hair for Empire Strikes Back.
About a year after getting Atari Star Wars, the yoke started acting funny when moving in the Y axis. The control was fine on the extremes, but would be jerky or unresponsive toward the center. This is a classic sign that the potentiometer used for the Y axis was wearing out. I didn't have any spares potentiometers around that matched the one used in the yoke so I tried out a temporary fix. I sprayed electrical lubricant/cleaner on the pot. I was happy that this fixed the problem, but I knew it was only a short term fix. Just a week later the problem started to return. It wasn't as bad as before, but certainly not good.
I ordered a replacement 5K Ohm potentiometer specifically for Star Wars. It is a "long lasting" pot with the correct shaft. I've read that the original pots were high quality Allen-Bradley brand, but these are impossible to find. The pot I removed from the yoke was not an Allen-Bradley so the original had apparently been replaced at some point. This isn't to surprising given the game is close to 30 years old (as I write this). Below is a picture of the bad pot I removed.
Immediately below is a picture of the new pot I purchased. It says "5K 0845 Extended Life PEC Made in Canada"
Finally, here is a picture of the new pot soldered onto the wires but not yet installed.
Shortly after getting my Star Wars, I realized it was having some problems keeping settings as well as high scores. I've simplified the story a little bit (just so you don't fall asleep). It's important to note that the Empire Strikes Back kit I have has two x2212 chips. One of these is used for the persistent Star Wars settings and the other is used for the persistent Empire Strikes Back settings. The problem my Star Wars game exhibited was that Star Wars would save high scores and settings as long as I never switched to Empire Strikes Back. Even if I always switched to ESB while the game was powered off, after playing ESB and switching back to Star Wars (with the power off), the Star Wars settings would be lost. Interestingly enough, however, running Star Wars doesn't seem to corrupt the ESB settings.
Note: It seems there are several variations on Star Wars PCBs. The ESB kit I have is great. Having the ability to play both Star Wars and Empire Strikes back is the perfect enhancement to a Star Wars game. While I had some trouble with the nonvolatile memory aspect of this kit, this should in no way be construed to say I don't like the ESB kit. I'd rather have a Star Wars without persistent settings than no ESB.
While it's not very hard at all, I've gotten good at removing the Star Wars board set. Below is a picture of the PCB that connects the 3 boards together. I'm thinking that gunk was once some sort of foam that kept the exposed pins from touching the inside of the metal PCB cage.
The picture below shows the Star Wars board set from the top.
With the sounds board removed, you can see the ESB kit. It's the daughter card at the bottom left of the picture below.
A close up of the ESB daughter card is shown below. This picture was taken after I removed the Star Wars x2212 chip and installed the Empire Strikes Back x2212 in its place. The Star Wars x2212 is the chip to the right of the solid white rectangle. The unpopulated spaces to the right of the SW x2212 is where the ESB x2212 goes.
The x2212 is a static ram chip with non-volatile storage. The chip acts like regular a 4x256 bit RAM with the added bonus that you can tell it to take the values in RAM and store them to the persistent nonvolatile storage. It acts like there is a shadow copy of the data. One set is in typical RAM and another set is in persistent storage. I learned a couple of interesting tidbits about the ESB kit, the x2212 chip and Star Wars will digging into this problem. I learned these from reading the "Schematic Package Supplement to Star Wars", using MAME and adding special diagnostic code to the x2212 logic, as well as examining the ESB daughter card.
Tidbit #1: The x2212 chip can write to persistent memory even when the chip select is not active
A chip select is voltage on a specific pin that tells the chip it should be alive. While alive it may drive data lines or perform other actions. The interesting aspect of the x2212 is that it can be told to store its current data into persistent memory even when the chip select is not active. The pin that controls writing to persistent memory is called "store".
Tidbit #2: The ESB daughter card connects all pins from both x2212 chips together except for the chip select
While the ESB kit has special logic to ensure that the chip select for Star Wars's x2212 is only active if the game is set to Star Wars mode, because all the other pins are tied together the x2212 store operation is always performed on BOTH x2212 chips. Put another way, whenever Star Wars writes to persistent memory, the ESB x2212 chip is also told to write to persistent memory (even though that game isn't being played).
The x2212 has a limited number of times a "store" can be performed. This means that the lifetime of the Star Wars x2212 is decreased while playing ESB and vice verse.
Tidbit #3: The Atari Hardware causes a x2212 store operation when you remove the power
Having a software background, I found this very interesting. Who typically thinks that hardware can do something when it is powered off? I really mean turning off the power switch or even pulling the AC plug from the wall! This is a pretty clever design. It means that individual actions that effect persistent data, such getting a top 3 high score in Star Wars, does not immediately consume a x2212 store cycle. Rather, in regular game play, the game never performs a store operation. The hardware triggers this when the game loses AC power. There is one exception. While in the diagnostics, performing the non-volatile memory test will cause the game to issue a store.
Because running Empire Strikes Back would corrupt my Star Wars x2212, I was suspicious that the behavior described in Tidbit #2 was causing me grief. While it is easy to jump to conclusions that writing to the Star Wars x2212 while playing Empire Strikes Back would clobber the Star Wars settings, this isn't obviously the case. When either Star Wars or Empire Strikes Back starts up, the software triggers the x2212 to recall from persistent memory into RAM. Since the recall operation is tied to both x2212 chips, both chips perform the action. Because of this, there shouldn't be any harm in telling Star Wars to "store" as it should store the data it previously recalled. Because the ESB kit ensures only the appropriate x2212 has chip select enabled, there isn't any way to modify the content of the Star Wars x2212 RAM while ESB is running.
But none the less, I wanted to rule this dual "store" out as being a problem. I designed a very simple circuit that ensures the Star Wars x2212 "store" only occurs when Star Wars is active. Similarly, this circuit ensures that an Empire Strikes Back x2212 "store" only occurs when ESB is running. If nothing else, this will help with the lifespan of the x2212 chips as only one perform a "store" at a time. The table below shows the logic I wanted. Keep in mind that "StarWars" is low when playing Star Wars. "StarWars" is high when playing ESB. Also, the x2212 store is triggered on low voltage. In short, we only want low voltage for StarWarsStore and ESBStore when that specific game is selected and the Store line is low.
This converts pretty easily into a circuit using just a 7400 (NAND) and a 7402 (NOR) chip.
Yes, that is a picture of my hand drawn circuit. In addition to Vcc (+5 Volts) and Ground, the circuit has two inputs and two outputs. The two inputs are "StarWars", which means Star Wars when low and ESB when high, and "store" (the x2212 store request). The outputs are simply "star wars store" and "empire strikes back store".
The "StarWars" input comes from pin 5 on the ESB kit's 7400. You can get +5 Volts and ground from many places, but I took +5 from pin 14 on the the same 7400 and ground from pin 7. The "Store" input comes from connection 9 of either of the x2212 locations --- but not the x2212 itself. You need to ensure the x2212s are NOT connected to the ESB kit PCB at pin 9 since we will drive this from "StarWarsStore" (or "ESBStore") and not "Store". Pin 9 on the Star Wars x2212 should be connected to "StarWarsStore" and pin 9 of the ESB x2212 should be connected to "ESBStore".
(BTW, I'm providing this information only to share what I did. It may not help your machine at all. Do it at your own risk and only if you know exactly what you are doing.)
Below is my home made daughter card for the ESB daughter card.
Below is the back of my daughter card.
In addition to my "store" enhancement above, I added a missing cap to my Star Wars board. The schematic indicates that C94 should be a 4.7 uF cap. For some reason, my Star Wars board didn't have this capacitor. Below is a picture of my board without the cap. This missing cap is marked with "C94" in the bottom center.
The picture below shows the newly installed cap. The night I went to find a cap locally, all I could find was a non-polarized one. This is fine... I'm told you can always use a non-polarized one in place of a polarized one.
I'm no electrical engineer, but this is my theory as to why the cap helps. The x2212 data sheet indicates that holding "recall" low while power is applied will prevent the chip from doing crazy things during the power up cycle. Adding a capacitor to the circuit changes the rate at which the voltage for the "recall" pin goes from 0v to 5v. Specifically, it makes the rate be slower. This means the chip stays in the "safe" mode longer. I can only guess that additional "safe" time is needed for some reason when the ESB kit is installed.
I added the simple circuit to save x2212 writes and, perhaps, help not clobber the other game's persistent settings
I added the missing cap
I've very pleased to say that both Star Wars and Empire Strikes Back are storing settings persistently and that switching between the two games does not clobber any persistent settings!
Above: Star Wars ARII board, Cage and RFI board
Above: Star Wars Cage with RFI board removed
Above: Star Wars Analog Vector Generator (AVG) board. The two pots in the center (black w/yellow) are the BIP adjustments.
My Atari Star Wars came with a reproduction HV board. It is pictured below.
My Star Wars has a modification kit that allows it to play either Star Wars or Empire Strikes Back.
When I got Star Wars, I searched the net for pictures showing what the diags screens look like. I wasn't able to find anything. So I decided to post pictures in case someone ever wanted to see what they look like.
These first two pictures below are not strictly diagnostics. They are the Star Wars audit and configuration screens. You need to go through these screens in order to access the diagnostics.
Below is the first diagnostic screen. I'm happy to report it didn't find any errors!
The screen pictured below shows the DIP switch settings (button with the hex numbers 10D and !0EF as well as the potentiometer readings from the yoke controller.
Star Wars does a lot of matrix math operations to create the 3D effects. There is a special test to ensure this math functionality is correct. Again, I'm happy that the picture below reports that all is well.
There are several other test screens, each of which is shown below.
For the BIP test below, note that my BIP offsets were not optimal. The 4 squares should be lined up right on top of each other.
This final test (below) is also showing that my BIP offsets are not optimal. The trapezoid should be a rectangle that fits within the square.
Have any comments, questions, or just want to say "Hi"? Drop me a note using "pins at this website". I'm being vague because of spam but you should be able to figure it out.