Konami (Sunset Riders) PCB resetting after (succesful) ROM check

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Konami (Sunset Riders) PCB resetting after (succesful) ROM check

      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
    • awbacon1 wrote:

      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.
    • Sumez wrote:

      awbacon1 wrote:

      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.
    • 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.

      ShootTheCore wrote:

      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’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.
    • 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: 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.
    • 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.

      youtu.be/2PAtTIAijeA

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

      The post was edited 3 times, last by ShootTheCore ().

    • Sir , how that white thing where you put the wires (red and black) from logic probe is called ? i want to buy one ^^ Thank you
      Multi's: CPS2 / F3 / M72 / NA1-2 / System16 B / Namco System1 Vector Labs' 4 in 1 (Horizontal)
      Superguns : HAS v3.1
      Scalers : OSSC v1.6 / RetroTINK-2X
      Scart switch : Gscartsw V5.2
      JNX: Spitfire
      NAC: Splitfire


      My Arcade Stuff
    • ShootTheCore wrote:

      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


      ShootTheCore wrote:

      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...