Solved - Sinistar Freezes During Title Screen and Gameplay

[SNESNESCUBE64]

I was working on a Sinistar this weekend and am a bit stumped on this one. I got the power supply and power to the boards in pretty good shape and was able to get Sinistar to boot as it should. However, it seems to have developed an issue where it locks up. Here's what I've done so far:

- Rebuilt the power supply (measuring about 4.9V at the mpu and rom boards
- verified the roms using an external eprom programmer
- replaced rom board ribbon cable (very flakey)
- added batteries via remote battery board
-ran through all the self tests, not really reporting errors.
-replaced several sockets on the rom board due to presence of corrosion. (Verified that I didn't pull any traces)

I'm almost wondering if maybe I have a half flakey rom or something. I'm half tempted to burn a new set. But I am a but stumped as to what is going on. Any ideas? It specifically locks up during the title screen when it prints "Sinistar" several times and during gameplay after a while.

I made a quick video showing it locking up.

 

[mecha]

Sinistar in my experience is prone to weird CMOS corruption that causes the game to freeze or reset. I would go into adjustments and change the following items to YES and press Advance. see if scrubbing everything fixes the reset issue. given you yoinked the batteries already you probably already technically did this, but if the 5514 CMOS is bad it can do stupid things like not initialize properly.

EDIT: I'm certain @SynaMax was able to figure out these anomalies, but that seems like forever ago now lol

 

[SynaMax]

@mecha and @braedel are definitely the go-to guys when it comes to this sort of thing. But from skimming through the video it looks like the palette colors in RAM get corrupted first and it draws some garbage on the right side of the screen, before resetting back to the power up rug test.

Note how the colors change twice when the crash happens. The second time is the "reset" color palette, which is normal and happens every time the system is reset or when the rug test starts up.

I would say bad ROM but the fact that the ROM test passes is interesting. Perhaps this is a RAM issue?

 

[ArcadeTechGW]

@mecha and @braedel are definitely the go-to guys when it comes to this sort of thing. But from skimming through the video it looks like the palette colors in RAM get corrupted first and it draws some garbage on the right side of the screen, before resetting back to the power up rug test.

Note how the colors change twice when the crash happens. The second time is the "reset" color palette, which is normal and happens every time the system is reset or when the rug test starts up.

I would say bad ROM but the fact that the ROM test passes is interesting. Perhaps this is a RAM issue?

Could be a flaky ROM. This was out in 82/83, that's a lot of years and stress on the ROMs.

 

[SNESNESCUBE64]

So here are a couple additional things I tried since I have the resources available.
- swapped the special chips with ones I had in stock (no change)
- swapped the 4116s for giggles with a tube of NOS ones, no change so the old stuff is going back in
- pulled the batteries, reset the high score table, reset everything in the menu.

I've noticed on bootup with no batteries goofyness on the high score screen.



Also, it sometimes locks up this way. In this I can still insert coins oddly enough.

I'll take a closer look at the 5514 cmos ram tomorrow. I'm pretty sure I can use LH5114 in its place but I'll check the data sheets.

 

[mecha]

So here are a couple additional things I tried since I have the resources available.
- swapped the special chips with ones I had in stock (no change)
- swapped the 4116s for giggles with a tube of NOS ones, no change so the old stuff is going back in
- pulled the batteries, reset the high score table, reset everything in the menu.

I've noticed on bootup with no batteries goofyness on the high score screen.
View attachment 862465
View attachment 862466

Also, it sometimes locks up this way. In this I can still insert coins oddly enough.

I'll take a closer look at the 5514 cmos ram tomorrow. I'm pretty sure I can use LH5114 in its place but I'll check the data sheets.

yes 5114, 5514, 6514 are all compatible. for giggles you could even use a 2114, but I wouldn't use that with batteries

the high score corruption is one of the early signs the CMOS is probably at fault. another sign is if it always boots to factory settings restored even after confirming battery power source is reaching the CMOS chip and you have no extracurricular things going on like Arcadeshop switching power supplies. I've had games drive me nuts in the early times until I realized bad CMOS can cause a myriad of problems. lol

 

[SNESNESCUBE64]

I'm running a stock (albeit rebuilt) power supply, I removed the switcher setup that was hacked in. I'll swap the cmos ram tomorrow. I never had issues with booting to factory settings, it seems to have hles the settings like freeplay just fine. But I am with you that it might be cmos. Perhaps the CMOS RAM is haunted...

 

[ArcadeJason]

Sinistar in my experience is prone to weird CMOS corruption that causes the game to freeze or reset. I would go into adjustments and change the following items to YES and press Advance. see if scrubbing everything fixes the reset issue. given you yoinked the batteries already you probably already technically did this, but if the 5514 CMOS is bad it can do stupid things like not initialize properly.

EDIT: I'm certain @SynaMax was able to figure out these anomalies, but that seems like forever ago now lol

View attachment 862463

This fixed random resets on my sinistar a week ago

 

[mecha]

work Sinistar was pretty sick. worth noting it and Joust were the only games not running JROK. when I came back to work here they were running on Arcadeshop switching power supplies and were a nuisance almost every day resetting CMOS. so I fixed the linear power supplies. also, don't reflow these original power headers like this, replace them with new square pins. I also think I changed both to use 2032 batteries.

 

[ArcadeJason]

work Sinistar was pretty sick. worth noting it and Joust were the only games not running JROK. when I came back to work here they were running on Arcadeshop switching power supplies and were a nuisance almost every day resetting CMOS. so I fixed the linear power supplies. also, don't reflow these original power headers like this, replace them with new square pins. I also think I changed both to use 2032 batteries.

View attachment 862479View attachment 862480View attachment 862481View attachment 862482

The fix for that is to put a big cap on the 5v terminals

 

[braedel]

Try swapping the 6809e and checking/cleaning socket connections for it. Is the watchdog pad cut?

~Brad

 

[vintagegamer]

I don't know why, but that feels like bad RAM to me.

 

[SNESNESCUBE64]

Is the watchdog pad cut?

No it is not. When it locks up, strangely enough the 74ls393 used in the watchdog is still being refreshed. I didn't hook up my logic analyzer to it, but it seems only the first two bits are counting on it which I would think is normal for a watchdog.

I replaced the 5414. There was rust underneath the chip. When I boot now without batteries, it seems to properly initialize with 0s in the highscore screen instead of dots. Even with resetting the settings and highscore table, it still locks up in the same place so the issues has not been resolved.

 

[braedel]

Yikes!


So, the only way the the screen image would persist(frozen) is if the CPU was halted or not running. Whatever was left in the memory when code execution stopped would continue to be rendered on the display.

~Brad

 

[SNESNESCUBE64]

So, the only way the the screen image would persist(frozen) is if the CPU was halted or not running. Whatever was left in the memory when code execution stopped would continue to be rendered on the display.

I see that the halt pin on the 6809 is toggling quite a bit but doesn't get stuck when it locks up. Could it be getting lost in code due to a fualty ROM? I kinda wish I had a 6809 fluke pod for stuff like this. What's funny is when it locks up I can still start a game.

 

[braedel]

The 'Special Chips' trigger the halt when they take over the bus to move data around. The key would be to look at the state of the halt pin when the game is hung (low/gnd is halt enabled - the CPU 'tri-states'/floats the address and data lines when halted).


~Brad

 

[SNESNESCUBE64]

The 'Special Chips' trigger the halt when they take over the bus to move data around. The key would be to look at the state of the halt pin when the game is hung (low/gnd is halt enabled - the CPU 'tri-states'/floats the address and data lines when halted).
View attachment 862529

~Brad

Like I had mentioned I kind of poked that pin just to see if it was getting stuck low. Even when the game locks up that pin is still toggling. It's not stuck low or active. It leads me to believe that it's getting stuck somewhere in code execution.

 

[crayzkirk]

It's really odd that the screen freezes yet the watchdog isn't resetting the CPU. Interesting that the game can be restarted by selecting one of the player start buttons (or did I read that wrong). Seems that the game is stuck in the page 0 process of reading the ROM board PIA or other function. I had a Bubbles that was making me crazy because it would run the diagnostics for hours yet when the game was running in attract mode, would freeze and restart. I ended up burning a set of Stargate ROMs and found that one of the special chips was bad. Does the game pass all of the switch and sound tests?

It's been a while since I looked at the schematics, could there be an issue with the write enables to the RAM? With the screen freezing and the program running, it seems that the game is running however writes are not making it to the RAM after the special chips have done their job.

 

[SNESNESCUBE64]

Does the game pass all of the switch and sound tests?

Switch test passes yes, it's goofy sometimes as the cable on my widget board is pretty flakey. I didn't think to run the sound tests because I could hear the sounds and all that. Although earlier it played the starting music inbetween lives 2 and 3, so maybe there is something there.

The game cannot be restarted by pressing the start buttons. But a game can be started when it is locked up. I am not convinced it is the special chips themselves. I swapped in another pair for testing purposes and noticed no change in behavior.

 

[HudsonArcade]

The 'Special Chips' trigger the halt when they take over the bus to move data around. The key would be to look at the state of the halt pin when the game is hung (low/gnd is halt enabled - the CPU 'tri-states'/floats the address and data lines when halted).

The special chips don't work on autonomously -- they have to be triggered by code running on the CPU.
/HALT stuck high points to a code issue.
/HALT stuck low would be a blit not completing --> bad SC