Microhard Ripof (Cinematronics RipOff clone) repair logs

[IZ8DWF]

Hi all,

this is the first post of a small series, documenting some repairs I made on two of these italian clones of Cinematronics' RipOff arcade.

First of all, a very good link to resources and documentation about the "CCPU", the TTL based 12 bits CPU used on Cinematronics/Vectorbeam arcades:

http://www.zonn.com/Cinematronics/index.htm

The logic PCB is identical to the Sky Fire (a clone of Tailgunner) that I described in a previous repair log, with of course the correct game EPROMs. The audio PCB is an almost identical clone of the Cinematronics' one. Checks and work required on the 2 audio PCB will be covered in a future post. The video PCB is also identical to the Sky Fire's one but it doesn't have the additional wire needed for the analog joystick A/D conversion since this game only requires button controls.

I'm actually starting from the last board fixed, that required somewhat less time than the first one.

The LED next to the power connector remaining always ON means the CPU is stuck. The watchdog counter resets the CPU at a rate of 38 Hz when it doesn't properly execute the instruction to restart the counter. Normally it isn't so easy to troubleshoot a CPU that's distributed on more than 40 different ICs, but with some tricks provided by the designer(s) of these boards we can get a good idea on what is working.

The first help comes from the jumper block at U13 (indicated as U14 in the schematics). These jumpers connect the ROM data path output to both the Instruction register T13 and the "instruction data" register S13. If we remove all the jumpers, the inputs of both the 74LS377 ICs will float and default to logic 1, the CPU in this case will execute continuosly the $FF instruction that corresponds to "LSLAB", a logical shift left of both accumulators A and B. It will go through all possible addresses before the watchdog resets it, so a lot can be tested in this situation. Of course, even before this step, we should check the power-on reset circuitry and the various clock generators.

This is a part of clock phases and enable generators, so the outputs of J4 F4 and F6 ICs are among the first things to check.

The output of F6 pin 12 doesn't look good, the high level is too low. A quick check with the HP current tracer shows no high current going or coming from this pin, so the 74LS27 IC at F6 is pulled, a socket is soldered in its place and a new LS27 IC installed, this resulted in good high/low levels, but the LED still remains ON all the time. So it's time to check what happens with the rom data path open. Of course the first thing to check is that the outputs of both T13 and S13 latches (see schematics above) stay high and all the "open inputs" are floating.

But on pin 6 of T13, the logic probe shows a logic low! Even this time the HP current tracer doesn't show any excessive current on this pin, but since this trace goes to a lot of other ICs, I decide to first cut pin 6 on T13 then check again if it remains low or jumps high as it's supposed to do with the jumpers at U13 removed. The cut pin 6 still showed logic low, so this 74LS377 must be faulty and it has been removed and socketed. Installing a new LS377 in its place shows that now pin 6 remains high as it should. Replacing the jumper block at U13 makes the LED go off! So now I connect the monitor cable to my vectorbeam to XYZ adapter.

The attract mode is running fine, however, all objects are displayed in the "bright" trace mode. These boards basically have only two brightness levels. The high level is used to blink the scores in attract mode and for some part of the enemies and players.

The high brightness trace mode is enabled by lowering pin 11 of F2. This 74LS259 IC is one 8 bit output port of the CCPU, the latch is addressed by the lower three bits of the instruction-data register and the output bit is the inverted LSB (bit 0) of the selected accumulator (either A or B). The other outputs of this latch are used to trigger the sounds and to read the coin counter. Indeed a quick check with the logic probe shows that pin 11 is always low. I decide at this point to connect the audio PCB and see what happens. All sounds work fine, I can credit the game and run one or two player games, all works flawlessly except the brightness stuck on high mode. It appears that the only possibility is a faulty 74LS259 at F2. However, this IC is always socketed on the boards I've seen, so a quick swap with a known good IC doesn't solve the problem! This is really puzzling, so I leave the F2 socket empty because it must be some downstream inputs shorted to ground, right? And no, with no 74LS259 installed at F2, the brightness level is instead correctly fixed at the "normal" level, so the inputs correctly default to high when open, that's even more strange. Of course without F2 no sounds are triggered and the coin counter is incorrectly read at its max value of 9. Re-installed the LS259 back on its socket and checked again the levels with the oscilloscope: sometimes now pin 1 would show an incorrect low level, it changed as I rocked the IC in its socket, so those old red sockets are hitting me again and again.. I decide then to change that socket but before I even do that,  at the next power-on the logic PCB dies again with the LED permanently ON. So we have a new fault...

So I started the troubleshooting again from the beginning: PSU voltage, reset, clocks, then removed the U13 jumper block again, this time the first check on the outputs of T13 and S13 passes (all high), so the next test in my checklist is the ROM address counters:

Outputs of P9, R9 and S9 must all toggle each at half the frequency of the previous, starting with pin 4 of S9 that must toggle at 1.66 MHz and ending with pin 12 of P9 that toggles at 800 Hz, however no faults found here. Other checks (very partial list):

- /SECONDARY must stay high (that selects the secondary accumulator to go on the accumulator output bus Kx)

- All A and B accumulator latch outputs must be low (ICs T4,S4,R4,P4,N4,M4)

- All outputs of the accumulator multiplexers to the common Kx bus must be low (ICs T2, R2, N2)

- All strobe pins (pin 15) of Ram/Data selectors N11, M11, L11 must stay low, pin 1 of all of these ICs must stay high, all data outputs of these three ICs must also stay high since they're passing the data register contents (all high).

However, all these check still gave no obvious faults. Rams IC are already socketed, so I swap all of them with known good ones, no changes... I try rocking the CPU state machine PROMs (C14, D14, E14, F14) and it seems that the LED flashes when poking D14 and E14. I decide to change all PROM sockets with good ones just to eliminate any risk of many intermittent faults. However, no changes, LED stuck ON. At this point, the options are either starting to force specific instructions at the data/instruction latches (instead of leaving the bus open, we can selectively ground the input lines to make it execute a specific opcode, however we are limited at the one byte instructions), or starting to write some custom test ROMs, or shotgunning all IC pins with the scope in search of an evident fault. I chose this last option, at least I want first to check the three ALUs 74LS181 (L6, M6, N6) and three magnitude comparators 74LS85 at L9, M9, N9. No obvious fault can be seen on the ALU's pins, however, with great luck, pin 9 of N9 looks like this:

Bingo! Clearly that's not a good level, however pin 9 of N9 is driven by pin 7 of M9:

Again, I check with the current tracer and no high current is flowing on pin 7 of M9 or pin 9 of N9, so it must be a bad driver at M9. Also, the 74LS85 at M9 has clearly rusted pins on both sides, while N9 looks much better. I pull M9, install a socket and a NOS 74LS85 and YES, that makes the LED go OFF, so I can reconnect the monitor. The attract mode runs again fine, however the brightness is still stuck at high level. Sounds work as before, I test one player game controls and player two game controls, I play a few games and all looks correct, only this strange brightness fault. I decide to pause a couple of days to reason about this strange fault. Since the solution wasn't so easy to find (but the cause was really in front of me all the time), I'll explain my troubleshooting approach on a future post on this thread.

Hope it helps.

Frank IZ8DWF

Edited October 28 by IZ8DWF
typos

[IZ8DWF]

Hi all,

this is the second part of a Ripof by microhard (a Cinematronics RipOff clone) repair. In the previous part I've described the steps to resurrect the logic PCB in a working state. Now it's stable and working since a few days. One problem remains: the vector's brightness is stuck in the high mode.

This is the relevant part of the brightness circuit on the logic PCB. The "intensify" output is enabled when drawing a visible vector and if the other output "bright" stays high, it makes a "low intensity" trace, if on the other hand, bright goes low, then a high intensity vector trace is drawn. This PCB is jumpered for "NORM" intensity option, I don't know what other games used the "VAR" option. The other boards I have (another Ripof and a Tailgunner clone) have the same "NORM" configuration. Gates J2 and J6 don't show any malfunction at least evident on a scope trace. The "bright" input directly depends on the "bright-*" signal, when bright-* is high, also bright is high, when bright-* is low, then bright follows the "intensify" signal, going low as soon as also intensify goes low (making the high brightness trace on the monitor).

The bright-* signal is generated when the CPU executes the OUT 6 instruction. The OUT n instructions transfers the LSB of accumulator A or B (depends on what accumulator is selected before executing the OUT n) at the selected output of the 74LS259 addressable latch at F2, however the accumulator bus LSB (K0) is negated by gate B6 before going to the F2 data input. A quick check with the oscilloscope and two probes on pins 12 and 13 of B6 shows that this inverter  gate is indeed working fine. The output latch on F2 is chosen by the value of the OUT n instruction, n can go from 0 to 7 and directly sets the D0,D1,D2 bits on the data-of-instruction latch. This output latch is used also to interface to the sound PCB (pins going to connector J4 in the schematics above) and to read the coin counter by toggling the output O5 on pin 10. All sounds are triggered fine, and the coin counter is also read correctly, so this excludes issues with the OUT instruction and with the data-instruction latch. During the initial investigation of this issue, the logic board failed again, but right before this failure I had identified a bad contact on F2 socket for pin 1. This F2 IC is almost always socketed from the factory as far as I could see on the boards I've got. I decided then to remove the old "red" socket and install a new one, the intermittent contact on pin 1 is now gone, but the problem remains, bright-* on pin 11 is always low. Of course the first thing I did before any other troubleshooting was to try a different 74LS259 but that didn't cure the problem.

All PROMs and code EPROMs of this board were initially dumped and compared to the dumps of the other boards and all dumps matched, so I can almost exclude a code error, unless some EPROM has just the right bit failing only on the real PCB and not when dumped on the eprom reader. So I decide to get the tailgunner EPROM set and see what happens when this set is transplanted on this logic PCB. Well, also tailgunner runs at always high brightness all the time, so this excludes any subtle code/eprom failure.

I also can pretty much exclude any intermittent error on the instruction-data latch and on the accumulators IC, any such error would never allow the game to run fine forever and never get any watchdog reset. So it's time for some more in-depth troubleshooting.

Jumper block at U13 if removed, disconnects the instruction and data-of-instruction latches from the EPROM data bus, so by grounding the correct pins on the data and instruction side, we can make the CPU execute always the same instruction. Now, OUT 6 is encoded as $96 or 10010110 in binary, since an open input will default to 1 (TTL inputs), by grounding the right 4 bits I can make the CPU executing OUT 6 forever (well it will be actually reset at 38 Hz rate, but that's not a problem now).

By removing also the IC at N2, I can also access the accumulator bit K0 (pin 12) and also toggle it from 1 to 0 (by grounding the wire I inserted in the socket), so I can control what state I want to write in the latch (that is continuously written at its address 6 now). I can see the correct bit state arriving at the latch input on pin 13, but pin 11 always remains low, which is again really puzzling. Making the instruction OUT 7 at this point is simple, just remove one grounded wire (the one on pin 14) of the U13 jumper block. Now I can control pin 12 (O7 output) of the latch. This time pin 12 follows correctly the data input, going low or high as I touch the K0 wire... Even stranger...

I decide to pull the IC at F2 and bend its pin 11 to leave it out of the socket, make the OUT 6 configuration again and this time pin 11 correctly toggles, but a quick inspection with the scope shows that the bright-* line, now undriven, is floating at 1.5-ish Volts, like any open TTL input do, and the LS32 gate that generates the bright signal correctly keeps its output at logic 1.... Does this make any sense?

At this point I can only suspect some strange short that happens only when pin 11 of F2 is inserted in its socket, which is something I can hardly believe because that socket was changed and I inspect very carefully all traces and pads when I replace ICs and sockets, since reworking twice the same IC area is really the last thing I want to do in a repair. However I decide to follow the trace going out of pin 11 of F2.

This capacitor is connected right to that trace, before it goes to the 74LS32 input next to it, the other side of the capacitor is at +5V. Of course I had noticed this strange capacitor at the first board inspection, there's no such capacitor on all the other boards I've seen. However I thought it was added as sort of bypass for noise, as it seemed always to sit between 5V and GND as any other bypass capacitors (yes, never measure, always follow the trace or at least measure at power OFF). Also the area were it's soldered, is really messy with all solder flux residues. I decide to remove the capacitor, clean carefully the whole area, inspect for any possible short and re-check what happens. I re-insert pin 11 of F2 in its socket place at this point. I still have the board jumpered for OUT 6 and now pin 11 of F2 correctly follow the input at pin 13!! What a failure really!

I remove all "diag" wires, re-insert the jumper block at U13, re-insert the IC at N2 and finally the vectors are drawn at the correct brightness!!!

Now two question remain: 1) why someone installed that capacitor and 2) what's the failure mode?

I think question n. 1 is the hardest to answer. I can only assume that at some point the monitor on this game had a contrast issue (too low? too high?) and they tried (in the very wrong way) to eliminate brightness differences. The monitor on these games is a clone of the first vectorbeam monitor design, it has no contrast control, just one brightness control.

Failure mode, I can only think about a combined input-output totem-pole latchup. First of all, capacitors to Vcc on any TTL circuit are a big NO-NO! Totem pole outputs are current-limited when driving a line high, but have no good current limit when driving a line low, so a capacitor to Vcc looks like a short circuit to Vcc when discharged, as soon a the output goes low, it gets an instant very high current rush that lasts probably not enough to permanently damage the low side of the totem pole, but can cause all sort of issues. The capacitor itself didn't have any evident fault when measured with my RLC meter, just a "regular" 10nF ceramic capacitor. I tried to connect a different 10nF capacitor momentarly (with a crocodile clip) from Vcc  to that bright-* line with the board already powered on and the effect is the opposite, all vectors are drawn in low brightness mode (so bright-* never goes fully low now). I won't do further experiments since the board is now working perfectly and is ready to be sent back to its owner. Also during digital electronic classes we were told frequently to never tie high a TTL input to Vcc directly, always use a resistor, direct connection to GND of an input is fine however.

Anyway, this logic PCB now ran for a few days without issues. I can call it fixed 🙂

On future posts on this threads I'll cover another logic PCB repair and some audio PCB issues.

Frank IZ8DWF

[needlebat]

Great read!

[IZ8DWF]

Hi all,

so this logic PCB, after the brightness fix only lived a couple of days. I connected it to its monitor instead of my adapter + 11" vector monitor, just to confirm everything was working fine before shipping back all the boards. However, I've noticed it would randomly draw vertical lines in some fixed parts of the attract mode (always in the same spot, always at the same time in the attract mode sequence). After a short time while I was still thinking about a possible fault location, the board died entirely with the LED permanently ON. It is important in this case to quickly power off everything if this happens with a monitor connected because in many cases there're still vector output commands that can result in "impossible" or too hard deflection and this can damage the monitor or at the very least trigger the overcurrent protection. However, as I heard the deflection coils starting to make a some nasty sounds and I've spotted the LED glowing, I've powered down everything and disconnected both the power supply and the DAC cable from the monitor. This will allow me to troubleshoot the logic board.

Since the symptom before the board died was erratic vectors drawn, I thought I'd start checking part of the vector output circuitry. In particular the "initial position" and the "line drawing" signals that enable the monitor to draw a vector between two points. In particular I've noticed that the "initial position" signal would continuously toggle on the bad board even if I removed the ROM data path jumpers, if you read the previous posts on this thread, it means the CPU will execute an LSLAB instruction continuously, this isn't supposed to enable the JK flip flop at G8 that in turns enables the initial position signal to be asserted. Checking on a good PCB indeed showed that the initial position signal never toggles when the U14 jumper block is removed. Checking all involved gates led me to think that the G8 74107 must be faulty (on this clone, most of the 74LS ICs are instead plain old 74 family ICs, so these are less reliable). So I've pulled the IC in position G8 and installed a socket. However, a good NOS 74LS107 wouldn't make the board start again and not even make the "initial position" signal stay permanently LOW when running on "LSLAB" loop. Then I moved my attention to the 74163 IC at F8 (again 74xxx in place of a 74LSxxx), it seemed that its CRY pin would remain always set, but that was a really bad assumption in this case, because you can see the CRY also goes to disable the counter as soon as it's asserted (through the NOT gate at B6). So as soon the CRY is asserted, the counter itself gets disabled and CRY is indeed remaining asserted until the counter is re-loaded by a new vector instruction (/VECTOR goes low). Anyway I pulled this 74163 but substituting it with a 74LS163 would not change anything. At this point I've started to make a lot of tests around the J and K inputs (pins 1 and 4) of G8 to understand why this flip flop would result in a set state at power on while on another board it would never result in the set state (it can't be only "luck" I think). I don't yet have an answer on this yet, but I ended also in removing the 74LS02 at H8 to help in the troubleshooting of this issue. Of course, the 74LS02 wasn't the problem as I confirmed by swapping it with another LS02. To this day, I don't know the answer for this different behaviour, but since trying to understand this proved to be really hard and wasn't leading me anywhere, I decided to change approach.

Let's pretend we know nothing about this particular logic PCB, so I've started 'from scratch', checked the power supply levels, checked for healthy clock signals, checked for a proper POWER ON signal, then I checked all the PROM checksums again, but all was ok. The next step is a checklist of things that must be verified when the jumper block at U14 is removed (check the previous posts on this thread). Also in this case, nothing bad was found. So, what to do now?

The /PROCEED signal is  a 38 Hz clock that resets the CPU if it fails to execute a watchdog reset instruction in time. By lifting the 1-16 jumper at D8 block, we can disable the periodic reset of the CPU. In this situation, often the instruction register is loaded with the instruction code that's misbehaving.

The instruction register is the LS377 at T13, indeed I had fixed outputs, by aligning the output levels from I7 to I0, the resulting hex number was 5B.

5B is a JLT instruction, it must execute a jump if the "less than" flag is set. Good information...

The CPU flags are latched by G10 and read through F10, a quick check with the logic probe showed that <ACC (less than) signal was asserted and could be read through F10, this means that the JLT instruction must generate a jump, in other words, a change of the address register to the content of the "J" register.

The J register is composed by P13 and R13 ICs and it's loaded sometimes before the execution of a jump instruction, it's not easy to check if it's loaded correctly, but I thought I should see the PARn signals toggling if I allowed the board to be reset, and that indeed happened, and I would also see toggling signals to the outputs of P13 and R13 if the board was allowed to be reset. Indeed all outputs BUT PIN 9 OF R13 were toggling, only pin 9 of R13 remained stuck high whether or not the board was reset or stuck in a loop... Changing the 74LS377 at R13 finally allowed the board to run again. Now, since I don't have a spare LS377, I borrowed one socketed 74LS377 from this same board, from the DAC output registers, so I currently don't know if the spurious vectors issue is solved. I need to wait for spare parts to arrive. However, the initial position signal still toggles with the U14 block removed.

I fear there're still problems with it, I'll know in the next days.

Frank IZ8DWF

[IZ8DWF]

Hi all,

this is another update on the (infinite?) repair of the Microhard Ripof (Cinematronic RipOff clone) logic PCB.

The 74LS377 ICs arrived this morning, so I could complete the DAC output register that donated a replacement 377 to the J register (see the previous fault above). The board started fine, so I could connect the monitor again and observe that the vectors still have some erratic behaviour but nothing like it was before, now some of the "aliens" have occasionally bad vectors like slightly out of position or with the wrong length and flickering back to the correct position during their movements. Most of the times they're drawn correctly however. This is a rather difficult fault to be diagnosed. However as I was starting checking the digital signals going to the monitor, the board died again with the famous "LED of death" permanently on. So I quickly powered everything off and disconnected the monitor *again*.

I went again back to the initial "unknown board" checklist: power supply OK, clocks OK, power on signal OK. Then I removed the U14 jumper block, that disconnects the ROM databus from the Instruction and Data-of-Instruction registers T13 and S13, I have a number of checks that can be done in this situation. One of these tests failed:

Pin 1 (select) of U11 and T11 multiplexers should toggle at 1.66 MHz, this is the odd/even ROM path multiplexer. The select signal is generated by the PROM at J14, probably just a copy or inverted copy of the A0 address. However, a quick inspection showed that the Vcc connection to this PROM was intermittent, rocking the IC in its socket would make the board start fine. Another red socket substituted with a more reliable one.

I'm now a bit afraid of really looking for the mysterious vector issue, seems like this board is not so happy to be working again.

Anyway, back to the bench.

Frank IZ8DWF

[IZ8DWF]

Hi all,

seems like I've also fixed the "flickering vectors" issue.

Notice how one alien has a "finger" on the front, that's the kind of faults I was seeing, momentarily jumping parts of the shapes, very fast but somehow happening always at the same place and time during the attract mode. Now usually this kind of faults are very difficult to diagnose, unless for example there's a fault in the RAM ICs (not the case here, I have plenty of 2101 spares lately). So we must look for other clues. The biggest clue to me is the fact that before the last time this board completely died, the erratic vectors would appear far apart of the aliens or number shapes, in almost unpopulated zones of the screen. Then after resurrecting the board, they were only "minor" deviations around the aliens. If you have read the previous posts in this thread, the only thing I needed to change to bring the board back from the dead state was substituting a bad 74LS377 part of the J(ump) register. This register isn't related to any vector output operation. BUT, I've borrowed the 74LS377 from a socketed one in the same board and that one was part of the X/Y output register. However, the borrowed 74LS377 of course works fine, otherwise the board wouldn't work at all. When I received the NOS 74LS377 I've ordered, I've just inserted one in the X/Y output register position.

The socket is this one, these black TI ones can be really problematic, much more than the red ones! The black TI sockets have springs contacting only the edges of the IC pins, not their sides. The red ones at least have contacts on the sides, not very "springy" but most of them work fine. However, I tried rocking the 74LS377 in this socket and the problem would go away or get momentarily worse... Lucky day! I've removed the old socket and installed a better one and no more erratic vectors! Now this problem is also worsened because the designers decided to not have any ground wires on the logic to monitor flat cable, the only common ground return between the monitor PCB and the logic board is through the power supply ground wires.

However, the board worked fine for a few games, I'll be testing it for another day or so. Fingers crossed.

Frank IZ8DWF