SEGA Star Trek - Power on Reset Trouble

64B1T

Well-known member

Donor 5 years: 2021-2025
Joined
Sep 16, 2021
Messages
3,750
Reaction score
4,255
Location
Maryland
I have a SEGA Star Trek I've been working on for a bit. I've rebuilt and recapped the monitor and the power supply. I've cleaned the boards and deoxited the headers. However it still is displaying trouble when booting.

It usually boots the game just fine, but audio and speech tend to have issues only when booting.

Here's an example:

Other things it'll do
- Work fine except no speech at all
- Static for a few seconds, and then it'll play part of the start up song
- Work fine (rarely)
- No image (only happened once)

In all cases, if I hit the manual reset switch after it has booted, it will work just fine.

I had assumed that it was the PSU, so I recapped it and set the voltage to 5.1V, but it doesn't seem to have affected it much.

I have a switch mode PSU setup that just ties 5V to the AC reset line, and that seemed to work last time I tested it, so I'm thinking it must still somehow be PSU related...
 
It's not the PSU. Think corruption in the sound and speech ROMs, or something in that area. What should be tones is coming out garbage.
 
It's not the PSU. Think corruption in the sound and speech ROMs, or something in that area. What should be tones is coming out garbage.
But then why does it all work perfectly (speech included) for as long as it is powered on, once I hit the reset switch?

Surely if it's ROM corruption, it would be persistent.
 
Original backplane? They get dirty. :poop:
Once powered on, the connections heat up and form a better connection.
Did you clean the edge connectors THOROUGLY - male blades on the PCBs, and pins on the backplane?
Did you visually inspect the pins on the backplane connectors? Just doing DEOXIT is not enough.

This is one reason why I repro'd these backplanes - to provide an updated/cleaner/more-reliable solution with new 86pin.

Of course, with anything Vector -> YMMV.
But with everything, start with -> Power and Connections.
 
Oh, and this is another case where having a SPARE set of WORKING boards really does help.
Swapping and eliminating boards in a cage like this is the easiest way to determine the issue.
Most don't have a bench setup nor an extender card to debug with.

Already, so many "guesses" - is it the CPU, is it a ROM, is it the sound boards, is it the reset, is it the backplane ... yes, could be any of these.

Oh, yes -> YMMV :)
 
Does it have a power-on reset circuit?

I've never looked at the schematics for these. But it looks like something in the sound system isn't getting initialized properly, and a manual reset is fixing it.
 
Half my Sega vector row does this . I just turn the power on ,off and on again. Reminds me of vanguards they often crash at boot due to the florescent bulb starting. Take out your bulb and see if it still happens
 
Does it have a power-on reset circuit?

I've never looked at the schematics for these. But it looks like something in the sound system isn't getting initialized properly, and a manual reset is fixing it.

The linear PSU sends an "AC" signal to the CPU board. A POR circuit, with 555 timer, determines the RESET signal to the Z80A on the CPU board.
The universal sound board receives a modified/buffered RESET signal from the CPU.
 
Last edited:
I've never gotten a crack at doing it, but the original power supply setup I think has inadequate grounds which results in plugs burning up. a prominent arcade has this game and don't bother with the power supply, whenever the G08 breaks cause the game doesn't boot properly they just keep fixing the monitor.

not my problem. these cabinets are also the worst ever to do anything with.
 
The G80 power supply has design flaw... (IMHO)
The fuses are on the output side of the bridge rectifiers.. if they fail the right way.. then stuff burns up..
One thing we learned the hard way.. if the -5v regulator is out of spec.. it shuts down the Z on the G08.. PITA..
 
Sorry for the late reply. I've been terribly busy lately moving my workshop from one location to another. I have some insight here that might help. The symptoms you're describing fall under POR but there is a specific part of that circuit that was modified because of (you guessed it) issues with the G08-001 and other early monitor failures. They threw the kitchen sink at the issue and modified several circuits on the monitor chassis along with a few on the logic set. The theory (unproven at the time) was that the G08 monitors were blowing up due to 'garbage' vector signals being generated by the XY pair prior to the Z80 coming out of reset during POR, resulting in over scanning and stress on the deflection transistors. Not sure I buy it, but that's in the past now. Here's an executive summary of what happened to POR based on reading service bulletins and other websites over the years:
  1. The early CPU boards used in the G80 vector games were designed/borrowed from the G80 raster games. Originally, C45 and C46 were both 10 uF capacitors. This resulted in a pretty lengthy reset time. Ever turn on Astro Blaster and see the black and white jail bars for a good 1-2 seconds before the game boots? That timing is controlled by the C45 and C46 values/ratio.
  2. The G80 vector team decided to minimize this time as much as possible and changed C45 from 10 uF to 0.22 uF. Service bulletins were issued for games in the field, and I assume new CPU boards leaving the factory had this done, too. In most cases this was done by using either a ceramic or tantalum 0.22 uF capacitor at C45 rather than electrolytic. That's an easy way to tell at first glance what might be on your CPU board.
  3. My speculation: I think they moved the pendulum too far in the other direction. While using a 0.22 uF greatly reduced the reset time, they were probably right on the cusp of this being enough time for the CPU board Z80 and, more importantly, the downstream reset signals on the speech and/or sound boards to all sync up and have a clean slate in memory to work properly. Why they didn't figure this out before issuing the service bulletin for the 0.22 uF capacitor is unclear. Perhaps their test rigs in the lab had components with latency that just squeaked under the radar of being okay.
  4. They later settled on using a 1.0 uF electrolytic capacitor at C45 rather that 0.22 uF. If your G80 vector game has a green 1.0 uF capacitor at C45, you probably have a later revision and likely do not experience these spurious bootup issues with the speech and/or sound boards.
Moral of the story: Recap your CPU board regardless of the value at C45. All the electrolytics are beyond their shelf life and need a refresh. When recapping, use 1.0 uF at C45 and 10 uF at C46. While I cannot guarantee this will solve the speech and/or sound board issues 100%, it will certainly reduce the likelihood of the occurrence.
 

Attachments

  • G80 Reset Circuit.jpg
    G80 Reset Circuit.jpg
    173.6 KB · Views: 12
Sorry for the late reply. I've been terribly busy lately moving my workshop from one location to another. I have some insight here that might help. The symptoms you're describing fall under POR but there is a specific part of that circuit that was modified because of (you guessed it) issues with the G08-001 and other early monitor failures. They threw the kitchen sink at the issue and modified several circuits on the monitor chassis along with a few on the logic set. The theory (unproven at the time) was that the G08 monitors were blowing up due to 'garbage' vector signals being generated by the XY pair prior to the Z80 coming out of reset during POR, resulting in over scanning and stress on the deflection transistors. Not sure I buy it, but that's in the past now. Here's an executive summary of what happened to POR based on reading service bulletins and other websites over the years:
  1. The early CPU boards used in the G80 vector games were designed/borrowed from the G80 raster games. Originally, C45 and C46 were both 10 uF capacitors. This resulted in a pretty lengthy reset time. Ever turn on Astro Blaster and see the black and white jail bars for a good 1-2 seconds before the game boots? That timing is controlled by the C45 and C46 values/ratio.
  2. The G80 vector team decided to minimize this time as much as possible and changed C45 from 10 uF to 0.22 uF. Service bulletins were issued for games in the field, and I assume new CPU boards leaving the factory had this done, too. In most cases this was done by using either a ceramic or tantalum 0.22 uF capacitor at C45 rather than electrolytic. That's an easy way to tell at first glance what might be on your CPU board.
  3. My speculation: I think they moved the pendulum too far in the other direction. While using a 0.22 uF greatly reduced the reset time, they were probably right on the cusp of this being enough time for the CPU board Z80 and, more importantly, the downstream reset signals on the speech and/or sound boards to all sync up and have a clean slate in memory to work properly. Why they didn't figure this out before issuing the service bulletin for the 0.22 uF capacitor is unclear. Perhaps their test rigs in the lab had components with latency that just squeaked under the radar of being okay.
  4. They later settled on using a 1.0 uF electrolytic capacitor at C45 rather that 0.22 uF. If your G80 vector game has a green 1.0 uF capacitor at C45, you probably have a later revision and likely do not experience these spurious bootup issues with the speech and/or sound boards.
Moral of the story: Recap your CPU board regardless of the value at C45. All the electrolytics are beyond their shelf life and need a refresh. When recapping, use 1.0 uF at C45 and 10 uF at C46. While I cannot guarantee this will solve the speech and/or sound board issues 100%, it will certainly reduce the likelihood of the occurrence.
Thank you for this! I finally got around to recapping the PCBs, and this entirely solved the boot problem. It did have that .22uF tantalum in place.
 
Back
Top Bottom