Add defines, build pipeline, minor fixes

[midwan]

The main purpose of this PR, is to add #ifdef statements where needed, to control various aspects of the emulation centrally (in sysconfig.h). Most of those defines already existed, but were not used everywhere they should. A few are new ones, with the same purpose.

I've been using these in Amiberry for quite a while, so I think it would be good to send them upstream so we can have the code a bit more easy to sync.

Some minor fixes are also included, but I've kept those to a minimal.
This also brings in the build pipeline I had set up, though. I've had it running for a few months now, and didn't notice any issues, but if that's a problem for you, let me know.

[tonioni]

Sorry, not going to do anything until new custom emulation core is usable (which changes a lot). At least few months more.

[midwan]

Alright, I'll close this then, and we can revisit it when the new code is there.

[tonioni]

Rewritten chipset emulation is now in. This update can continue now.

Can automated builds also create official betas + debug symbol files? And also optionally builds with different settings, like different CPU feature requirements? (I don't want to know too much about that stuff as usually :))

[midwan]

Great news, just in time also (I was getting Amiberry v7 ready to release, now I have to merge the changes in :D )

Automated builds can certainly be used for betas - you can use the Github "Pre-Release" option for those and use it for proper releases when the time comes (which would be normal "Releases" for Github). I personally use git tags to specify what I want to be released, and I let the workflow do the job automatically.

Creating debug builds is also possible and could be done as part of the same process (ending up in a separate binary with debug symbols) or in a separate workflow, depending on how you want it. Anything you could specify from the command line when building it, in other words (e.g. a different Visual Studio config, Release, Test, Debug, etc).

Not entirely sure what you mean by different CPU feature requirements, but again - if it can be specified from the command line with options to the MSBuild step, it can certainly be done.

I'll take care of updating the PR after resolving the conflicts, in the meantime.

[rofl0r]

(I was getting Amiberry v7 ready to release, now I have to merge the changes in :D )

reading the changelog, the changes made appear to (temporarily, at least) significantly shift the scale from speed to accuracy, so it might be be a good idea to make the planned release using the old codebase, before digging into the new code.

[midwan]

Yes, indeed, after reading through the changes, I'll keep the release with the previous code for now.

I can merge some parts at least.

[tonioni]

Automated builds can certainly be used for betas - you can use the Github "Pre-Release" option for those and use it for proper releases when the time comes (which would be normal "Releases" for Github). I personally use git tags to specify what I want to be released, and I let the workflow do the job automatically.

git tags works fine for that.

Creating debug builds is also possible and could be done as part of the same process (ending up in a separate binary with debug symbols) or in a separate workflow, depending on how you want it. Anything you could specify from the command line when building it, in other words (e.g. a different Visual Studio config, Release, Test, Debug, etc).

I don't mean debug builds. Just normal release build + matching (huge) symbol file automatically stored somewhere.

Not entirely sure what you mean by different CPU feature requirements, but again - if it can be specified from the command line with options to the MSBuild step, it can certainly be done.

I mean options like AVX enabled or not. Because I decided to have AVX2 requirement in official betas but someone surely wants non-AVX2 versions even if isn't optimal. ("Requirement" because in my opinion older CPUs are too slow and I don't want to care about those until things stabilize)

[rofl0r]

in my opinion older CPUs are too slow and I don't want to care about those until things stabilize

too slow for what? emulating an A500?
i think the main point of midwan's fork is to run on low-powered ARM devices (and those naturally come without x86's AVX).

[midwan]

I don't mean debug builds. Just normal release build + matching (huge) symbol file automatically stored somewhere.

If you're referring to the winuae.pbd file, that's generated in the output bin directory, then yes. That could be picked up and packaged as a separate file, alongside the release.

Not entirely sure what you mean by different CPU feature requirements, but again - if it can be specified from the command line with options to the MSBuild step, it can certainly be done.

I mean options like AVX enabled or not. Because I decided to have AVX2 requirement in official betas but someone surely wants non-AVX2 versions even if isn't optimal. ("Requirement" because in my opinion older CPUs are too slow and I don't want to care about those until things stabilize)

Sure, that sounds possible as well. I assume you'll have these options as either Configurations in VS or perhaps they can be overridden manually from the command line? In any case, it's doable without too much trouble (we can just add a few more lines in the workflow, to produce separate builds for each configuration - then package each one in a separate filename).

[midwan]

in my opinion older CPUs are too slow and I don't want to care about those until things stabilize

too slow for what? emulating an A500? i think the main point of midwan's fork is to run on low-powered ARM devices (and those naturally come without x86's AVX).

That doesn't affect Amiberry, which is a separate project. :)

[tonioni]

Too slow when weird/fast CPU configs are used that some users will use. Normal A500/A1200 configs should still run just fine. But there is still things left to optimize but only after core really works. (and ARM has their own equivalent instruction extensions).. I am just not interested in hearing (just yet) if someone complains that is slow because they use CPU from the 2010.