Screen aspect: real hardware vs emulators

[yugisokubodai]

As the title says, below are some pics on real hardware and clone ones: Hyperkin Supaboy SFC, SuperNT.
As you notice, the gray frame is closed to the logo.





This one is real hardware on CRT TV. The result is the same.



However, when I run on emulators like Snes9X and even BSNES, the one said to be the most accuracy emulator, the gray frame is not CLOSED to the logo as in real SFC/clone machines.



Can anyone explain why this happen? And how to cure this? I code the game to run on real machine, but I use emulators to quick test, so it's important to adjust the emulators close to real machine.

Note: this doesn't matter with the screen setting on emulators. I tried every setting and nothing change.

[FAST6191]

Look up something called overscan.

That is likely what is causing what you are seeing. Not all emulators will have/emulate it, CRTs have it by default and those fancy frame capture/conversion devices likely also handle it.

[yugisokubodai]

Solved. This does not involve overscan, it's a problem with layer scroll.
I scrolled the background with logo, but forgot to update the layer with the frame.

[Orochi Kusanagi]

A Dai no Daibouken romhack? Is there a link to the patch?

[yugisokubodai]

No, not a rom hacking.
It's one of my homebrews.

[assassin]

to be sure:

1) which output is the one you wanted?  the text box right by the logo (hardware), or the text box lower down (emulator)?
2) does the discrepancy still happen on normal higan and bsnes, as opposed to forks like bsnes-plus?

[yugisokubodai]

As you can see, the same code ends up differently on real hardware/clones and on emulators including Bsnes.
The text box position on real hardware/clones is higher than in emulators.
Anyway, this is solved.

[assassin]

congratulations; you answered exactly neither of my questions.

i was asking them to get more information, in case emulator authors want to duplicate whatever special case you might've found, in order to tighten up any accuracy their software might be lacking.

but forget it.  if authors/maintainers stumble upon this thread, and happen to have enough novocaine for at least 10 teeth, maybe they can ascertain what's in this homebrew and how their software responds to it.

[yugisokubodai]

which output is the one you wanted?  the text box right by the logo (hardware), or the text box lower down (emulator)?
> This is very simple. I code to run on real hardware. But everytime turning on the hardware for some seconds test is time consumming. So I'm using emulators to test. But, if the emulators output different results than the real one does, it would ruin my work. I keep laying on the emulators and then it turns out to be craps on the real hardware.

I've coded some homebrew demos and I recognize that the emulators tend to forgive minor errors,like miss timing, but the Snes hardware does not.

[Raeven0]

if authors/maintainers stumble upon this thread, and happen to have enough novocaine for at least 10 teeth

I'll pass on the novocaine. There's nothing like pain to make a person feel alive.

Can anyone explain why this happen? And how to cure this? I code the game to run on real machine, but I use emulators to quick test, so it's important to adjust the emulators close to real machine.

Well, bsnes-plus is not bsnes -- improvements in bsnes can take a while to propagate to bsnes-plus. This matters especially because you're using an old version of bsnes-plus. Version 05 includes some fixes for DMA, HDMA, and the PPU that might solve the problem you're seeing.

If you can re-create the bad file, it would be helpful if you'd try it in bsnes-plus-v05, and in Mesen-S, and in the "research project" known as higan.

[yugisokubodai]

Is there anywhere else allow to download executable V05 of Bsnes plus?
I've tried Mesen-S, but it seems inaccurate.



The same code was tested on real hardware (Super Famicom) and its clones, and they run perfectly without garbarges on the screen.

[Raeven0]

The direct link to bsnes-plus-v05 is probably here: https://github.com/devinacker/bsnes-plus/releases/download/v05/bsnes-plus-05-x64.7z

I am not surprised that mesen-s fails, but it's an interesting failure because mesen-s is trying to be high-accuracy like bsnes. I am more optimistic about bsnes-plus-v05.

What PPU sorcery have you committed that's causing the lesser emulators to choke? You might have found a feature that deserves a hardware accuracy test ROM.

[yugisokubodai]

Try enabling backgrounds in main screen ($212C) but turn off the sub screen ($212D), then the real hardware won't forgive this. But Mesen-s and other emulators does. However, I found that Mesen-S has much user friendly interface than Bsnes plus.

[Raeven0]

Try enabling backgrounds in main screen ($212C) but turn off the sub screen ($212D), then the real hardware won't forgive this. But Mesen-s and other emulators does.

I don't know what you mean. Something like

Code Select Expand

lda #$11 : sta $212c : stz $212d is a common initialization workflow that the hardware supports just fine. Maybe you're writing them during active display? If the emulator's timing is wrong, your writes could be occurring during HBlank on an emulator but during active display on hardware.

[yugisokubodai]

Thanks to the kind support of the emulator's author, all problems solved.