Rendering Ranger: R2 - Hangs on black screen after Virgin logo

[italiangrandma]

The Targa ‘Rendering Ranger’ prototype rom exhibits the same behavior. Running 20210713 release.

[SegaSnatcher]

Just confirmed that this game ran fine on the previous release of 06.20.21. So likely one of the recent commits broke compatibility with this game.

[steven-a-wilson]

This game is known to have CPU/SMP sync issues, including occasionally on original hardware. A bisect unsurprisingly points at a001ae9, which was a fix for #283. Reverting that change and changing ACLK_FREQ to 410112 (per @paulb-nl in #208 (comment)) gets both games running. This was basically a guess-and-check process, though; I can't cite any authority for this being fundamentally more accurate than the current code, and I don't know what the risk is of breaking other games.

[SegaSnatcher]

This game is known to have CPU/SMP sync issues, including occasionally on original hardware. A bisect unsurprisingly points at a001ae9, which was a fix for #283. Reverting that change and changing ACLK_FREQ to 410112 (per @paulb-nl in #208 (comment)) gets both games running. This was basically a guess-and-check process, though; I can't cite any authority for this being fundamentally more accurate than the current code, and I don't know what the risk is of breaking other games.

Mind posting the RBF, I'd like to try it out and see if it breaks other games. Thank You.

[steven-a-wilson]

SNES-ACLK-410112-test.zip

[SegaSnatcher]

SNES-ACLK-410112-test.zip

So some interesting behavior. At first it seems to work well, but after more time with it I noticed sometimes loading Rendering Ranger would result in the game freezing up in the beginning of the first stage. I can't repeat the issue consistently unfortunately. I was loading it up after the Kawasaki motorcycle game.

[steven-a-wilson]

It's reportedly the same way on original hardware (as well as on bsnes without a game-specific timing hack), although I don't know if anyone tested it enough on original hardware to get good statistics on how often it "should" happen. See bsnes-emu/bsnes#206 and:

https://github.com/bsnes-emu/bsnes/blob/6fc6bf14a39d32dab69c4f9687a81df26d412758/bsnes/sfc/system/system.cpp#L129

  if(configuration.hacks.hotfixes) {
    //due to poor programming, Rendering Ranger R2 will rarely lock up at 32040 * 768hz.
    if(cartridge.headerTitle() == "RENDERING RANGER R2") {
      information.apuFrequency = 32000.0 * 768.0;
    }
  }

I haven't fully tracked down the math, but I suspect that the current value of ACLK_FREQ in mainline SNES_MiSTer is equivalent to always applying the bsnes hack. In other words, strictly speaking, the game never locking up is inaccurate behavior. However, it might still be locking up more than it would on original hardware.

[Max833]

I was the one who tested this on original hardware back than. It never freezes on my SNES after the virgin logo, but sometimes when you play the game.

But Mesen-S had a similar problem like MISTer. This is what Sour writes in his "tricky to emulate" arcticle:

CPU read effects do not occur early enough in the CPU's cycle | Rendering Ranger R2: Freezes due to infinite loop with SPC

Source: https://snesdev.mesen.ca/wiki/index.php?title=Tricky-to-emulate_games

There was a disscusion on nesdev as well, some posts:
(Source: https://forums.nesdev.org/search.php?st=0&sk=t&sd=d&sr=posts&keywords=Rendering+Ranger&fid%5B%5D=12)

Near:

FWIW, Rendering Ranger R2 was a game that broke whenever I tried synchronizing the SMP to the CPU after every opcode, rather than after every cycle. It's very tightly timed code.

As I stated earlier, Rendering Ranger R2 is one of many games that absolutely requires cycle-level synchronization of the SMP to the CPU. If the CPU is calling the SMP, and the SMP is executing entire instructions before returning, then it's not going to work. It will work in much less accurate emulators by futzing with the timings (as in ZSNES and older Snes9X versions), but it will break when you get more cycle accurate timings (as in bsnes and Mesen-S. I also wrote a cycle-accurate SMP core that Snes9X uses now.)

bus hold delays on memory accesses (the thing you just did for Rendering Ranger)

Sour:

It wasn't working properly - it would only interrupt DMA to run HDMA if it was on the same channel as DMA. But in this case, HDMA is on another channel, and it ended up running after DMA completed. I guess very few games depend on this? (surprisingly?)
It's fixed now. I also spent some time triple-checking the logic and timing compared to higan and I think it should be pretty close now (including the lack of sync when HDMA interrupts DMA, etc.)
I also implemented the read being 4 master clocks earlier than the writes, and this fixed Rendering Ranger R2. It could be a coincidence, though, but I'll take it!

I hope this helps

[mario-64]

With SNES getting some attention lately could someone take a look at getting this game working?

[srg320]

Do not think that no one works on this issue, just that the issue is not a simple one.

[bootsector]

Game was badly programmed and issues happen even on real hardware. I don’t think anything can be done in the core.

[mario-64]

It should be playable again with only the same issues real hardware has.

[birdybro]

If this is related to SPC700 operations, then it might be relevant to mention all of PeterLemon's SPC700 test roms currently don't pass on the MiSTer, but they do on bsnes. That might provide a clue.

https://github.com/PeterLemon/SNES/tree/master/CPUTest/SPC700

I also just retested the large repo of snes test roms, and compared with bsnes. The remaining in this zip are ones that pass in bsnes but don't pass on the MiSTer core.

mister-fail-bsnes-pass.zip

If anyone has a ROM cart where they can test and compare, please remove the roms that also fail on real hardware and rezip and reupload here.

[henryrizzi]

I've attached the a zip of the test roms above which pass on real hardware as well. Tests were run against a 1 chip (snes jr) and earlier revision NTSC console using an sd2snes.
mister-fail-bsnes-pass-hardware-pass.zip

[birdybro]

This is a patch which allows it to boot (EDIT: for now, this is not meant to be a solution to this issue). It was also required for people to use it on jailbroken SNES Mini systems.

renderingranger_canoe.zip

[mario-64]

Any idea what this patch is doing technically? Does it change the timing of the game?

[birdybro]

No clue. Sluffy would have to describe it and he's awol for years now.

[Max833]

I'm pretty sure the canoe patch is a very hacky approach and not really helpful with this issue.

[birdybro]

I wasn't suggesting that it solves this issue.

I was providing a stop-gap solution as the person who would make the change to this core is srg320 who is currently living in a Russian-ocuppied region of Ukraine and somehow still working on the Saturn core, courageously.

This obscure issue with a known-to-be badly-programmed game (which needed a game detecting hack to get working in bsnes even) will get resolved eventually, I was just letting you all know that you can play it for now without having to revert to older versions of the core.

[Max833]

Hm, okay.
I'm not sure if we should spread hacky patches like this at all, though. In the future it will only cause problems, because some people will tell you this is a good rom.

bsnes doesn't have a detecting hack. You can enable an optional switch, so it doesn't crash as often as on real hardware, but it is starting perfectly fine even without this option enabled.

[SegaSnatcher]

Hm, okay. I'm not sure if we should spread hacky patches like this at all, though. In the future it will only cause problems, because some people will tell you this is a good rom.

bsnes doesn't have a detecting hack. You can enable an optional switch, so it doesn't crash as often as on real hardware, but it is starting perfectly fine even without this option enabled.

Given we don't really know when/if Srg320 will fix this issue, having a temp work around is very much appreciated. I doubt people using this hack will cause any real issues.

[bootsector]

Since the game programming is half assed and this patch address it, this patch is actually the right fix.

[mario-64]

Since the game programming is half assed and this patch address it, this patch is actually the right fix.

Since we don’t know what this patch actually does I’m not sure we can say it’s the right fix. Other than making the game bootable on the current core does it fix any of the crashes, etc?

[birdybro]

I don't really enjoy playing this game much, feel free to test it out and let us know how it goes.

[italiangrandma]

Patched the game and tested a bit...made it into Stage 4 before I died. No issues encountered. Will report back if I can make it further!

[bootsector]

Patched the game and tested a bit...made it into Stage 4 before I died. No issues encountered. Will report back if I can make it further!

You're the best grandma ever! :)

[birdybro]

Patched the game and tested a bit...made it into Stage 4 before I died. No issues encountered. Will report back if I can make it further!

Thank you for being a brave enough soul to test this game. Again, to anyone else reading, this is not a solution to the issue, it's a temporary workaround for the users only.

[Toryalai1]

This is fixed with latest commit!