MiSTer FPGA board

[Wolf_]

The person working on the MiSTer user guide (bible) has said they are going to take a look at improving the front end so I imagine that will probably get some polish very soon.

And considering it has amazing snes, genesis, sega cd, Neo Geo, nes, sgx, gbc, and gba cores (and many others) with tg-cd and ps1 cores on the way I can't see why you wouldn't invest in it.

Also I'd say the snes core is 100% playable (no bugs impact gameplay let alone break games from what I have seen) and the only bugs that exist are very minor graphical ones you would only notice in games you are looking at side by side or have memorized by heart and those are usually patched very quickly after they get reported. Considering the core is under a year old and supports every special chip except for a shogi game ai chip used in a single game I'd consider the 99.8% perfect core to be outstanding with the potential to reach bsnes levels of accuracy sooner rather than later. The main thing keeping it from perfection atm is just waiting on more people to play with it and notice any of the fairly well hidden (to the average user) remaining bugs.

He already had a current solution, a healthy backlog, and wasn't sold on spending more money. I don't disagree that it's a great device, but with those restrictions, why pay for it now just to sit around and gather dust?

True I do currently have a very good all in one PC with the benefits of more emulators, Fightcade and STEAM. I even have a modded Wii that I make good use of as well. Actually the Wii is probably my most used machine when I want to get back to some old school classics

The question I have now is waiting a good idea? I currently don't really need one and the MiSTer is an evolving device.

We see this with the implementation of new cores and up-gradable components. We saw this with the RAM when the Neo Geo core was released.

I think its possible that if I get one now I might need to drop down more money on upgrades when new cores are released. That and the fact that you have to shop around for MiSTer components. I'd rather just buy one fully assembled from the get go but that option is just way more expensive.

The MiSTer will likely always be an evolving device until the moment it is not being developed for and then the next board will be an evolving device until it is no longer being developed for and ect into infinity. In terms of hardware though here is my take:
De10 nano fpga dev board - going to be in use for years.

128mb ram - probably going to be around for awhile. The Neo Geo is one of the most demanding consoles the de10 nano is capable of replicating and was just released so on the off chance we get something more advanced it probably won't be for awhile

Io board - probably going to lose the sync on green switch as that can be done via an ini file and I would imagine a version without analogue video out will hopefully exist as that can be done via dac and looks much neater.

Controller boards - BliSTer is probably finalized and LLCJ will probably be out in the next few months.

Cartridge & cd reading components - I saw a pic of a prototype MiSTer case that included a disc drive. I have no eta on this or confirmation it will ever actually be released and wouldn't suggest using a disc drive or cartridge slot anyways. Just pick up an external harddrive and play backups. This will be less headaches and preserve your game collection.

Case - Probably going to be updated as new revisions of the io board and a new controller board comes out (not that it matters if you are using the BliSTer board)

So if you're okay with the BliSTer controller board and don't mind a physical sync on green switch and analogue video out ports then the current fpga board, ram board, io board, controller board, and case should all be something you can use until a new fpga board gets selected in the distant future. If you want to wait for the LLCJ then you will need a different bottom half to the case. And if you want a neater looking io board with no SoG or potentially analogue ports that will be a little while and require a new top half of the case.

[Bassa-Bassa]

Isn't a low latency mode for standard USB boards being already coded so that LL Cool Joy or Blisster aren't needed anymore (if you use a low latency USB controller)?

[Wolf_]

Isn't a low latency mode for standard USB boards being already coded so that LL Cool Joy or Blisster aren't needed anymore (if you use a low latency USB controller)?

That is true but adapters have yet to be created to plug analogue controllers into usb ports in this mode (as far as I know anyways) so you are limited to usb controllers. Also it is only working with native controllers for the core in use when you are playing (and only a few cores have the option to enable it) and Blissbox allows you to use any controller you want with very low latency and has adapters for pretty much everything under the sun available for purchase right now. The LLCJ prototype board has a analogue connection designed for arcade sticks as well. So they both offer things you can't get with just low latency usb.

I'm certain in the future you will be able to use usb low latency modes with non-native controllers and it will be enabled on all the cores and not just a select few but as it is very much in beta right now I wasn't going to count it as ready to be used for gaming as opposed to just testing it out. Although like all things MiSTer I expect now that it is in beta it will develop rapidly in the next few weeks. Fingers crossed for a wide variety of adapters.

[paulb_nl]

I really hope that all the people working on MiSTer cores are doing things properly and the bugs in the SNES code reported will lead the core's author investigating about what's wrong and not just make a patch to have those games working properly and call it a day.
Good thing everything is on Github so we can check ourselves what's been done (and how).

Most of the time when software emulators use game specific patches the reason is for speed. If they implement cycle accurate logic then a powerful cpu is needed to run it.

With FPGAs there is no need for this and logic is implemented at a cycle level anyway. When a bug is found then the logic is changed which affects everything and not just a single game.

Most emulators are made from studying the behavior of original hardware. Including the FPGA emulators by Kevtris.

Only a select few are made from copying the transistor logic from the original chips. The MiSTer Neogeo core by Furrtek was made from transistor logic except for the CPU and sound chips.

[donluca]

Every single emulator (including all FPGA based emulators) use hacks. So, everyone has messed it up? That's extreme.

They're not.
Using a hack is different from coding an approximation of what the hardware does. There's an important difference.

All emus use code which approximately reproduces the original hardware behavior.
Some, we might say, are close to perfect, where perfect means that their output matches what the original hardware does, down its own very logic.

First of all, absolutely no video game system has been completely researched and photographed at a transistor level. AFAIK, the 6502 processor is the oniy component that has been (more or less) completely documented. That means dissolving the chip and photographing it layer by layer. The research hasn't been done.

We have schematics of most videogame boards and most chips used were off the shelves ones which come with complete documentation and the custom ones are being studied. If you're into this kind of research, you'll probably enjoy the read: http://arcadehacker.blogspot.com/2018/0 ... licon.html
And they studied many more, they really did god's work.

Also, there aren't any affordable and conveniently sized options to completely implement a system on a true transistor level.

We don't have the hardware to do it. We don't have the documentation.

FPGAs are acceptable approximation and that's why I'm really interested in the MiSTer development.

Sure, but I don't have the information or hardware to do it "properly" right now.

I'll give this the benefit of the doubt.

As hardware gets more powerful, we have the ability to emulate more accurately and "organically" derive proper behavior. In the meantime, everyone is using hacks.

This was true... uh, 10 years ago, if not more.

Is that what happend? Or was it because we wanted something playable that hit frame rate on our hardware at the time?

Again, this was true ~20 years ago and I could still object on using such hacks, but I guess that it was the kids you're talking about raging and crying on the internet that they wanted to play Super Mario 64 on their PCs which pushed developers into making speed hacks instead of telling them to go out and buy the console and game and stop pirating.
My own opinion of course. HLE emulation and dynamic recompilers are what got us to have more power hungry consoles to run on our own computers so it's still an important development in the history of emulation.

So sick of spoiled children pissing on all the hard work emu devs poured in. You're not special, kids. You have better hardware available. You're not magic.

I wish I were still a kid, unfortunately I'm 33. I started on an 8Mhz 80286 when I was 8yo and marveled at playing games like Monkey Island and Prince of Persia.
So yeah, I know about hardware limitations probably better than most people around those days.
You can go patronizing someone else, thank you very much.

The people working on MISTer are doing the best they can with what they have available to them.

Also, cycle accurate is a reference to timing, not proper hardware behavior.

Almost correct. Cycle accuracy is referred to the set of inputs and outputs given in a single cycle.
In laymen terms, if I input "1" into a SNES and it outputs "2" in a single cycle, a cycle-accurate emulator will behave exactly the same, down to single cycle timing.

Most of the time when software emulators use game specific patches the reason is for speed.

Most of the time when software emulators use game specific patches the reason is they got most of a console's library to play (mostly) right and know that fixing some games will screw up hundreds others, so they take the easy way out, put a couple "ifs" for those games and call it a day.

Glad to hear this is not the case with how MiSTer's SNES core is being handled, hopefully this is the case with all the others.

[Udderdude]

486. DOS. NESticle. All you need, really.

[donluca]

486. DOS. NESticle. All you need, really.

Great times indeed, except that we couldn't afford a 486 at the time, so we kept using our 286 and then, when my dad finally saved up enough money, we got us a Cyrix 166Mhz with MMX extensions which was cheaper than a pentium and a fucking headache for lots of games due to compatibility issues

Alright, not so great times, but that's what we got back then.

[orange808]

They're not.
Using a hack is different from coding an approximation of what the hardware does. There's an important difference.

All emus use code which approximately reproduces the original hardware behavior.
Some, we might say, are close to perfect, where perfect means that their output matches what the original hardware does, down its own very logic.

That depends on your definition of a hack. How close does it have to be for you to call it legitimate? And, obviously, your definition of "close enough" changes with every passing day. Who has time to constantly churn a hobby project?

We have schematics of most videogame boards and most chips used were off the shelves ones which come with complete documentation and the custom ones are being studied. If you're into this kind of research, you'll probably enjoy the read: http://arcadehacker.blogspot.com/2018/0 ... licon.html
And they studied many more, they really did god's work.

Yes. So, we agree the research isn't done.

FPGAs are acceptable approximation and that's why I'm really interested in the MiSTer development.

That's not what I said, though. You said transistor level emulation and that's not feasible today. Something tells me the goal posts of "acceptable" will move as time goes on. (They always do.)

That's my issue with this. Intentional or not: you suggested we can make a magic hardware recreation by just plugging the schematics into an off the shelf FPGA. The barrier? "Lazy" devs?

That's not true. What is close enough, anyhow?

This was true... uh, 10 years ago, if not more.

Well, I'm old.

We got flamed in Mame for worrying about accuracy and letting the hardware catch up. On the other side, hitting frame rates on real machines today is penalized with a dismissive "you're just lazy" tomorrow.

Very few people have time to pour into infinite iteration. At some point, there just isn't any spare time and energy to keep going.

Again, this was true ~20 years ago and I could still object on using such hacks, but I guess that it was the kids you're talking about raging and crying on the internet that they wanted to play Super Mario 64 on their PCs which pushed developers into making speed hacks instead of telling them to go out and buy the console and game and stop pirating.
My own opinion of course. HLE emulation and dynamic recompilers are what got us to have more power hungry consoles to run on our own computers so it's still an important development in the history of emulation.

UltraHLE was important, but the dev never wanted to make a long term commitment to an emulator--or take on Nintendo. It was a tech demo. I can't speak for the other N64 emulation options. With Mame, it was possible to work on games that couldn't hit frame rate on the hardware, but if you tried that with a console emulator, all you would get was flame.

[donluca]

That depends on your definition of a hack.

A hack is a modification of how your own code works in order to make something run, which otherwise wouldn't.
This means you've basically messed it up somewhere along the road and you're doing a (highly likely) very bad patch to make the problematic game run.
So instead of doing it properly, by doing research on where's the flaw in your logic/code is, you just lazily make a change just for that game in order to have it working.

How close does it have to be for you to call it legitimate? And, obviously, your definition of "close enough" changes with every passing day. Who has time to constantly churn a hobby project?

That's the 1 billion dollar question and it's not just me, but all the people looking at the emu scene since it all started.
To some, legitimate = I personally can't tell a difference between emu and real hardware, to others it has to be graphically identical and then there are those who go beyond and want the game code to run exactly like on original hardware, even if there are changes that they can't see or feel.
Your call.

For me, I don't necessarily need to go down to circuit level, like emulating the picoseconds of delay cause by a trace length. That's way too much and absolutely useless.

But this is something which I always wanted to see being made: a FPGA where you can put in whatever components you have on hand and let the FPGA handle the rest of the logic.
For example, Mega Drive FPGA, you have your own 68000 CPU, Z80 and YM2612. You put those on, the FPGA recognizes them and turns its own emulation of those ICs off and use them. If you don't have them, then the FPGA will emulate them.
That's my little utopia, emulation wise, but I feel we're nearing a stage were it won't be needed because...

Yes. So, we agree the research isn't done.

...enough research has been already done.
It's not complete, like every single IC on the every console or arcade board, but parts like the motorola 68000 CPU, Z80 and others are at this point well known and perfectly emulated, down to cycle accuracy. And those have been used in god-only-knows how many consoles and arcade boards.

You said transistor level emulation and that's not feasible today. Something tells me the goal posts of "acceptable" will move as time goes on. (They always do.)

It will in time. Having the foundation ready it's a good thing. MAME should have taught you this.

That's my issue with this. Intentional or not: you suggested we can make a magic hardware recreation by just plugging the schematics into an off the shelf FPGA. The barrier? "Lazy" devs?

I'm not suggesting anything, I'm not an FPGA developer, that's more of a question for the likes of Jotego or paulb.
The barrier is knowledge and motivation. Today we have the means to create motivation through donations, Patreons and so on.
MiSTer itself is a fantastic starting point and it's going to get better and better as time passes, so we basically just have to wait.

We got flamed in Mame for worrying about accuracy and letting the hardware catch up.

You know I wasn't on that part of the fence, I always cared more about accuracy (except, maybe, when I was a kid and just wanted to play Metal Slug, but good ol' NeoRageX got me covered on that)

On the other side, hitting frame rates on real machines today is penalized with a dismissive "you're just lazy" tomorrow.

It is not, it's never been about speed, it's been about making stuff work through hacks.
The whole "speed" topic was brought up by you and I didn't buy into it.
There have been hacks to make games run at full (or acceptable) speed, but I wasn't addressing those and you'd known if you've read my posts.
I never talked about speed, I always talked about accuracy.

Very few people have time to pour into infinite iteration. At some point, there just isn't any spare time and energy to keep going.

And that's true, I agree and it's why open source software has been the real revolution in emulation, so that when someone doesn't have any more time, someone else can pick it up and continue.
And it's why I have really high hopes for MiSTer.

UltraHLE was important, but the dev never wanted to make a long term commitment to an emulator--or take on Nintendo. It was a tech demo. I can't speak for the other N64 emulation options.

For a very long time, it was the only real option and opened the doors for High Level Emulation (that's what HLE stands for) to other platforms. Dynamic recompilers then came out and made the Playstation emus make huge leap forward and so on.

With Mame, it was possible to work on games that couldn't hit frame rate on the hardware, but if you tried that with a console emulator, all you would get was flame.

I know too well but trust me, MAME got a huge amount of flak for this even back in the days.

And let me add just a little remark: for once, it feels really good to actually have a goddamn civil discussion without resorting to personal attacks and non sequiturs.
If you feel like discussing it further, I'd be absolutely okay with that, although this might not be the best thread.

[mikejmoffitt]

...enough research has been already done.
It's not complete, like every single IC on the every console or arcade board, but parts like the motorola 68000 CPU, Z80 and others are at this point well known and perfectly emulated, down to cycle accuracy. And those have been used in god-only-knows how many consoles and arcade boards.

How sure of you are this? Do we have information on the cycle penalty of accessing VRAM on Atlus 68000, "Toaplan 2" GP9001 hardware, and other systems of this era? How about during blanking vs active display? Does MAME even support the concept of asserting /DTACK for n cycles as necessary?

The two aforementioned platforms also are filled with hacks to make things "work" (e.g. the Atlus 013 sprite IC's serial configuration register is completely ignored and isn't understood; Dangun Feveron's screen shake that changes the sprite raster area doesn't work; GP9001 sprite/layer priority is based on some experiments and isn't still fully understood). The maximum draw bandwidth for the GP9001 and 013's sprite framebuffer isn't emulated either, so it is able to overdraw where the hardware would simply drop sprites.

Those individual common components like CPUs, sound ICs, etc. are mostly understood well, but the glue logic connecting them is part of what makes each machine configuration different, and these are important elements in making an emulated system perform accurately. It's easy to scoff at this kind of thing, but many games (unfortunately) have their playability somewhat tied to the execution speed, and slowdown has not been right for many of these arcade games.

[donluca]

How sure of you are this?

You tell me.

And without quoting all of your post, just to reply to the question above, I'll just highlight this:

Those individual common components like CPUs, sound ICs, etc. are mostly understood well, but the glue logic connecting them is part of what makes each machine configuration different,

And that's what's been investigating recently, including the dreaded wait states in the 68k emulation which make lots of games in MAME run at incorrect speed, mainly thanks to the effort of many people who are also working on the MiSTer cores.

https://twitter.com/topapate

This is a guy I've been keeping an eye on. He's going places and working really hard, gathering knowledge and applying it to try and replicate the original hardware behavior.

And there are many more.

I wouldn't be surprised if in 4-5 years we'll get to a point where we'll have all the main consoles and the most well known arcade boards cracked open and perfectly replicated on FPGAs.

[Bassa-Bassa]

Dangun Feveron's screen shake that changes the sprite raster area doesn't work; GP9001 sprite/layer priority is based on some experiments and isn't still fully understood).

Do these two particular aspects cause a tangible difference between MAME and the original PCBs? Just curious.

[mikejmoffitt]

Dangun Feveron's screen shake that changes the sprite raster area doesn't work; GP9001 sprite/layer priority is based on some experiments and isn't still fully understood).

Do these two particular aspects cause a tangible difference between MAME and the original PCBs? Just curious.

Well... Dangun Feveron is simply missing the screen shake in MAME, and when sprites should drop out and disappear, they don't in MAME. One good example is ESP Ra. De. after most bosses die; you can expect part or all of the energy stock bar to disappear momentarily on real hardware.

This is a case of "but the emulated one looks better!", and while that might be agreeable, I think that should be a conscious choice, not a benefit through coincidence of inaccurate emulation.

My worry with MiSTer is that the acceptance criteria will be "the players think it looks good", and so the cores will seldom go beyond that - I fear for reimplentations of MAME's understanding of the hardware dominating the developmental focus.

[Bassa-Bassa]

Interesting, thanks. Totally agree as well, of course - I kind of tried to make that point here yesterday indeed.


Edited - Does PS4 Feveron have the screen shake? Anybody compared it with MAME?

[ldeveraux]

I went to update my MiSTer for the first time in months and ran into issues. I have the USB board (v1.2), an extra SDRAM addon, a RTC addon, and the IO board (v4?). Apparently now the Mister.ini file sits on the root of the sd card. When I updated (really just flashed a new SD) the video ports will only work occasionally. It takes a while to lock video on HDMI and I couldn't get the VGA to my switch at all, said unsupported resolution. I tried playing around with the INI file, but couldn't really get anything reliable. TBH I never even had an INI file before, it was just running without it.

Ideally I'd like the HDMI and VGA out both active for no reason other than testing. I've seen a video where you can switch INI files on the fly, which is fine, but I couldn't get it working. I'm back to the main MiSTer core from August 2019 until I can figure out how to update properly without losing video. The online "guide" is sort of outdated and doesn't really cover my specific setup. Any advice?

[fernan1234]

You should be able to get video from both HDMI and I/O VGA simultaneously with the standard configuration with the current MiSTer binaries and menu core. On the ini file the only recommended change would be to set the HDMI output to 1080p, since the default is 720p. You only need to switch INI settings for output when you're getting direct video analogue from the HDMI out, which some people do to avoid needing an I/O board for analogue.

For those who haven't updated for a long time, it's often recommended to backup your games folder as well as configs for controllers if you want, and do a brand new install on the SD card using the latest SD card installer (or using the script on Linux or MacOS) and then running the updater script on MiSTer.

Also take note that the method of handling arcade cores and loading arcade ROMs has changed and has been made much more convenient and simple (using .mra files). I'd recommend looking into this.

[ldeveraux]

You should be able to get video from both HDMI and I/O VGA simultaneously with the standard configuration with the current MiSTer binaries and menu core. On the ini file the only recommended change would be to set the HDMI output to 1080p, since the default is 720p. You only need to switch INI settings for output when you're getting direct video analogue from the HDMI out, which some people do to avoid needing an I/O board for analogue.

Right, but it doesn't work. Is the Mister meant to power up completely even if there's no video cable connected? Because mine doesn't, and only occasionally does with just HDMI connected. I thought maybe the IO board was shorted or otherwise bad soldering causing problems, but wouldn't know how to begin checking that.

When I upgraded from my June 2019 working setup, I backed up the micro SD and flashed a completely new most recent build with their flash utility. I couldn't get anything to work reliably (HDMI, VGA) after hours of trying connections, INI settings, etc so I just flashed back my June build. Now HDMI works 100%, but still nothing on VGA. I don't know if this was before the INI file had to be in the root of the SD, but I don't even have an INI on this build. From August would that go in root of the card or in the "config" folder?

[paulb_nl]

On the ini file the only recommended change would be to set the HDMI output to 1080p, since the default is 720p.

It is quite important to set vsync_adjust=2 so you have zero lag and no stutter. Otherwise you get 2 frames latency.

[thrasherx]

Dangun Feveron's screen shake that changes the sprite raster area doesn't work; GP9001 sprite/layer priority is based on some experiments and isn't still fully understood).

Do these two particular aspects cause a tangible difference between MAME and the original PCBs? Just curious.

Well... Dangun Feveron is simply missing the screen shake in MAME, and when sprites should drop out and disappear, they don't in MAME. One good example is ESP Ra. De. after most bosses die; you can expect part or all of the energy stock bar to disappear momentarily on real hardware.

This is a case of "but the emulated one looks better!", and while that might be agreeable, I think that should be a conscious choice, not a benefit through coincidence of inaccurate emulation.

My worry with MiSTer is that the acceptance criteria will be "the players think it looks good", and so the cores will seldom go beyond that - I fear for reimplentations of MAME's understanding of the hardware dominating the developmental focus.

The arcade cores are a bit harder to deal with because they’re unique but most of the console cores have used rea hardware as reference and rely on the feedback and bug reporting of thousands of users. Few things will ever be perfect but at the point where the bug reports disappear, I’m not sure how to progress past that.

If you want 100% hardware accuracy, then original hardware is the only solution. But if you are okay with a solution that approaches 100% accuracy, has active development, receives new cores, and uses a unified frontend, scaler, input, etc then MiSTer is the device for you

The accuracy will always depend on the developer, of course.

[donluca]

The arcade cores are a bit harder to deal with because they’re unique but most of the console cores have used rea hardware as reference and rely on the feedback and bug reporting of thousands of users. Few things will ever be perfect but at the point where the bug reports disappear, I’m not sure how to progress past that.

Just wanted to chime in: Jotego's arcade cores are made by using a logic analyzer to check what each custom chip is doing by reading the inputs and outputs, which means he's "brute forcing" the chips to understand what they do and replicate exactly their behavior.

His cores should be perfect, save for some minor mistakes he can easily figure out and correct if anyone finds them and report to him.

[Bassa-Bassa]

For those using MiSTer on a 15khz CRT, has the GBA core the option to display at the native resolution and refresh rate (240x180 at 59.7275, or 240x240 with borders, for what it's worth)?

[fernan1234]

For those using MiSTer on a 15khz CRT, has the GBA core the option to display at the native resolution and refresh rate (240x180 at 59.7275, or 240x240 with borders, for what it's worth)?

Yes, it does. You may need to set "sync core to video" and/or some other setting on to get stable video via the direct video/IO analogue output.

[Bassa-Bassa]

Thank you.

[jandrogo]

Speaking about picture quality. What is your preferred scanline configuration for 1920x1080 non-crt screen?

I found comfortable with 50% horizontal scanlines and sometimes combined with 15 or 20% vertical scanlines (yes you can combine them) to emulate 14”crt tv

Still looking for a final config

[mario64]

On the ini file the only recommended change would be to set the HDMI output to 1080p, since the default is 720p.

It is quite important to set vsync_adjust=2 so you have zero lag and no stutter. Otherwise you get 2 frames latency.

Is vsync_adjust = 1 an acceptable compromise if your TV doesn’t like 2?

[Fudoh]

speaking of it, can someboy line out the difference between vsync 1 and 2 ? I don't think that I fully grabbed the difference from reading into it on the github.

From what I understand: contrary to Analogue's implementation, the cores themselves on the MiSTer always run at original speed, so there's no speed alteration to a straight 59.94 or 60Hz output, right? Vsync 0 performs a framerate conversion on the digital output, so you a recording friendly signal with slight hiccups due to inserted or dropped frames.

Vsync 1 or 2 both give you the original framerate on the HDMI output, but with slightly different signal timings due to the methods the timings are generated. I'd appreciate it, if somebody could elaborate on this one.

[tomwhite2004]

vsync_adjust=0 triple buffered (2 frames), 60hz (compatibility mode)

vsync_adjust=1 triple buffered (2 frames), native system's refresh (smoother)

vsync_adjust=2 single/sub-single buffer (0-1 frame), native system's refresh, synced

https://twitter.com/smokemonstertwi/sta ... 84?lang=en

[paulb_nl]

speaking of it, can someboy line out the difference between vsync 1 and 2 ? I don't think that I fully grabbed the difference from reading into it on the github.

Vsync 0 & 1 use a triple buffer so it they have 2 frames of latency where Vsync 0 sets the clock to the set video mode and Vsync 1 sets the refresh rate output as close to the source as possible for the least dropped frames.

Vsync 2 uses a single buffer but the scaler is constantly adjusting the HDMI clock to stay at most 5 lines away from the source so there are no dropped frames and there is at most 5 lines of latency.

[Fudoh]

So Vsync 2 is actually framelocked, while Vsync 1 imitates a framelock by setting the refresh as close to the original as it can without actually running framelocked ?

Where is the increased compatibility of vsync 1 over 2 coming from?

[paulb_nl]

So Vsync 2 is actually framelocked, while Vsync 1 imitates a framelock by setting the refresh as close to the original as it can without actually running framelocked ?

Yes so there are still dropped frames with Vsync 1 but not often of course.

Where is the increased compatibility of vsync 1 over 2 coming from?

The constant HDMI clock adjusting of Vsync 2 I would say. Maybe some devices are more tolerant against the varying clock speed.

My old Sony 40W4000 works fine with Vsync 2. Most devices should not have any problem with Vsync 2 vs Vsync 1 but there are dropouts when loading games in most cores.