Missile command stuck in test mode (bad INT signal)

alessio

New member
Joined
Dec 15, 2006
Messages
9
Reaction score
0
Location
Cabiate, como, Italy
Missile command stuck in test mode (bad INT signal)

My MC always boots in test mode and the screen keeps flashing as one (or more) button is continously pressed.
Compairing my PCB with a working one I've found that INT signal has the right frequency but the active time is twice the expected. (let's say that in the working PCB INT is active for one mSec while mine is2 mSec)

INT is generated by the 7474 @F7, the flip flop inputs are ok thus is INTACK that is not working properly.
I've replaced the decoder @M5 but the problem persists.

Sincerely I don't know if the wrong INT signal is the cause of my problem or jit's ust a side effect.

What should I check?

Note:
- voltages are ok;
- new Rom sockets
- Roms checked
- rams socketed and replaced with brand new ones
- micro, pokey and prom are ok
- all the address decoding ICs have been replaced (N2, P2, M5, E8)
- all buffers checked and working
- test switch ok
- all switches are ok
 
Last edited:
My MC always boots in test mode and the screen keeps flashing as one (or more) button is continously pressed.
Compairing my PCB with a working one I've found that INT signal has the right frequency but the active time is twice the expected. (let's say that in the working PCB INT is active for one mSec while mine is2 mSec)

INT is generated by the 7474 @F7, the flip flop inputs are ok thus is INTACK that is not working properly.
I've replaced the decoder @M5 but the problem persists.

Sincerely I don't know if the wrong INT signal is the cause of my problem or jit's ust a side effect.

What should I check?

Note:
- voltages are ok;
- new Rom sockets
- Roms checked
- rams socketed and replaced with brand new ones
- micro, pokey and prom are ok
- all the address decoding ICs have been replaced (N2, P2, M5, E8)
- all buffers checked and working
- test switch ok
- all switches are ok

How about the clock?

ie the crystal and generated clock signal.
 
My MC always boots in test mode and the screen keeps flashing as one (or more) button is continously pressed. Compairing my PCB with a working one I've found that INT signal has the right frequency but the active time is twice the expected. (let's say that in the working PCB INT is active for one mSec while mine is2 mSec)

INT is generated by the 7474 @F7, the flip flop inputs are ok thus is INTACK that is not working properly.
I've replaced the decoder @M5 but the problem persists.

Sincerely I don't know if the wrong INT signal is the cause of my problem or jit's ust a side effect.

What should I check?

Note:
- voltages are ok;
- new Rom sockets
- Roms checked
- rams socketed and replaced with brand new ones
- micro, pokey and prom are ok
- all the address decoding ICs have been replaced (N2, P2, M5, E8)
- all buffers checked and working
- test switch ok
- all switches are ok

Wow, you've done a lot of work on this board.

It's not clear to me from your description: does it always boot to test mode, even if the test mode switch isn't closed?

A few thoughts:
- have you tried piggybacking a good '74 @ F7? Just because it's generating the INTs based on its inputs at the apparent proper frequency doesn't mean is doesn't have an issue with the preset input line.

- have you scoped the INTACK line, to see if it's the same on both PCBs?

- in the decoder section: don't neglect the "glue logic" that works in conjunction with the decoders. For example, take E8 (the decoder that produces INTACK). One of it's inputs comes out of a logic gate in C4--check that gate. Tracing upstream a little more, the inputs to that logic gate are /NIO and /WRITE. The former comes from up above, out of 1/4 of R5, which is in turn fed by an inverter @ K7. Take a peek at the inputs and outputs of all those logic gates; any could cause a problem with the proper decoding of an INTACK address write by the CPU.

You also have a good point: the whole INT thing could be a red herring. Videos and/or detailed descriptions of exactly what you get in both test mode and game mode (including audio) might be helpful.
 
Last edited:
It's not clear to me from your description: does it always boot to test mode, even if the test mode switch isn't closed?
It always boots in test mode ignoring the test switch status

- have you tried piggybacking a good '74 @ F7? Just because it's generating the INTs based on its inputs at the apparent proper frequency doesn't mean is doesn't have an issue with the preset input line.
IC @F7 has been replaced but still the /INT signal is wrong in the faulty pcb the signal width is almost twice the right one.
Checked the inputs (/INTACK, 32V and FLIP) and they seem to be the same.
I wrote "seems" because right now I have a huge doubt:
32V it's definetly correct (if it was fauty there would be other problems), the check I did on FLIP was just visual and it was "more less" equal to the working one.
Tomorrow I'll check the XOR @L3 and the inverter that negates 16V (@D3) hoping that a wrong clock in the FF @F7 implies a wrong width on the /INT signal.

- have you scoped the INTACK line, to see if it's the same on both PCBs?
Exactly the same waveform and frequency

- in the decoder section: don't neglect the "glue logic" that works in conjunction with the decoders. For example, take E8 (the decoder that produces INTACK). One of it's inputs comes out of a logic gate in C4--check that gate. Tracing upstream a little more, the inputs to that logic gate are /NIO and /WRITE. The former comes from up above, out of 1/4 of R5, which is in turn fed by an inverter @ K7. Take a peek at the inputs and outputs of all those logic gates; any could cause a problem with the proper decoding of an INTACK address write by the CPU.
Checked all the ICs chain that generates /NIO ans /WRITE, all IC are working at least the outputs are coherent with the inputs.
The only difference between the two boards is the frequency of some signal, i.e. SYNC output of the micro has a difference of, more less, 10% same story for READ /WRITE.
Another difference is in MADSEL, in the working PCB is possible to see some sort of "data packet" that toggles with a continuous data stream while in the faulty PCD I can see just the "data packet".
Still I don't know if this is the cause of the problem or just a side effect.
I'm guessing that something is wrong in syncing some signal but I don't know which one.


You also have a good point: the whole INT thing could be a red herring. Videos and/or detailed descriptions of exactly what you get in both test mode and game mode (including audio) might be helpful.

Here's my MC boot sequence:http://youtu.be/gny6NIEBqLA
 
It always boots in test mode ignoring the test switch status

OK, I'd maybe focus on this problem first. It is certainly A problem, even it it's not THE problem.

The branch between game mode and test mode happens VERY early on in the boot process, and yours is apparently taking the wrong branch, based on reading address 0x4900. If you've checked your button/switch wiring, and checked the PCB for damage, then this would seem to imply an issue with the LS244 @ M9 (or the address decoding that enables /IN1).
 
If you've checked your button/switch wiring, and checked the PCB for damage, then this would seem to imply an issue with the LS244 @ M9 (or the address decoding that enables /IN1).

The problem persists with the switches connector unplugged, I'll exclude broken traces at least on address bus since I've checked all the lines shared among the buffers.
Buffer @M9 works as expected.
/IN0, /IN1, /IN2 seem to be ok, at least they have same frequencies and waveforms of the working PCB.

The thing that is driving me crazy i the /INT signal.
Double checked the inputs (data, clock and preset) and are just like the same of the working pcb (as usual same frequency and waveform) but the output is different.
My only guess is that somehow /INTACK is not properly synced with 32V and FLIP so the input is sampled at wrong time causing a longer /INTACK.
Next week (I need a second probe) I'll try to trigger 32V on /INTACK and see what's wrong.

Obviously I've checked all the sync section and it works as expected.

P.S. Many thanks for the suggestions
 
Problem fixed

It works!

My major fault was to focus on /INT wrong signal, (due to a phase delay of /INTACK), as DarrenF suggested I've re-checked buffer @M9.

By triggering M9 output signals on /IN0 I've found that two lines (/FIRE2 and /TEST) were zero even if the inputs were high.

Replaced ls244 @M9 and now MC is back to life.
 
<feeling vindicated> ;)

Glad you got it working. Thanks for posting the follow-up with the resolution.
 
Back
Top Bottom