Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI-Nspire => Topic started by: hoffa on September 22, 2012, 07:26:34 pm
-
Many people have trouble setting up their TI-Nspire emulator. Numerous cases of worried moms and fractured frontal bones have been reported as a direct consequence of that very fact.
The time has come for me to step out of my cave and help my comrades out of their misery!
As such, I now deliver to you a single-executable no-bullshit Ndless-already-installed CX-and-Touchpad/Clickpad TI-Nspire emulator! It's isn't even the first of April!
Screenshot for the interested:
(http://i.imgur.com/Njzqi.png)
It is very much based on Goplat's wonderful nspire_emu, as you might have guessed.
Latest version: 0.1 (EDIT: I need to update the Ndless to the newest one, as with some programs the emulator reboots. I'll do it shortly)
No instructions needed, just launch the executable and enjoy the ride. Both have Ndless already installed and are completely clean otherwise. I'll keep 'em updated.
Have fun! :)
EDIT (by Deep Thought): Removed links. They're basically emulators with ROM images packed inside.
-
Is there a version for Mac?
I don't use windows :'(
-
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.
-
Double-clicking didn't work for me—it gives an "Invalid Argument" error.
Anyway, as adriweb said it's illegal to distribute the boot1 to people who don't own the physical device (I do), so I removed the links as part of that no-ROM-image-linking policy.
-
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.
-
There was already karmTI by SpiroH (http://ourl.ca/16585) that made life easier with setting the Nspire emulator. It even supports skins and gif recording ;)
Anyway, now that there is concurrence, I guess that both projects will try their best to improve, and we'll soon see a Nspire emu that is as good as Wabbit for the z80, so good luck with your project :D
-
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.
-
I was only interested in removing the burden of boot1 & co. from the users, but apparently it won't suit here in its current form, so I'm not looking forward to doing anything else about it really (I could always circumvent the legal issues but I'm not interested in playing hide and seek). This was something I hacked together in one night, and I don't have more time to invest.
-
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 ;)
-
I was only interested in removing the burden of boot1 & co. from the users, but apparently it won't suit here in its current form, so I'm not looking forward to doing anything else about it really (I could always circumvent the legal issues but I'm not interested in playing hide and seek). This was something I hacked together in one night, and I don't have more time to invest.
Yeah, DMCAs are not pretty for us here. Web hosting companies tend to freak out, and shut off a customer's service altogether, even if the DMCA turns out to be wrong.
A long term solution would be to have a wizard like Wabbitemu has - either make a ROM from the OS (assuming a community boot1 is made), or dump a ROM. And of course, forgo the usual CLI arguments and load up the emulator with the previous settings immediately. (Of course, CLI arguments will still be supported.)
-
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*.
-
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.
It's obvious that it would be better if they were open source. But why don't you make your version public? Debugging features would help the development community very much, wouldn't they?
-
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.
-
Now if only over USA it was more lax like in France. On French sites, you can host any ROM of any kind without fearing any legal action in most cases. >.<