Updated 15/12/25

Here I have a Meteor PCB set by Hoei Intl. on the bench for testing and repair. It appears to be an almost exact copy of the Atari original. Although the layout appears virtually the same there is one notable difference; the Meteor circuit is divided into two halves connected by a pair of ribbon cables whereas Asteroids employs a larger single PCB.

The Meteor PCBs aren't in great condition with some corroded IC legs and messy traces of previous repairs. Checking for any damaged or broken components I have noticed one issue - there is a row of inductors with plastic housings near the edge connector and the outer ones have been pushed over breaking their connecting leads.

There don't appear to be any circuit diagrams available specifically for Meteor so I'll refer to the very comprehensive Asteroids documentation and note any differences encountered. In the circuit extract below the 13 x 100 uH (microHenry) inductors are shown in line with the input signals with capacitors to ground forming a low pass filter arrangement. There is another pair of inductors nearby on the PCB, in series with the X and Y vector outputs.

I'm not sure whether the input and output filtering was primarily intended to reduce glitching and switch bouncing of the controls, or to suppress any RF interference generated by the circuit to meet FCC standards - it may have been effective in both regards. Although the inductors specified for Asteroids were 100 uH the ones fitted to meteor are marked 102 which would correspond to 1000 uH (or 1 mH) as I have confirmed by measuring one out of circuit with my multimeter.

Fortunately the ones with the broken leads have just enough of a stub remaining to solder into the PCB so I have swapped these two to the X and Y output positions for the moment. I'll try and source some new replacements with my next parts order. So the next step is to begin making up a test lead, set up power supplies and check for circuit activity.

3/7/25

I'm setting up a Meteor arcade PCB set for testing on the bench, beginning with connections for power only. I'm not connecting a monitor as yet, in fact I don't have a vector monitor to work with this game so will just use a Cathode Ray Oscilloscope set to X-Y mode and the Z input (which is available on the rear panel of the CRO) will control the beam intensity / blanking of the vector signals.

There is a 2 x 22 way edge connector for power and signal connections which appears to be pin compatible with Asteroids, I'll trace and confirm each connection with my multimeter just to be certain. Initially I'm just wiring up the +5V logic supply using a basic arcade switchmode PSU, the only other power connection required is 36 Volts AC (centre tapped) which is then rectified and regulated on board to provide the remaining DC Voltages required by the circuit.

I also don't have a transformer with a 36V secondary handy so will substitute an equivaent DC Voltage to the point on the PCB after the rectifier stage.But first I'll test the 4 diodes of the bridge rectifier with my multimeter to confirm none are shorted or open circuit and the correct forward Voltage shows on my meter display for each diode. Having done that I'll connect my bench power supply to the inputs of the on-board regulators at the smoothing capacitors C87 and C86.

My bench power supply can manage plus and minus 20V DC at up to 3 Amps which should give enough headroom for the +/- 15V regulators to work correctly. I notice the circuit diagram indicates a nominal +22V at C87 and one would assume a similar negative amount at C86, also allowing for the forward Voltage drop across diodes and some AC ripple.

With the Voltages set on the bench power supply (+/-20V) and arcade PSU (+5V), powering on briefly to measure the regulated supplies on board the -15, +12 and the separate +5V supply (for the digital to analog converters) are present and correct but the +15V is missing. Power off, testing for a short to ground across the +15V rail does not reveal any problem so I suspect the 7815 regulator IC is most likely at fault.

That's a locally available part so after sourcing a couple of spares and replacing the IC in question, powering on once again the +15V rail is restored - but the zener diode regulated +8.2V rail now reads just over 10V so that diode must be open circuit. I don't have that value on hand so will try to source one locally and replace that component before powering on again.

23/8/25

I'm just getting back to this Meteor arcade PCB repair as I have been juggling a few works in progress of late. So far I have identified a faulty 7815 regulator IC and 8.2V Zener diode in the on board power supply regulator stage. Having replaced both of those all of the internal power supply rails are now present and correct. The next step will be to check for activity on the X and Y vector outputs in the unlikely event that the rest of the PCB is working correctly.

No joy there, both vector outputs show no sign of life when viewed with my oscilloscope so I'll check for activity further back, beginning with the signals at the 6502 CPU. If a board seems 'dead' with no output activity the usual starting point for troubleshooting is to check the CPU power, clock and reset lines followed by address, data and then control signals to see whether the CPU is active or idle, perhaps in a wait state or some sort of reset loop.

In this case there does seem to be some activity but the CPU reset input pin 40 is toggling so the CPU is repeatedly being reset, presumably by the watchdog timer. Many arcade PCBs especially those based on Atari designs include a watchdog timer to reset the CPU if the intended program flow is interrupted for whatever reason e.g. a power glitch, software bug or hardware issue.

If the cause of the issue was a one-off glitch then normal operation will automatically resume after reset but a more serious fault will cause the watchdog timer to reset the circuit repeatedly, as is happening in this instance. The Watchdog timer is exactly that, a counter which will cause a CPU reset after a certain delay. In normal operation the timer must be accessed by the CPU program at regular intervals to restart its count. If that does not occur the timer will reach its limit and trigger a CPU reset.

Interestingly the reset signal in this case is not repeating at a steady, regular pace but with varying intervals which suggests the program is operating to some extent and clearing the watchdog timer initially but stalls at some point allowing the watchdog timer to reset the CPU and the cycle then repeats. The most likely cause of a CPU which begins to run but ends up in a short reset loop would be a ROM or RAM fault so I'll try to verify those components out of circuit to begin with.

Fortunately both ROM and RAM are socketed on this PCB. The four MB8516 EPROMS are labelled ME1 to ME4, they're 2716 equivalents so can be read with my EPROM programmer and verified against known MAME ROM sets using an online ROMident utility. Having done that all 4 are exact matches to known ROM files, two are identical to Asteroids ROMs while the other two match up with an Asteroids clone called Aerolitos.

Incidentally, there is a known ROMset in MAME for Meteor by Hoei Intl. but that set is read from 8 x 1 k Byte ROMs whereas this PCB is fitted with 4 x 2k Byte EPROMs. The easiest way to directly compare this version to that known set would be to first divide each of the 2k Byte files in half. As there is a relevant match for the existing 2k Byte EPROMs there is no need to take that extra step, the EPROMs and their contents must be working correctly.

Next testing the 6 x 2114 static RAM ICs using my CPU / RAM tester, two of the vector RAM ICs fail the tests with data errors. Fortunately I still have a few spare 2114 ICs on hand so I'll place the 4 ICs which passed the RAM tests into the vector RAM positions and the two replacement ICs (which are also tested and working) into the CPU RAM positions on the PCB.

That done and powering on once again there is a definite improvement with the CPU reset line now remaining high after initial reset so the program seems to be running without crashing. Checking the vector outputs once again there is a repetitive short burst of signal on the X axis but just some noise on the Y vector output. At this stage there is no point viewing those signals in X-Y mode so I will trace back from the Y vector output to see if i can find a point where that signal goes missing.

5/10/25

Continuing with the fault tracing on the Hoei Meteor PCB set; to date I have checked and repaired the DC power supply regulator stages, replaced a couple of faulty 2114 RAM ICs and resoldered two inductors which had broken leads. When the circuit is powered on I am now seeing a repetitive, short burst of activity on the X vector output but only some low amplitude noise on the Y output.

Referring to the (Asteroids) circuit diagram once again, the Meteor output stages appear very similar and the good news is there does appear to be some activity at the output of the Digital to Analog Converter. Following that is a CMOS analog switch, in this instance a 4066 IC is used rather than the 4016B shown in the circuit diagram.

Checking its outputs there appears to be just some DC offset with no signal activity, it could be the IC itself which has failed or a poor connection due to severe corrosion of its pins. It's not just a bit of surface rust, the IC legs seem to be almost rusted through and the IC socket appears to be similarly affected. I have some 4066 ICs to hand so will replace this one as well as the IC socket.

The corresponding IC on the X vector output stage doesn't look much better so I will also replace that one in due course but for the sake of fault tracing will leave well emough alone for now. So, after replacing the 4066 IC in position B12 along with its socket the X and Y vector outputs are now both showing little bursts of activity. Switching the Oscilloscope display to X-Y mode there is some sort of image:

As yet I haven't connected or even checked the Z (intensity) signal from the PCB so the entire path of the X / Y outputs are visible including a bright centre spot, not only where valid characters are present. To avoid phosphor burn I only turned the brightness up briefly and just enough to make the traces visible for the above photo.

The image seems pretty indistinct so there may still be some graphics issues but the program appears to be running, in attract mode with the Asteroids - er, Meteors drifting around and some text message on screen. Switching back to 2 channel display the Y vector output now looks sharp, by comparison the X vector output appears low in amplitude as well as having a poor slew rate.

That could be an op-amp problem but I'll begin by replacing that second rusty 4066 IC and socket to see whether it resolves the issue: That done, the image now looks much better with some recognisable shapes and text. The next step will be to check and connect the PCBs Z output signal in order to see the displayed characters more clearly.

22/10/25

I'm making slow progress with the Hoei Meteor PCB repair; the game runs now in attract mode and I can see the vector graphics on my oscilloscope display in X-Y mode albeit not clearly as yet. To see the vector lines which make up the image without all of the intermediate traces (as the beam jumps from the completion of each line to the start of the next) I need to connect the PCBs Z axis (intensity) signal to the Z input on the rear panel of my oscilloscope.

The Z signal determines not only the blanking but also the relative intensity of the vectors which are to be displayed. Reading the Atari Asteroids circuit description, the blanking level of the Z Output is 0 Volts with +1 to +4 Volts for the range of intensity determined by the 4 bit SCALE signals, giving a possible 16 shades of grey (or green as viewed on the oscilloscope display).

So the Z output is effectively a positive video signal, with higher Voltages resulting in a higher display intensity. Checking my oscilloscope manual however a positive going signal on its Z input decreases intensity, to obtain a correct image I will need to invert the Z Out signal from the Meteor PCB.

To achieve that I can use my video inverting amplifier which I originally built and used for testing a Nintendo Space Firebird PCB set. Since then I have used it for other Nintendo games from Space Fever to Donkey Kong as all of these titles originally used a Sanyo monitor which required a negative going video signal. The amplifier has 3 identical channels to invert an RGB signal

In this case I only need a single channel to invert the monochrome Z signal from the Meteor PCB and the input termination is not required but I will leave the 75 Ohm terminations switched on for the other two inputs so they are not left floating. Having done that the vector image on my oscilloscope display is much improved but still not perfect.

The main problem now appears to be an instability in the Y axis causing a blurry ghosting or double image vertically on the oscilloscope display. It's most noticeable on the text characters, I think this is a fault in the Y channel of the Meteor PCB rather than a problem with the test setup or general power supply issue which would most likely affect both X and Y axes equally. So I'll need to check for noise on the PCBs Y axis output.

23/11/25

The Meteor PCB is running now, on the test bench and displaying its attract mode using my oscilloscope display in X-Y configuration as a vector monitor. The Z (blanking / intensity) signal is also working with the addition of an inverting amplifier to adapt the signal to the format of the oscilloscope's Z input. So far the display looked sharp in the horizontal axis but blurred in the vertical, presumably due to noise on the Y axis output from the PCB.

Switching the oscilloscope back to conventional 2 channel mode to compare the background noise of the X and Y channels, both signals look clean up to the final inductor which is in series with each output. The Y signal after the inductor shows an increased noise level probably due to a poor connection, high resistance or dry solder joint from the output side of the inductor to the circuit board.

Looking back, I had found a couple of inductors with broken leads on the control inputs to the board and (temporarily) swapped those to the X and Y outputs, soldering the short stubs which remained of the broken leads into the PCB pads. At the time I also ordered some replacements which have since arrived so, removing the old inductors from both X and Y channel outputs and replacing with new components we now have a nice looking vector display.

A quick test of the control inputs with a wire link to ground shows the game does appear to coin up and start with ship controls and firing also working. The next step will be to add connections to my test setup for joystick control and audio output, test the game functions and sounds to see whether all are working.

15/12/25

Although the Meteor PCB now runs there seem to be several issues yet to resolve. I have connected a joystick to the main control inputs; rotate left /right. thrust, fire and hyperspace which all work as expected however the PCB occasionally resets mid game or during its attract mode, presumably the program is crashing intermittently and the CPU is then reset by the watchdog timer.

I've also connected a small amplified speaker to the low level audio output from the PCB. The explosions can be clearly heard but the rest of the sounds are either completely missing or sound wrong. The firing sound is just a high pitched beep with no dynamic character and the thump sound which increases in tempo as the game progresses is barely audible as a faint click.

I'll return to those sound problems later as my priority is to resolve the program crashing issue which does seem to occur more frequently as the PCB warms up. It may be possible to localise the problem to a specific area on the PCB by selective heating and cooling and I should also look for any marginal signal levels around the CPU address and data busses.

To probe around the signals within the circuit while still observing the vector display output I'll need to press a second oscilloscope into service, to function as my vector monitor and return my usual test bench CRO to signal tracing duty. My test setup for this PCB set is looking pretty busy with 2 separate power supplies as well as additional sound amplifier and vector display. For more common raster video games my usual test bench RGB video monitor would suffice.

As I prepare to observe the address and data signals around the CPU I have discovered that just touching the IC can sometimes cause the program to crash and reset continuously, pressing lightly at either end of the 40 pin package seems to return it to normal operation. That is obviously caused by a poor connection, most likely the old IC socket with single-wipe contacts is to blame. I don't routinely replace IC sockets for no reason but this one definitely needs to go.

Removing the CPU in order to replace its socket I've just noticed another problem; the IC is marked as a MOS MPS6502 with date code 1280 (presumably 12th week, 1980) but a higher speed 6502A should be fitted here. It was obviously working to some extent but could definitely be responsible for the random crashing and resetting problem so also needs to be replaced with a working 6502A. The Asteroids circuit diagram specifically notes this detail:

The CPU on this PCB was almost certainly replaced at some point, there is a dot of white paint on it where it has been marked by a previous repairer so we can only guess whether that was to signify if the IC was tested or maybe used as a temporary replacement during a repair. Another suspicious detail is the IC has another marking and contradictory date code - KOREA 3679 on its underside so the markings on top which suggest it is a genuine MOS branded 6502 are probably fake.

To be continued...

Meteor / Asteroids specifications

Web Resources (External Links) -

Meteor - KLOV

Hamster's Online Rom identification

Home