Update loaders for Ghidra 12.x Loader API

[tomconte]

Ghidra 12 changed the Loader interface — load() now takes a single Loader.ImporterSettings record instead of the old (ByteProvider, LoadSpec, List<Option>, Program, TaskMonitor, MessageLog) params. This updates every loader's load() (and Trs80Model100RlcLoader's getDefaultOptions, which gained a mirrorFsLayout param) to match, so the extension builds and runs again on 12.x. Should be a no-op behavior-wise, just signature plumbing.

While I was in there testing with real Atari ST binaries, I also hit a latent bug in AtariStLoader/X68KXLoader/X68KZLoader: they query the opinion file for any 68000-family language, which on my Ghidra install resolves to 4 installed variants (default, MC68020, MC68030, Coldfire) with no defined ordering. In the GUI this shows up as an unexpected language/compiler picker on import, and headless import silently picked Coldfire, which isn't right for real ST/X68000 68000 CPUs. Hardcoded 68000:BE:32:default instead, matching what ClassicMacResourceForkLoader and AppleLisaObjectFileLoader already do, and dropped the now-dead opinion file entries for these three.

Tested by building against Ghidra 12.1.2 and running headless imports of a couple of real Atari ST .PRG files — Atari ST loader and the right language now get picked automatically and the binaries load and disassemble cleanly.

Heads up on compatibility: this only builds against Ghidra 12.x... 11.x users aren't stuck, since the existing v0.0.1 release predates this and still works fine for them, but main itself would only target 12.x from here on. Wanted to flag that trade-off rather than have it land as a surprise — happy to also update the CI matrix to 12.x in this PR if that's the direction you want, or rework this differently if you'd rather keep 11.x building on main.

[hippietrail]

Thanks so much for this!

While I was in there testing with real Atari ST binaries, I also hit a latent bug in AtariStLoader/X68KXLoader/X68KZLoader: they query the opinion file for any 68000-family language, which on my Ghidra install resolves to 4 installed variants (default, MC68020, MC68030, Coldfire) with no defined ordering. In the GUI this shows up as an unexpected language/compiler picker on import, and headless import silently picked Coldfire, which isn't right for real ST/X68000 68000 CPUs. Hardcoded 68000:BE:32:default instead, matching what ClassicMacResourceForkLoader and AppleLisaObjectFileLoader already do, and dropped the now-dead opinion file entries for these three.

I haven't touched this in over a year and don't even have Ghidra installed at the moment so I'm a bit vague on some things so pardon my dumb question but I just want to make sure that in non-headless mode a user can still choose '020 or '030 for ST files since unlike the X68000 and Lisa there were machines with upgraded CPUs and probably 3rd party accelerators too? I do remember that I doubled checked that those other machines never had fancier CPUs.

When I was working on this I never tried running headless.

Heads up on compatibility: this only builds against Ghidra 12.x... 11.x users aren't stuck, since the existing v0.0.1 release predates this and still works fine for them, but main itself would only target 12.x from here on. Wanted to flag that trade-off rather than have it land as a surprise — happy to also update the CI matrix to 12.x in this PR if that's the direction you want, or rework this differently if you'd rather keep 11.x building on main.

That should be fine as I don't think there's many active users.

[tomconte]

Good catch — you're right, that was an overcorrection. The actual bug was only that Coldfire was sneaking into the candidate list (no ST ever had one); MC68020/MC68030 are legit for TT/Falcon030 and accelerator-card setups, so I've restored those as selectable options, just with default preferred. Pushed.

Have you tested it works?

For the Ghidra 11→12 thing, I'll leave the CI matrix as-is for now and let you decide how you want to handle that whenever you get a chance to look at it again.

I suck at CI. Another user contributed it a few months ago and I trusted them as the community is only a tiny handful of people.

[tomconte]

Yes, tested! Built against 12.1.2, imported a couple of real .PRG files both in the GUI and headless — the Atari ST loader gets picked automatically and the binaries disassemble cleanly with the right language. The 020/030 options show up in the GUI picker as expected.

Also added the CI matrix update in the latest commit, so the build now covers 12.0 through 12.1.2 instead of the old 11.x range (which would all fail against the new API anyway).

One thing to know: because this PR comes from a fork, GitHub won't run the CI automatically — it needs a one-time approval from you. You should see a yellow banner on the PR's Checks tab saying something like "Workflow runs from fork pull requests require approval" with an Approve and run button. Just a click and it'll kick off.