mecha
Well-known member
I don't have any of these games to fix but I'll pass along your video to @gamefixer
@mjenison is a true wizard
@mjenison is a true wizard
-
Please post all monitor technical topics in the Technical - Videogames - Monitors section, not in the General Help section.
My Sega G80 PCBs Repair Thread
- Thread starter mjenison
- Start date
OP
OP
mjenison
Well-known member
First repair with the new sound board test setup. @jkoolpe sent me a few boards to work on, one being a Battlestar sound board that he built by himself, but couldn't figure out why one of the sounds was missing.
Symptom: large explosion not working, all other sounds good (repro board)
Fortunately, there is a small explosion circuit right next to it mirroring it except for a few caps and resistors differences, so being able to trigger both sounds over and over allowed me to compare one for one what I should be seeing. For the 2N4903, I could touch the metal case with my logic probe to immediately verify the noise circuit was working. Nothing was coming out of U5, but it was socketed so I quickly swapped one of those hoping for an easy fix, but no joy. Noise circuit feeds right into U5, so must be a diode or resistor, or bad solder joint. Since this was hand soldered, I suspected maybe a bad solder joint not causing continuity, maybe a bad socket. Looking at the schematic, there should be continuity between Q3, R44, D4 and U5 pin 5, which should all connect.
Well, they didn't.
This repro board has an error. these two pad should be touching, connecting Q3 and D4 to R44 which has a trace to U5 pin 5.
I put in my own jumper, and the sound was restored.
Original:
version 2.0:
Symptom: large explosion not working, all other sounds good (repro board)
Fortunately, there is a small explosion circuit right next to it mirroring it except for a few caps and resistors differences, so being able to trigger both sounds over and over allowed me to compare one for one what I should be seeing. For the 2N4903, I could touch the metal case with my logic probe to immediately verify the noise circuit was working. Nothing was coming out of U5, but it was socketed so I quickly swapped one of those hoping for an easy fix, but no joy. Noise circuit feeds right into U5, so must be a diode or resistor, or bad solder joint. Since this was hand soldered, I suspected maybe a bad solder joint not causing continuity, maybe a bad socket. Looking at the schematic, there should be continuity between Q3, R44, D4 and U5 pin 5, which should all connect.
Well, they didn't.
This repro board has an error. these two pad should be touching, connecting Q3 and D4 to R44 which has a trace to U5 pin 5.
I put in my own jumper, and the sound was restored.
Original:
version 2.0:
Last edited:
OP
OP
mjenison
Well-known member
Sega G80 Speech boards use a similar setup of port messages, yet each speech board seems to require slightly different messaging to prepare the speech board.
After analyzing the port messages in MAME, I was able to put together a testing tool for speech boards as well.
Here's a demo of testing a Star Trek speech board. Reading a G80 reference faq from Al K from back in the day, I was able to also demo the "Sector Secured" speech sample that doesn't appear in the game.
I gotta get a quieter power supply. Maybe I could disable the fan
.
After analyzing the port messages in MAME, I was able to put together a testing tool for speech boards as well.
Here's a demo of testing a Star Trek speech board. Reading a G80 reference faq from Al K from back in the day, I was able to also demo the "Sector Secured" speech sample that doesn't appear in the game.
I gotta get a quieter power supply. Maybe I could disable the fan
.
Mike Rhinehart
Active member
How do we get that "sector secured" into the game?! That is awesome, Mark. Thanks for sharing.Sega G80 Speech boards use a similar setup of port messages, yet each speech board seems to require slightly different messaging to prepare the speech board.
After analyzing the port messages in MAME, I was able to put together a testing tool for speech boards as well.
Here's a demo of testing a Star Trek speech board. Reading a G80 reference faq from Al K from back in the day, I was able to also demo the "Sector Secured" speech sample that doesn't appear in the game.
I gotta get a quieter power supply. Maybe I could disable the fan
OP
OP
mjenison
Well-known member
It wouldn't be too hard to add. I'm speculating that they may have removed it in favor of reporting the small bonus / large bonus sounds that occur at the end of the rounds. Fitting it back in, spacing it out, and leaving enough gap before Spock announces the next level might have been another issue.
OP
OP
mjenison
Well-known member
And to complete the vector sound board trifecta...
The Universal Universal Sound board tester!
(yes, that was my cat meowing, not a new sound on the universal sound board).
A few neat things I learned working on this...
The boards are loaded with "code", which I understand to be mostly data tables, into the 6116 RAMS at start up and occasionally throughout the game. During this time, the board has garbage signals running around, cause static output. We talked about this earlier in the thread that they had a temporary "mute" circuit on the board so you didn't hear this screech when the game starts up, but as soon as the RAMS are loaded and the reset signal sent (output port 3F, value $7f), the board goes silent. Unfortunately, the Arduino isn't so instantaneous and I'm subjected to about a minute or two of screeching while the board loads. I cut that from the video for your own good. Fortunately, I have a volume nob on the audio amp.
Star Trek has a total of 3 different 6116 ram data; it actually swaps out the code for one of the 6116 RAMs during game play just for coin up, and high score music. Since these are very rarely used, it keeps the other two main chunks of code static during game play.
I was having trouble getting this to work. I couldn't tell if my writes were working correctly or not. So then I thought, maybe I could test reading first, which would allow me to validate if my writes were working. Well, how could I validate reads were working if I couldn't get writes to work? I thought about putting in some 6116 NVRAM adapter boards, putting the board in a real game, starting it up to load them, then take the board over to the bench. Except I didn't have any 6116 NVRAM adapter boards on hand. Then I thought, what if the data were already there? So, I burned two 2716s with the correct Star Trek data, bent out pins 21 and tied them to +5VDC to make two read-only RAMs, prepopulated with the correct data. Turns out, you can actually test the boards this way.
Anyway, that helped me get my reads working, which, in turn helped me figure out how to write to them, and I ended up with a nice validator routine for testing the 6116 rams, which, is kind of essential for getting these boards working anyway.
Not shown in the video, but I did go back and add the test for the Tac/Scan coin up sound, oddly missing from the Tac/Scan self-test.
Now I can finally pickup where I left off...working on Universal Sound boards.
The Universal Universal Sound board tester!
(yes, that was my cat meowing, not a new sound on the universal sound board).
A few neat things I learned working on this...
The boards are loaded with "code", which I understand to be mostly data tables, into the 6116 RAMS at start up and occasionally throughout the game. During this time, the board has garbage signals running around, cause static output. We talked about this earlier in the thread that they had a temporary "mute" circuit on the board so you didn't hear this screech when the game starts up, but as soon as the RAMS are loaded and the reset signal sent (output port 3F, value $7f), the board goes silent. Unfortunately, the Arduino isn't so instantaneous and I'm subjected to about a minute or two of screeching while the board loads. I cut that from the video for your own good. Fortunately, I have a volume nob on the audio amp.
Star Trek has a total of 3 different 6116 ram data; it actually swaps out the code for one of the 6116 RAMs during game play just for coin up, and high score music. Since these are very rarely used, it keeps the other two main chunks of code static during game play.
I was having trouble getting this to work. I couldn't tell if my writes were working correctly or not. So then I thought, maybe I could test reading first, which would allow me to validate if my writes were working. Well, how could I validate reads were working if I couldn't get writes to work? I thought about putting in some 6116 NVRAM adapter boards, putting the board in a real game, starting it up to load them, then take the board over to the bench. Except I didn't have any 6116 NVRAM adapter boards on hand. Then I thought, what if the data were already there? So, I burned two 2716s with the correct Star Trek data, bent out pins 21 and tied them to +5VDC to make two read-only RAMs, prepopulated with the correct data. Turns out, you can actually test the boards this way.
Anyway, that helped me get my reads working, which, in turn helped me figure out how to write to them, and I ended up with a nice validator routine for testing the 6116 rams, which, is kind of essential for getting these boards working anyway.
Not shown in the video, but I did go back and add the test for the Tac/Scan coin up sound, oddly missing from the Tac/Scan self-test.
Now I can finally pickup where I left off...working on Universal Sound boards.
joemagiera
Thread Manager
- Joined
- Mar 22, 2003
- Messages
- 6,187
- Reaction score
- 1,095
Pretty awesome work there. Nice job.
Need more cat sound effects. 
OP
OP
mjenison
Well-known member
Now with my new tester, I decided to revisit a few boards:
USB 4
-------
Symptoms: Static, low pulsing tone
Now that I know startup static means the board isn't starting up, either due to the processor or rams not working, the tester 6116 RAM testing comes in handy....
Retest with USB tester. RAMS aren't getting loaded. Flip flop at U38 is not flopping. Replace. No change. Look at 6 and 5 pins on U38 more closely. Pin 5 is not flopping. Find that pin 5 is actually grounded! Checking the circuit, it feeds a few 74LS157s and a 74LS245 which I didn't notice was on the bus somehow. I ask Grok which chip is likely shorted to ground; it says most likely it's the 74LS245. Replace U53. Replace. Rams now loading.
With good data, I can now probe each of the channels individually. Replaying the same sound over and over, I can test each AD7525 and TL082 pair. Find noise on U27 pin 15, but TL082 U20 not outputting on pin one. Lift resistor R42 to separate from circuit. Still no sound. Replace U20; Targeting returns. Testing shield hit is also bad. Check U28 pin 15; sound, but no sound on pin 1 of U21. Lift resistor U43 to confirm: no sound. Replace TL082 @U21. Shield hit returns. Red alert not working. Turns out manual is incorrect; Red alert is found on U13 and U12, driven by U42 pins 10 and 13. However, sound is not coming out of the TL082 @ U4. Lift resistor R13 to confirm: still no sound. Replace TL082 @U4. Fixed.
After validating sound on all pairs, connect all resistors. Still no sound on board. Sound getting to U1 but no output. Replace TL082 @U1. Sounds return. Test all Star Trek sounds: Enterprise Explosion and Starbase Hit have "Bong" sound. Test Tac/Scan mode: all sounds good except player ship roar missing.
Grab good working board to understand this issue, as this seems to be a common problem with a few of the boards from the past.
There should be white noise on U31 pin 12 and pin 15, same for U30 pin 12 and 15 on U30.
There was no white noise on U31 pin 12. After replacing most of the chips in that circuit, the final culprit was...a .01uf ceramic capacitor @ C25, which was drawing down
multiple chip inputs/outputs in the circuit.
The "Bong" is an issue in the U30/U31/U23 area. C25 is a film capacitor on most of the other USB boards I have. I may need to start replacing these as well.
Fix: Replace U53 (rams not loading), missing targeting (U20), missing shield hit (U21), missing red alert (U4), all sounds missing (U1), C25 (bong noise).
USB 4 took a few days; very frustrating one to track down.
USB 5
-------
Missing a chip at U42; don't have any spares at the moment, so passing on this until I come up with a parts board (USB 3 most likely candidate).
USB 6
-------
Another painful one...
Symptoms (retested): Missing sounds, static but can hear some sounds underneath
A lot of resistors were cut from previous testing. Replaced them so I could see where I was actually at again...
Lifting R9 removes the static, so it's coming out of the SB2 channel. All sounds from SB0 seem good.
Pressing on the board causes some inconsistent activity. Replace the processor socket and the 6116 RAM socket at U50 brings back stability.
I learned that I should probably work backwards, starting with the chip closest to R9. Instead, I worked from the furthest, prioritizing chips I had ample spares of (TL082). Replacing U5 and U6 did not help. The only other chips directly feeding R9 would be U15 and U16. Mapping the outputs against values from a known good board, it seemed like U15 had the most mismatches, so I replace it. No change. Replacing U16 finally removed the static overlay. All sounds returned, but the explosion sounds were breaking up.
Attempting to trace what is causing the explosion breakup in the circuit. I suspect it has something to do with the circuitry being fed by U43 pin 17, because targeting, which is driven by pins 10 and 13 of the same chip sounds fine. Probing around I find that if I touch the logic probe to the pins of U30 pin 1 while replaying the sound, the sound returns to normal. Replacing it resolves the breaking up noise.
Final fix: U30 (explosions breaking up), U16 (static overlaying SB2).
USB 4
-------
Symptoms: Static, low pulsing tone
Now that I know startup static means the board isn't starting up, either due to the processor or rams not working, the tester 6116 RAM testing comes in handy....
Retest with USB tester. RAMS aren't getting loaded. Flip flop at U38 is not flopping. Replace. No change. Look at 6 and 5 pins on U38 more closely. Pin 5 is not flopping. Find that pin 5 is actually grounded! Checking the circuit, it feeds a few 74LS157s and a 74LS245 which I didn't notice was on the bus somehow. I ask Grok which chip is likely shorted to ground; it says most likely it's the 74LS245. Replace U53. Replace. Rams now loading.
With good data, I can now probe each of the channels individually. Replaying the same sound over and over, I can test each AD7525 and TL082 pair. Find noise on U27 pin 15, but TL082 U20 not outputting on pin one. Lift resistor R42 to separate from circuit. Still no sound. Replace U20; Targeting returns. Testing shield hit is also bad. Check U28 pin 15; sound, but no sound on pin 1 of U21. Lift resistor U43 to confirm: no sound. Replace TL082 @U21. Shield hit returns. Red alert not working. Turns out manual is incorrect; Red alert is found on U13 and U12, driven by U42 pins 10 and 13. However, sound is not coming out of the TL082 @ U4. Lift resistor R13 to confirm: still no sound. Replace TL082 @U4. Fixed.
After validating sound on all pairs, connect all resistors. Still no sound on board. Sound getting to U1 but no output. Replace TL082 @U1. Sounds return. Test all Star Trek sounds: Enterprise Explosion and Starbase Hit have "Bong" sound. Test Tac/Scan mode: all sounds good except player ship roar missing.
Grab good working board to understand this issue, as this seems to be a common problem with a few of the boards from the past.
There should be white noise on U31 pin 12 and pin 15, same for U30 pin 12 and 15 on U30.
There was no white noise on U31 pin 12. After replacing most of the chips in that circuit, the final culprit was...a .01uf ceramic capacitor @ C25, which was drawing down
multiple chip inputs/outputs in the circuit.
The "Bong" is an issue in the U30/U31/U23 area. C25 is a film capacitor on most of the other USB boards I have. I may need to start replacing these as well.
Fix: Replace U53 (rams not loading), missing targeting (U20), missing shield hit (U21), missing red alert (U4), all sounds missing (U1), C25 (bong noise).
USB 4 took a few days; very frustrating one to track down.
USB 5
-------
Missing a chip at U42; don't have any spares at the moment, so passing on this until I come up with a parts board (USB 3 most likely candidate).
USB 6
-------
Another painful one...
Symptoms (retested): Missing sounds, static but can hear some sounds underneath
A lot of resistors were cut from previous testing. Replaced them so I could see where I was actually at again...
Lifting R9 removes the static, so it's coming out of the SB2 channel. All sounds from SB0 seem good.
Pressing on the board causes some inconsistent activity. Replace the processor socket and the 6116 RAM socket at U50 brings back stability.
I learned that I should probably work backwards, starting with the chip closest to R9. Instead, I worked from the furthest, prioritizing chips I had ample spares of (TL082). Replacing U5 and U6 did not help. The only other chips directly feeding R9 would be U15 and U16. Mapping the outputs against values from a known good board, it seemed like U15 had the most mismatches, so I replace it. No change. Replacing U16 finally removed the static overlay. All sounds returned, but the explosion sounds were breaking up.
Attempting to trace what is causing the explosion breakup in the circuit. I suspect it has something to do with the circuitry being fed by U43 pin 17, because targeting, which is driven by pins 10 and 13 of the same chip sounds fine. Probing around I find that if I touch the logic probe to the pins of U30 pin 1 while replaying the sound, the sound returns to normal. Replacing it resolves the breaking up noise.
Final fix: U30 (explosions breaking up), U16 (static overlaying SB2).
Mike Rhinehart
Active member
Awesome work, Mark. Still learning and improving despite being an expert. That is very impressive and admirable.
Thanks for writing them up.. I know it's a lot of work
If you have an ESR meter that shows ohms on the screen, you can use it as a high frequency milliohmmeter to check pins to ground to see which one is ever so slightly lower and the source of the grounding problem.
