MiSTer FPGA Forum

The AV adapter seems to include its own Sync on Green circuit. Maybe that's redundant if you are getting SoG from the Mister AV board? Can you try turning one of them off?

Modelines do not rotate the image. Only the core itself can, and you can tailor a modeline to match that rotation. If the core itself doesn't include a rotate option in its menu there isn't much you can do, unless you want to edit the source itself in verilog/HDL or whatever.

There is an ini option for rotating the OSD only, not the games.

I don't see vsync_adjust. If you've got the core set to variable refresh then vsync_adjust=1 or 2 you will get 70hz in DOS which your TV probably won't handle, or at least not with normal modelines. Try vsync_adjust=0 to force the refresh provided in your modeline for now.

For optimal timing, think you need a mister-specific active adapter for the 5-pin din to USB for the user port. (And then naturally a classic 5-pin midi cable.) There's a bunch of them out there, here's legacypixel's.

https://www.legacypixels.com/mister/midi.html

werpu wrote: ↑Thu Oct 10, 2024 12:56 pm

The arm part sounds interesting, this could move the mt32pi project into full software mt32 emulation on the mister without the need for a pi!

This is a funny turn of phrase, on-device MUNT and Fluidsynth are already installed on Mister and semi-usable, just slotting in a more powerful ARM should make them more reliable.

RealLarry wrote: ↑Tue Oct 08, 2024 4:12 am

It should be enough to write 241007 into /MiSTer.version to fix that temporary (tested in a MiSTer emulation).

Is it known that we actually got the new bootloader and the version just isn't being updated?

I'm not hearing this in the above mentioned games on the analog out of my 6.1 Analog I/O from MisterAddons after UpdateAll. So I suspect its some interaction with your MiSTress. Though you might want to check if you have any audio filters active in the cores.

There's currently no real solution here short of using analog output. You need vsync_adjust=2 (no framebuffer) for minimal lag and that's going to necessitate drops when changing cores at least.

VRR isn't fully implemented unless vsync_adjust=0 but even then it seems implemented incorrectly. (I get a lot of wobble on an LG C1 when doing this.)

Completely forgot about scandoublerfx. Literally hoisted by my own pertard, er, past post. Glad it ended up helping you!

I would bet the problems are direct_video related. Each core produces its own super resolution, some may be more or less compatible with the converter.

Wonder if bad or missing SDRAM could be a cause?

I'm super sus if an NTSC analog SD TV can't handle SNES. I'd be more likely to blame your converter.

But sure I think [SNES] should work for testing. I'd probably use video_mode=512,240,60,cvt for evener pixels.

Come to think of it, you might need something higher to raise the pixel clock for the converter to work. Maybe 2048,240,60,cvt.