Updated 3/3/26

Here I have another PCB set on the bench for testing and repair. It's reportedly a Meteor, Asteroids clone by Hoei Intl. and appears to be a close copy of the Atari original. Although the layout appears very similar 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.

I haven't found any circuit diagrams specifically for Meteor as yet 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 - normally an L/C low pass filter arrangement would have the capacitors to ground on the load side following the series inductance - suggesting it is to filter incoming control signals but 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 that 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.

So, I have ordered a couple of replacement ICs; these ones were advertised as MOS 6502A CPUs and I chose a local online seller in the hope of obtaining genuine New Old Stock items. Although they were shipped locally and did arrive very quickly from order they unfortunately bear all of the telltale characteristics of fake, remarked ICs and were most likely sourced from disreputable suppliers overseas to be resold locally.

Both have different markings on their underside which appear to contradict the identical type number and date codes which have been printed on the top face of the ICs. The first is marked underneath as R6502F MEXICO 1327. Although it does run when installed on the PCB it exhibits the same random crashing behaviour of the previously fitted CPU and is most likely another 1MHz rated 6502 IC rather than the claimed 6502A specification.

The second IC is marked PHILIPPINES F5582 on its underside and does seem to run correctly without crashing when installed on the PCB. Although advertised as a MOS 6502A I suspect this one could be a later CMOS type 65C02 or equivalent which at least seems capable of running reliably at 1.5MHz. As it appears to work correctly in this instance I will leave it installed as it seems almost impossible to find a genuine replacement part with correct markings.

Moving on to the next problem, I have noticed the vector image is not stable but tends to jump slightly in the horizontal, X axis. As the CPU crashing issue now seems to be resolved this must be an unrelated fault around the area of the X axis Digital to Analog converter or analog output circuitry.

18/1/26

I have been making slow progress with the Meteor PCB set which has been stranded on my test bench for a very long time due to other higher priority commitments. Now it's time to complete the repair and move on to new projects. In the last installment the PCB was running without crashing and exhibiting only minor image instability along with some sound issues. Cue the secondary fault!

The 'secondary fault' is a common theme within my repair logs which usually describe my attempts to revive long abandoned PCBs with no known history, probably years of disuse and storage in less than ideal conditions. Once any initial symptoms are addressed and the PCB is seen to be working to some extent a secondary fault often occurs which sets us back to a non working condition. In these cases we must restart the fault tracing from the beginning.

Powering on now there is a random looking vector display with lines darting about and no recognisable pattern. The watchdog timer is once again resetting the CPU continuously. There is a test point on the PCB to disable the watchdog timer; when grounded the random pattern continues with little change - the CPU seems to be running but has derailed from its normal program flow at some point.

Before commencing any new fault tracing I will take a step back and verify the components which I have previously tested are still working. RAM and EPROMs still test OK when removed from the PCB as well as socketed logic ICs. The fault symptoms are unchanged when the CPU is swapped and there is no apparent change once the ICs are reinserted in their sockets so the problem seems to be more than a simple socket issue.

Rechecking the power supply rails reveals no problem in that area so I will do some signal tracing to see if there is any obvious reason why the watchdog timer is not being reset. The /WDCLR signal should become active when the CPU performs a write operation to address 3400 Hex. The data written to that address is unimportant, it is the signal generated within the address decoder which causes the watchdog counter to be reset.

24/2/26

The Meteor / Asteroids clone PCB repair has taken a backward step; what was previously running with video and controls working is now failing to start and stuck in some sort of reset loop. A quick probe around clock, address, data and control signals reveals no glaring errors so the new fault will require some more detailed analysis to resolve.

On one hand an intriguing problem with no obvious cause can be an interesting and rewarding challenge to unravel. On the other, I don't have much free time at the moment to immerse myself into the finer details of the circuit design - this could take a while. To begin with, the watchdog timer is repeatedly resetting the CPU. Its counter appears to be working but the /WDCLR signal which should be created by the program at regular intervals is inactive.

That could be due to a fault in the address decoding circuitry which is responsible for the memory-mapped I/O ports as well as the program and graphics RAM and ROM assignments. It could also be caused by an address or data error derailing the program flow to the extent that it does not process the instructions to output a signal to that address.

Before moving on to some actual checks and results I will attempt so summarise the workings of the address decoder circuit so feel free to skip this part if not wanting to know the theory behind the circuit design. And yes, I realise one can simply ask an AI chatbot to explain this circuit but bear in mind that AI works my regurgitating knowledge and content harvested from the internet - which has been shared by real people, some correct and sadly a great deal either flawed or misinterpreted.

Referring to the circuit excerpt above, the address is decoded in stages beginning with IC E4 at the top left of diagram. Its enable signal pin 15 is shown as either coming from CPU A15 or linked to ground, as the upper 32k address range is unused A15 is normally low (except at reset when the 6502CPU reads its reset vector address - more on that later). So this stage is always enabled and one of its outputs will be low depending on the address selected by the CPU.

Specifically address bits 13 and 14 determine the selection; when both low (address range 0000 to 1fff hex) the /ZPAGE signal is active low, selecting the program RAM. When A14 is low, A13 high (address 2000 to 3fff) the I/O addresses are enabled; if buffered address AB12 is low and buffered read/write R/WB signal high then inputs at address 2000 to 2fff can be read. AB12 high and R/WB low allows outputs within address range 3000 to 3fff to be written to.

A14 high, A13 low (address 4000 - 5fff) selects video memory. As both vector RAM and vector ROM are within this address range the address is further decoded within the video section of the circuit. Both A14 and A13 high (address 6000 - 7fff) selects the program ROM range which is further decoded by IC L3 into 2k Byte blocks /PROM2 (7800 - 7fff), /PROM1 (7000 - 77ff), /PROM0 (6800 - 6fff) and unused (6000 - 67ff). PROM2 is the 'boot' ROM, more on that to follow.

Getting back to the /WDCLR signal, that is further decoded by IC L6 from the output address range 3000 to 3fff. The 74LS42 is a BCD (binary coded decimal) 1 of 10 decoder but its D input pin 12 is being used here as an enable signal - when high the unused outputs 8 or 9 will be active, when low outputs 0 to 7 will be selected depending on the state of address lines A11, A10 and A9.

Each output of IC L6 then will correspond to a 512 Byte address range beginning at 3000 hex, 3200, 3400 etc. with output 2, pin 3 being /WDCLR. A write to any address from 3400 to 35ff hex would cause this output to be selected but for the purposes of programming it is defined as 3400 hex. In binary that is expressed as 0011 0100 0000 0000 i.e A15 low, A14 low, A13 high, A12 high, A11 low, A10 high and A9 low with address bits 8 to 0 determining the range from 3400 to 35ff Hex.

3/3/26

The Meteor PCB set has been on my test bench for eons and I seem to be light years away from getting it working once again. Its repair recently went off course from an almost working board with minor issues to 'Houston, we have a problem'. After re-testing memory components and checking signals around the CPU there are no obvious issues there so I'll look for clues in the area around the address decoder.

Referring back to the previous image which shows the address decoding circuitry, checking outputs of IC E4 reveals all address ranges; Program ROM, Vector RAM/ROM, I/O addresses and program RAM are active with the buffered CPU Read/Write signal also active. Checking the most obvious symptom, the lack of a /WDCLR signal from IC L6 reveals no activity on any of its ouputs 0 -7 due to its D input pin 12 remaining high.

That comes from the 74LS20, 4 input NAND gate in position E5. A quick check reveals all of its inputs are active so it seems that could be faulty. For its output to be low all 4 inputs must be simultaneously high though that is not straightforward to confirm with a 3 channel oscilloscope - I guess I could view 3 of the inputs while using the 4th as an external trigger source for the B timebase but it seems easier to remove and socket that IC position, try a replacement which I have to hand.

Although that doesn't get the PCB running there does seem to be a change with some activity on the outputs of IC L6 but still no repetitive /WDCLR signal. At this stage I'm not sure if that represents an improvement or just a different pattern of signals each time the board is powered on. It could be L6 has problems and its input has been loading the output of E5 so as a last resort I'll try removing, socketing and replacing the 74LS42 in position L6.

That makes no improvement and seems to confirm that this part of the circuit is not at fault, rather the program is not writing to these I/O ports as intended. In these instances a logic analyser could be used to great effect but without that resource my next option is to substitute a small test program for the program ROM to create some predictable activity which can be traced using an oscilloscope.

I should mention that Asteroids does have an inbuilt test program which uses audio tones to confirm RAM operation and vector output with simple test pattern also displaying DIP switch settings, unfortunately that does not seem to run correctly with no display output or noticeable sounds. The PCB does have sound issues so the RAM tests may be running but without any audible indication. So substituting a simple test program into the 'boot' ROM position seems the next best option.

I've written a number of test programs for various arcade PCBs, the most recent and most elaborate ones have been for Z80 or 8080 CPU basesd boards with raster display. My earliest attempt was a simple program loop for the 6502 CPU in Missile command so it should be straightforward to adapt that one to run on the Meteor / Asteroids clone PCB.

The program loop was intended to simply read each address from 0000 to 7fff in sequence, also writing to specific I/O addresses at regular intervals to clear the watchdog timer and output pulses to the Player 1 and 2 Start LEDs to signal activity. If the program runs correctly that will confirm the CPU is able to read from the boot ROM as well as write and read the loop count from the Zero page of RAM.

Using an oscilloscope it should be possible to confirm all address selections within the address decoder circuit become active in sequence each time the program loops around. The boot ROM and RAM select lines should show constant activity as these addresses contain the program instructions and loop count data. The adapted program will need to be loaded into a 2716 EPROM and fitted to the 'boot' PROM2 position in place of the original program EPROM ME1.

So having done that and placing the ME1.x04 test EPROM into the boot ROM position, powering on - the program does not run correctly and the watchdog timer resets the CPU repeatedly. This was not completely unexpected and confirms there is some fundamental issue causing the program to be misread, most likely an address or data signal integrity issue. At least with a short, simple program it should be easier to determine the exact point where it all goes wrong.

To be continued...

Meteor / Asteroids specifications

Web Resources (External Links) -

Meteor - KLOV

Hamster's Online Rom identification

Home