F-Secure is blocking emulator r39

svenvandevelde · Post by **svenvandevelde** » Mon Apr 11, 2022 7:35 pm

On 4/11/2022 at 2:52 PM, Johan Kårlin said:

1. I have VS2022 so I upgraded the project. Maybe I have to install VS2019?

Not an issue at all.

On 4/11/2022 at 2:52 PM, Johan Kårlin said:

2. Should I compile the latest version of the source files or go for the latest release from last year?

Please compile the latest version of the Source Code that you forked.

On 4/11/2022 at 2:52 PM, Johan Kårlin said:

3. Does rom.bin from the official release 39 of the emulator work? (It seems to work.

Yup. It works and maybe better than in the official emulator.

On 4/11/2022 at 2:52 PM, Johan Kårlin said:

4. If I get this working, is it compaitble with the official r39? After all, the reason for doing this is to upgrade my programs to work with this release.

I'm having exactly the same question and I really don't know. I think the r39 has the ground level architecture defined, but there are optimizations needed on the rom design and bug solving will be required to get it stable until the roms are burned.

StephenHorn · Post by **StephenHorn** » Tue Apr 12, 2022 12:46 am

If you grab the latest source code, Box16 should be fully compatible with r39's official ROM. That said, I'm still recovering from a fairly extended period of crunch, so I'm only 95% confident that it's fully compatible... mea culpa, the recent burst of activity has just had the worst timing relative to the demands of my dayjob.

StephenHorn · Post by **StephenHorn** » Tue Apr 12, 2022 2:57 am

On 4/11/2022 at 7:52 AM, Johan Kårlin said:

It starts without F-Secure complaining about it, there is some information in a first window but then a completely white and blank window opens and nothing more happens.

Some more questions if you have the paticence:

1. I have VS2022 so I upgraded the project. Maybe I have to install VS2019?

2. Should I compile the latest version of the source files or go for the latest release from last year?

3. Does rom.bin from the official release 39 of the emulator work? (It seems to work.)

4. If I get this working, is it compaitble with the official r39? After all, the reason for doing this is to upgrade my programs to work with this release.

On 4/11/2022 at 12:37 PM, desertfish said:

This has occurred for other people as well, usually it was related to incompatibilities in the integrated graphics card of a laptop. Are you on a laptop? Try forcing the use of the discrete graphics card for box16 (if your laptop has one of these)

For now, try running box16 with the "-vsync none" command line argument.

As for the questions:

1. The upgrade should be fine, I've got VS2022 installed as well and had no problems upgrading the solution. I'm dithering over whether to commit the upgrade into Github because it was so painless, but I probably should and just update the README.md to direct folks to install VS2022.

2. In general, I would recommend compiling from latest source, and the only reason I'd go back is if the latest source is broken for some reason (at which point, please let me know).

3. As I mentioned in my first, more hasty reply above, Box16 should be up-to-date to run the official rom.bin from r39. That's the rom I'm working with now.

4. I believe latest source code for Box16 should be fully compatible with r39. I need to roll new zips, tweak the README and a few other details, but I would plan to release nr39.3 soon™.

StephenHorn · Post by **StephenHorn** » Tue Apr 12, 2022 2:58 am

If "-vsync none" doesn't help, that's helpful to know as well.

svenvandevelde · Post by **svenvandevelde** » Tue Apr 12, 2022 8:32 am

On 4/12/2022 at 2:46 AM, StephenHorn said:

If you grab the latest source code, Box16 should be fully compatible with r39's official ROM. That said, I'm still recovering from a fairly extended period of crunch, so I'm only 95% confident that it's fully compatible... mea culpa, the recent burst of activity has just had the worst timing relative to the demands of my dayjob.

Take your time Stephen. I had contracted Omikron last week and was out too. It's all just a hobby.

Johan Kårlin · Post by **Johan Kårlin** » Tue Apr 12, 2022 6:32 pm

It all works perfectly fine now! I compiled the latest source code with VS2022, copied the latest rom.bin from the official emulator and used the -vsync none option. Thanks all for your help, it is much appreciated!

And Stephen, Box16 seems absolutely great. There are debugging possibilites and other improvements that I have been dreaming about. Fantastic job. I will report if I find anything broken.

StephenHorn · Post by **StephenHorn** » Thu Apr 14, 2022 2:26 am

On 4/12/2022 at 1:32 PM, Johan Kårlin said:

And Stephen, Box16 seems absolutely great. There are debugging possibilites and other improvements that I have been dreaming about. Fantastic job. I will report if I find anything broken.

I appreciate that! And I'll be continuing to support Box16. Fixing the the vsync situation, in particular, is high on my list of bugs to fix. The problem is that I don't appear to have a good way of detecting when a driver doesn't support the API functions I'm depending on there, so I'll have to do something... creative.

AndyMt · Post by **AndyMt** » Thu Apr 14, 2022 6:43 am

On 4/14/2022 at 4:26 AM, StephenHorn said:

The problem is that I don't appear to have a good way of detecting when a driver doesn't support the API functions I'm depending on there, so I'll have to do something... creative.

I remember this issue from a few years ago. Intel HD Graphics 520 and 620 (or their drivers) seem to cause this issue. See this article here:

https://discourse.glfw.org/t/most-frames-are-not-drawn-on-intel-graphics-and-windows-10/1395

Don't know if this helps to solve the issue. According to your source code you already use glFenceSync() in combination with glClientWait(), but maybe try with glfwPollEvents() as suggested in the post above.

StephenHorn · Post by **StephenHorn** » Thu Apr 14, 2022 8:32 pm

I committed a change to Box16 last night (or maybe this morning? It's high noon somewhere...) that will hopefully improve detection when my V-sync technique fails, and will disable V-sync entirely if no new frames are rendered within 5 seconds of it being enabled (or 5 seconds of the emulator being opened if V-sync is enabled with an ini file or command-line option). It could probably still use some iteration, but it's hopefully better than nothing, and will make "-vsync none" unnecessary.

But I will also check out that thread @AndyMt, thanks for pointing that out.