Updated 23/8/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.

To be continued...

Meteor / Asteroids specifications

Web Resources (External Links) -

Meteor - KLOV

Hamster's Online Rom identification

Home