What's new

Sumez

Student
Joined
Jan 16, 2020
Messages
34
Reaction score
21
Location
Denmark
I have an issue with my Sunset Riders that has persisted since I got it. At the time I complained to the seller who assured me that the PCB was just super picky about the 5v supply. I didn't have a PSU with an adjustable 5v, so I just foolishly believed him (though it may have worked to him, so I can't say if he's being dishonest).
A few years later when I did get one in my Astro City, and was able to set it to precisely 5.00 at the board edge, it got pretty clear that it fixes nothing.
IIRC the listing showed a picture of the game running, but it's been many years. So it's possible that this issue happened in shipping. Though it's also a possibility that the seller was trying to pass on a broken pcb.

What I find really curious is that the board seems to be working. I get the correct character graphics, the ROM/RAM check is running, and all of them are tested OK, including the 5 socketed EPROMs which I had figured could be the cause (I'd assume the CPU is hitting invalid code and returning to the reset vector). Basically at the moment when the game is expected to display the copyright screen, it just resets instead.

I also tried resetting with the test button held (hoping I could get into the test menu somehow), re-initializing the security EPROM. Not that it was an issue anyway.

I really have no clue how to go on diagnosing this problem, on a board that otherwise seems to be working. Any clever ideas from the big forum brains?
 
So all the post checks come back as OK and then it just boot loops? Weird

have you popped the EPROMs and reseated then? Yeah it’s 101 stuff but I’ve had boards come back to life just by reseating socketed stuff. I don’t think this’ll work in this instance but always good to start early.

Also I don’t have this board, but “super picky about 5V” doesn’t necessarily mean it absolutely wants 5V. It could be 4.97/8/9. I wouldn’t go too wild but maybe try some diff voltages and see what occurs. I just mention this as so many of my boards display as running at 4.97 or 4.98 vs pure 5V
 
So all the post checks come back as OK and then it just boot loops? Weird
Precisely

No need to skip 101 stuff, I might easily overlook things. I didn't have the socketed chips out of the sockets, but I've pushing them all down properly. I figured if they weren't working well, they wouldn't pass the ROM check though. Doesn't that do a full checksum?
I've also tried with different voltages. It's been a few years since I gave it a try, but I believe at least varying between 4-6 volts. I've never experienced any other Konami game being picky with that - including Parodius, which is the same hardware.
 
Try adjusting the power supply up a little - say to 5.10 to 5.15V. Don't go beyond 5.2V though.

If it is stable with a little more power then replacing the capacitors might resolve the issue.

If it still reboot-loops with more power then there must be something else wrong. I had a SF2 board that would loop after a hardware check and it ended up being a damaged trace on the bottom of the PCB. Yours might be a similar issue. Check the board over carefully for trace damage or missing components.
 
So all the post checks come back as OK and then it just boot loops? Weird
Precisely
No need to skip 101 stuff, I might easily overlook things. I didn't have the socketed chips out of the sockets, but I've pushing them all down properly. I figured if they weren't working well, they wouldn't pass the ROM check though. Doesn't that do a full checksum?
I've also tried with different voltages. It's been a few years since I gave it a try, but I believe at least varying between 4-6 volts. I've never experienced any other Konami game being picky with that - including Parodius, which is the same hardware.
Haha yes it should do a full checksum...that’s why I said I doubt it would work. But then again I’ve fixed boards by doing this so I always try it first.

I’d up voltage as previous mentioned. Just don’t go wild and let the magic smoke escape
 
Also, and I am unfamiliar with this particular board, is you could have a faulty CPU. If the bios is checking against the EPROMs, once it passes and tosses the execution of code to the CPU, there could be an issue. Maybe not a 100% dead chip, but a damaged leg or trace could cause the reset.

I’d check all the legs on the cpu and the traces around the chip itself. Could be something minor yet important
 
There isn't really a BIOS like you see with a PC. The startup hardware check is contained on the same ROM chip as the game code and is executed by the main CPU. If the CPU or clock crystal was dead then you wouldn't get a hardware check screen at all.

However, it is possible that the ROM chip with the game code is corrupted after the hardware check and the game is crashing, causing the watchdog to trigger the restart. It's also possible the watchdog itself is malfunctioning and restarting the board when it's not supposed to be.
 
Conflating terms. I say bios even if it’s in the ROM. Just cause I’m always fiddling with the M2 bios files
 
Either way, it's all running on the CPU, so if the ROM check runs as it's supposed (and even the EPROM reinitlializing works) I'm going to assume the CPU is doing fine.

However, it is possible that the ROM chip with the game code is corrupted after the hardware check and the game is crashing, causing the watchdog to trigger the restart. It's also possible the watchdog itself is malfunctioning and restarting the board when it's not supposed to be.
That would be my immediate assumption, but wouldn't that result in an error message during the ROM check though? As far as I can tell, all the ROM/EPROMs are being checked.
 
I tried just changing a couple of bytes on a MAME rom, and the check immediately failed, so I assumed it's a thorough checksum - but really it's just an assumption.
 
I’ve had a PCB before where it passed the rom check but when I pulled the rom to verify it, it failed. Replaced it and it worked perfectly after that. I told this to RJ before and I told him that it doesn’t make sense but it’s true.
 
I’ve had a PCB before where it passed the rom check but when I pulled the rom to verify it, it failed. Replaced it and it worked perfectly after that. I told this to RJ before and I told him that it doesn’t make sense but it’s true.
This is the kind of stuff I wanted to hear. :) Was it a Konami board also?
 
So for whatever it's worth I checked all the socketed EPROMs, and they match the MAME checksums. I also measured the voltage directly on the 68k CPU, and it's a fine 5v.

I'm not sure I have the tools to figure out what's causing the resets, so if there are no known issues or other probable guesses I guess I need to turn this board over to an expert somewhere. :\
I did find this log: https://www.jammarcade.net/sunset-riders-repair-log-3/ which could be a similar issue, but the IC in question at least doesn't have the same problem.
 
Just curious - did you check over the bottom of the board carefully for any damaged traces?
 
Yeah, there's nothing visible on the board.
I'm suspecting there's a faulty IC somewhere on the board, and since the error doesn't happen until a certain place in the code, it would be one that's not used until that point... so I guess probably a RAM chip?
 
Yep, could be either one of the RAM chips for the CPU or one of the TTL chips that handle the address lines between the CPU and RAM chips. Faulty GPU RAM would give you scrambled graphics but probably not restart the game. Same thing for the audio memory. So I suggest focusing on the CPU Work RAM and it’s supporting TTLs.

You can piggyback or swap the Work RAM first and see if that makes a difference. If not, the next step would be probing the Work RAM address lines with a logic probe and seeing if you can find one that isn’t toggling with activity. Trace that line back, and if it goes to a TTL then that TTL might have died. That’s a common fault-especially if they’re made by Fujitsu. Look up the part numbers on the RAM chips and TTL chips to get schematics that indicate which pins are the address lines.

Shameless self-promotion: I made a tutorial video on using a logic probe to track down a faulty ROM. You can follow a similar procedure to check RAM address line and TTL line activity. Maybe it’ll be helpful for you.

https://youtu.be/2PAtTIAijeA

On Sunset Riders, these two chips are the CPU Work RAM:

7E8F4879-9173-48E0-9093-A63529481850.jpeg
 
Last edited:
Yep, could be either one of the RAM chips for the CPU or one of the TTL chips that handle the address lines between the CPU and RAM chips. Faulty GPU RAM would give you scrambled graphics but probably not restart the game. Same thing for the audio memory. So I suggest focusing on the CPU Work RAM and it’s supporting TTLs.
This is exactly what I would be expecting.
I'm a software guy, not a hardware guy, but I've worked with assembly code on a lot of old school hardware. So as long as it's relevant to the software, and address mapping etc. this is the kind of language that makes sense to me XD
I was actually thinking of maybe writing a small 68k program on an EPROM just to test exactly where it goes wrong, but that's obviously insanely overkill. :P


You can piggyback or swap the Work RAM first and see if that makes a difference. If not, the next step would be probing the Work RAM address lines with a logic probe and seeing if you can find one that isn’t toggling with activity.
You'd start soldering on the board before using a logic probe? What's the reason for this priority?
The ROM test screen still tests the 12G and 12F RAM chips though (the ones you are pointing at), but I guess they aren't necessarily testing every possible address.

Thanks for the tutorial anyway! It's time for me to learn this stuff...
 
Back
Top