Midway Space Invaders Motherboard

Lurch666

Active member
Feedback
21 (100%)
Credits
4,142CR
When I was repairing my cosmic invaders the shifter used 74LS151s so I never needed to figure out the circuit that used the 25S10 chips.

Working on the sound on my midway gunfight the board developed a fault with the sifter and lines appeared through the moving graphics and the daughterboard does use 25S10 chips.

On mine the test showed a horizontal row of numbers instead of columns like yours and on mine only one row was bad telling me it was probably one of the 74LS175 chips at fault.Used my scope to figure out where the fault was and now it's sorted.

Anyway looking at the schematics I now have a better understanding of how this shifter circuit works even though the space invaders shifter is a little different from gunfight with your test showing possibly half the shifter failing I think it might be the 74LS175 at A5 as fault because if you are seeing no signal on some of the output pins (2,7,14 and 15) that would stop the 25S10 from performing properly.
 

funhouse

Active member
vacBacker
Feedback
3 (100%)
Credits
360CR
Got the 174 and 175s and tried the piggyback but no change. Still waiting on the 25S10 to try but I took some readings from the pins while it sits after test ROM:

SItruthtable.jpg


The numbers are volts and the P is 'pulsing'.

Will now look at the ICs and schematics to see if I can workout if anything is wrong!
 

funhouse

Active member
vacBacker
Feedback
3 (100%)
Credits
360CR
The 25S10 chips arrived and I had a go at piggybacking. Three of them made no difference but piggybacking on A4 I get something new.

newTesRomA4.jpg


Looks hopeful that A4 is the problem, will change it at the weekend.
 

RaveN

Active member
vacBacker
Feedback
1 (100%)
Credits
1,325CR
A bit of a long shot, but have you tried cleaning the edge connector? A lot of shifting errors are due to bad contacts between the mother/daughter cards.

The bit test on the braze kit runs thousands of patterns through the shifter hardware and it's possible that even though it fails it may not be noticeable on certain games unless something serious is wrong.
 

funhouse

Active member
vacBacker
Feedback
3 (100%)
Credits
360CR
Thanks. I did clean the edge connector to the daughterboard, but I didn't properly check the sockets or the solder connections. Will do that next.
 

funhouse

Active member
vacBacker
Feedback
3 (100%)
Credits
360CR
Cleaned the socket, pushed the pins back a bit and resoldered the connections. Same result on test but definitely worthwhile as some of the pins looked bent back.

Socketed new 25S10 at A4.

Progress:

shifterbit.jpg


(It also fails the Braze test).

From the Test Rom documentation:

"on
one line the first four bytes are the outputs of D4 and B4 and the
last four bytes are the outputs of C4 and A4. The top quarter of a
byte comes from C4 or D4, the bottom quarter comes from A4 or B4."


To start with it is a problem in the last four bytes so that says either C4 or A4.

Then I don't really know what they mean by top/bottom quarter of a byte?

I have already changed A4 and it improved considerably so I guess it must then be C4.

Edit. Just socketed C4 but the same 01 error remains and it also fails Braze.
smiley5.gif


funhouse2019-06-01 13:54:24
 

Lurch666

Active member
Feedback
21 (100%)
Credits
4,142CR
It's strange how only one of the bytes on the second line is incorrect.

If there was a faulty chip I would expect most of a line or column to have errors in it so I can't figure this one out.

have you tried piggybacking the other chips (A5,B5,C5,D5,B4 and D4) again since you have changed the two 25S10 chips?

If you have then I would be down to just guessing and swapping out chips till the problem went away unless someone else here knows how to pinpoint this problem.
 

funhouse

Active member
vacBacker
Feedback
3 (100%)
Credits
360CR
Yes, I couldn't work it out either (and I still don't understand the 'top/bottom quarter of a byte' idea).

I did piggyback again I think but will have another go to be sure. I also think I may email the test ROM author and ask him as he has freely given his email address.

Cheers.
 

Lurch666

Active member
Feedback
21 (100%)
Credits
4,142CR
So just tried to simulate the same error on my gunfight daughterboard by grounding the outputs of the 25S10 chips.

Could not reproduce this error as when one of the outputs is grounded the error is diagonal across the shifter test screen-I could never get it to just one digit being wrong but that could be down to the circuits being slightly different.

I'm thinking it could be a false positive caused by the speed of the chips.

Maybe try swapping the two 25S10s you have socketed around with each other to see if that makes a difference.

Have you tried running the game roms on your board and see what it looks like?
 

funhouse

Active member
vacBacker
Feedback
3 (100%)
Credits
360CR
Tried swapping the two 25S10s but still the same. Also did all the piggybacking too.

The documentation says: "The second line is the result of the test 0x02 offset 0, 1, ... 7 times ..."

So it is supposedly failing when shifting 0x02 the 7th time. What is different about that I wonder?

Edit. The documentation is a bit ambiguous I reckon and I'm still not sure about that top quarter of a byte do they mean 192 to 255 and the bottom 0 to 63?

So in Hex that would mean:

Top quarter of byte C0 to FF

Bottom quarter of byte 00 to 3F

smiley5.gif


I think I am going to change B4 next then D4 if required.

funhouse2019-06-02 15:33:31
 

funhouse

Active member
vacBacker
Feedback
3 (100%)
Credits
360CR
I've socketed A4, B4, C4 and A5 and no change.

I am starting to think that it was a known problem with these boards. Midway updated them and removed the 25S10s didn't it?

funhouse2019-06-04 13:27:12
 

Lurch666

Active member
Feedback
21 (100%)
Credits
4,142CR
They stopped using 25S10s because they were getting difficult to find even then.

This is really puzzling as in my tests if a line is stuck either high or low the shifter test shows multiple errors.I can't figure out why just ONE check is coming up incorrect.

Try the actual game roms and if everything looks OK it could be a false positive or you are just going to have to replace chips till the problem goes away.

Without understanding how the shifter works all I can suggest is A5,B5,C5,D5 and then even A3 to D3 as they are part of that logic as well.
 

funhouse

Active member
vacBacker
Feedback
3 (100%)
Credits
360CR
Thanks Lurch66, I have ordered some chips to test A3 to D3.

The test harness I have been using doesn't have sound, though I had heard sounds working out of the cab. However I now notice that two sounds aren't working (they are silent):

MISSL = MISSILE SOUND

UFO-H = INVADER HIT

Looking at the daughterboard schematic these come from the shifter circuit so I wonder if they give me a clue as to where to look?
 

Lurch666

Active member
Feedback
21 (100%)
Credits
4,142CR
I think UFO-H is when the ufo gets hit.

I don't think they are actually involved in the shifter.

While they use the same data lines if they were affecting the data than your shifter test would show more errors.

Check E4 pin 5 (missile) and E4 pin 10 (UFO hit).

(Unless it is the invader hit missing then the second one will be E5 pin12)

If you see a change when the sound effect should be heard then that part is OK and it's probably the amp chip failed (LM3900). This is a common failure.

The only other parts are the signals going into and out of E3 but these are clock signals so if they were missing I think again you would be seeing more errors.
 

funhouse

Active member
vacBacker
Feedback
3 (100%)
Credits
360CR
Have socketed new at E5 and F5 after reading about these failing often.

I also tried piggybacking on all the LM3900 and now with or without piggybacking I get a continuous repeating sound.

I've attached the sound of it I recorded on my phone:

https://www.ukvac.com/forum/data/uploads/3235/SpaceInvaderRepeatingNoise.zip

Which sound does that come from I wonder? Maybe I've partially revived it!?

These things are so temperamental aren't they!

funhouse2019-06-07 17:25:57
 

funhouse

Active member
vacBacker
Feedback
3 (100%)
Credits
360CR
As you guessed Lurch666 the latest test ROM looks like it has the 'UFO-hit' and the 'Invader-hit' swapped in error.

Using the schematics the sounds I am missing are the 'Missile Sound', the 'Saucer hit' and the 'Invader Hit'

'Missile Sound' E4 pin 5 goes high at the correct time. So does F4 pin 10.

'Invader Hit' E5 pin 12 goes high at the correct time. So does F5 pin 12.

'Saucer Hit' E4 pin 10 goes high at the correct time. So does F4 pin 12.

I replaced the LM3900 at M4 because I hoped as it was involved in the Missile and the Invader-hit it was a good choice but no change.

I guess P4 is the next to swap in the missile circuit but would M5 in the Invader-hit circuit have failed as well?

funhouse2019-06-17 17:14:15
 

Lurch666

Active member
Feedback
21 (100%)
Credits
4,142CR
The LM3900 are prone to die so I just socketed the lot of them.

It is possible that M5 has failed as it would explain why the hit sound is missing.

It could also other components that are causing the problem (like the noise generator) but it's best to start with the LM3900 as they are most likely the cause.

Have you checked the page on sound problems?

http://www.brentradio.com/SpaceInvadersSoundRepair.htm

Although I think it's got saucer sound being M5 incorrect as like you said it looks like the invader hit.

(could be wrong as I've forgotten what I did to fix my sounds).
 

funhouse

Active member
vacBacker
Feedback
3 (100%)
Credits
360CR
Thanks. Yes have looked at the Brentradio page on Sounds - useful.

I've now socketed new LM3900 at M4 and P4 which are the two in the Missile circuit. Still no change.

I couldn't see the pin go high at M4 pin 2 when F4 pin 10 goes high for the Missile. Do you think I should see anything after the effects of the C15 capacitor and R30 resistor and nearby D3 diode?
 
Top