Cool

It should work fine with Wine, Crossover....  directly
(as it did with nspire_emu)

Anyway nice job hoffa, this is indeed quite easy, just tested and it works well - just a double click is required !
The only issue being the legality of this for people who don't actually own a device and thus don't normally have access to a boot1.

I suggest anyone wanting to make Nspire emulators to 1) get in touch with upstream (Goplat, ExtendeD, myself, etc.) and 2) provide the source code.

Anyway, now that there is concurrence, I guess that both projects will try their best to improve,

Well, the first, sine qua non improvements for forks would be to 1) communicate with upstream and 2) open source stuff, in such a way that these forks can (at long last, for kArmTI, which brings some useful improvements to users, but lacks killer developer features) be considered alive branches in the nspire_emu evolutionary tree

Both kArmTI and Nemu are based on outdated versions of nspire_emu, so it seems clear that their authors haven't communicated with upstream (unlike ExtendeD, AFAICT, and I), even after being made aware of the fact that their work is based on an outdated version of nspire_emu (hoffa may well have missed the topics, but SpiroH is perfectly informed).
Since neither kArmTI nor Nemu are open source, nobody can upgrade the code in lieu of their authors (assuming somebody is willing to do the work that SpiroH and hoffa neglected to do).


For the record: like the previous times I brought the matter forward, all I want is a single Nspire emulator that provides the best features to both users (for that purpose, kArmTI is the lead) and developers (for that purpose, upstream nspire_emu wins, since ncubate_emu was merged there months ago). And unlike ExtendeD for ncubate_emu, who kept his fork open source (and that's precisely why made it possible for me to port the changes it contains to upstream), SpiroH is not helping for kArmTI.

That's OK, and I know you don't have much time
But it's not the first time Omnimaga censors you for posting some things, so you should be more careful

either make a ROM from the OS (assuming a community boot1 is made),

From a legal POV, a community boot1 wouldn't necessarily help that much, as it faces the same problem as imgmanip: distributing decryption keys is, sadly, legally dubious in some countries...

or dump a ROM.

In the general case, this is not (always) possible, as polydumper requires arbitrary native code execution on the OS, which we don't have in an uninterrupted manner. A bit more automation would be possible through the integration (and likely modification) of libti*.

But why don't you make your version public?

Well, I'm not the maintainer of nspire_emu, and AFAICT, Goplat hasn't indicated that he did no longer want to maintain nspire_emu
Anyone who already has it (at least a dozen persons) could indeed publish the version - but it will feel like a step back to those who switched to kArmTI, which was published, out of the blue, after I worked on nspire_emu.
The only proper solution is that kArmTI becomes open source, so that people can benefit from the best of both worlds (user features and developer features) in a single, open source tree.
If SpiroH goes away, for a reason or another (hard drive crash without backups, lack of time, loss of interest, accident, illness, etc. - people frequently underestimate the chance of bad things !), users will be left with an unmaintained piece of closed source software (which originated from a piece of open source software). That's a highly undesirable outcome, and I think we should all push for this not to happen.
I've attended the TI open development community for about 11 years and a half, and I've seen way too many projects stopped because of one of the reasons I've just mentioned. Hard drive crashes is the most frequent source of losses; as far as the Nspire is concerned, it has cost us a TI-68k emulator, easier maintenance of the GB/GBC emulators, and certainly other things I forget about at the moment. With more backups, or preferably publishing the code, that could have been avoided.

Debugging features would help the development community very much, wouldn't they?

That's one of the motivations behind me forward porting the changes from ncubate_emu.
That said, hardly anybody cares about the Nspire in general, and the addition of a GDBstub to an emulator is very far from being enough to change this state of fact... I'm afraid that the only way to change things is TI fully opening the platform, and we all know that this won't happen, as sad (for both them and us) as it is.