86Box time tracking

[slamotas]

I'd thought 86Box wouldn't work with libTAS due to the UI, but I was able to get it to work recently by compiling 86Box without QT. The way I built it was (following https://86box.readthedocs.io/en/latest/dev/buildguide.html):

git clone https://github.com/86Box/86Box.git cmake -B /home/slamo/86box091222/ -S /home/slamo/86box091222/86Box/ -D QT=OFF -D CPPTHREADS=OFF cmake --build /home/slamo/86box091222/

(I'm unsure what CPPTHREADS does exactly, I was hoping it would help with single threading)

This results in an 86Box build without a UI, it just looks like a regular SDL2 window now. libTAS almost wants to play nice with it! The only problem is that it softlocks on frame 0. Normally some time tracking would fix this, but no cocktail of option seems to work. However, if you use uncontrolled time, it boots perfectly. It looks like it might want clock_gettime() but that doesn't help. Maybe there is some time option that hasn't been hooked yet?

[clementgallet]

This would need the same kind of modifications as PCem:

• main thread is doing events (inputs) processing, but another thread is doing the emulation, so inputs and frames won't be synced. Threads must be synced with mutexes, or code must be rewritten to remove the emulation thread
• there is a blit thread which should be synced with main thread
• time handling (decides when to run an emulation frame) is not deterministic, and is performed by emulation thread (should be main thread)

I could rewrite this if it does matter.

[slamotas]

That would be fantastic! I think it's wise to switch from using PCem to 86Box, since 86Box development is way more active and it emulates more machines, and it has a greater likelihood of implementing more advanced machines in the future.

[clementgallet]

Then maybe @vadosnaprimer can setup a fork on TASEmulators so that I can make the changes?

[vadosnaprimer]

Then maybe @vadosnaprimer can setup a fork on TASEmulators so that I can make the changes?

Invited! Ideally we'd ask them for something and they'd implement it. If they generally agree to have a feature but no one can work on it, then we'd send a patch. And only if they don't think a feature critical for us makes sense for them, we'd have to actually rely on our own fork. As always, please keep master even to upstream.

[clementgallet]

It would be difficult to present it like a feature, because it is basically making the emulator run slower (how much slower, I have no idea).

Looking at the code, it would be hard to keep both single-threaded and multithreaded possible options, without a lot of if statements, or lot of duplicate code. It is a big rewrite of some of the code (moving code around and removing all sync functions). I don't currently see how to not make the code look bad.

[vadosnaprimer]

Oh well, I think it's still worth a shot to ask what they think about it, in general. The benefit for them would not be direct of course, but people would be able to just use upstream to tas.

[clementgallet]

https://github.com/86Box/86Box/issues/2687

[clementgallet]

I forgot to tell that we would also need to patch all video drivers that use threading (voodoo, s3virge, etc.)

[vadosnaprimer]

86Box/86Box#2687

Thank you!!!