Omnimaga
Calculator Community => TI Calculators => General Calculator Help => Topic started by: ruler501 on May 13, 2011, 09:12:42 am
-
i have downgraded my Nspire from 3.0 to 2.0.1 hoping to use OSLauncher to play with CAS. How can I do this? The article on TI-Bank is a pdf and google translate had problems with it(said it was too large and couldn't translate). Iw ould love it if someone would just tell me how to do this. I would like the CAs to help me with the math I do. I would not use it to cheat on tests. My teacher makes me use the 84+keypad anyways on tests.
I currently have a touchpad Nspire nonCAS with OS 2.0.1
-
Use 7zip (or other file unzipping software) to extract the Ti-Nspire.img from the desired operating system. Then, use the program unSpire (it's in the news section) to convert that img file into phoenix.zip.raw.tns. Transfer that file to your calc. Put it in the same folder as OSlauncher and hope for the best. It only works on about one out of two calcs. It doesn't work on mine, but it may work on yours. Make sure to use a similar OS, as stated in the pdf.
-
Where is the download for OSLauncher?
-
Where is the download for OSLauncher?
I was also wondering about that. ???
-
It's on both ticalc.org and TI-Bank ;)
-
It's on both ticalc.org and TI-Bank ;)
Figured, just couldn't find it there.
-
thank you I will go try that now.
eDIT:I downloaded OSLauncher off of ticalc but It is a C file with a make file. when I tried to compile it said nspire-gcc was not available. what do I need to do?
-
thank you I will go try that now.
eDIT:I downloaded OSLauncher off of ticalc but It is a C file with a make file. when I tried to compile it said nspire-gcc was not available. what do I need to do?
You'll need Windows XP or later, mSYS, and a modified variable somewhere. Sadly, I forgot how to do this.
-
I have Linux Mint 10 and want to know how to do this. when i tried it off of hackspire the instructions didn't work. anyone know how to get it to work on linux mint(basically an improved version of ubuntu imo)
-
In order to install a toolchain suitable for the Nspire, I used a modified version of http://blog.nutaksas.com/2009/05/installing-gnuarm-arm-toolchain-on.html . I upgraded the dependencies' versions, and I used only the first part of the script, until Atmel-specific stuff begins, i.e.
cd ..
mkdir Sam_I_Am
etc.
Lately, on one of the EFNet chans (probably #omnimaga), broooom mentioned summon-arm-toolchain: https://github.com/esden/summon-arm-toolchain . It may require some configuration as well.
EDIT: I have posted the script I used, after improving it to stop upon the first error: http://hackspire.unsads.com/wiki/index.php/C_and_assembly_development_introduction#On_other_Linux_distributions
-
IIRC, the TI-Bank version doesn't need any compiling.
-
Could you give me a link to the TI-Bank one? I don't read french so it would be kind of hard for me to find.
-
http://ti.bank.free.fr/index.php?mod=archives&ac=voir&id=3223 .
And the inordinately high download count is largely a result of script attacks on TI-Bank against various programs released in the same time frame. I think the download count of OSLauncher was already fixed once...
-
So all I need to do is put OSLauncher and the img for the OS I want to run in the same folder and it should work?
-
So all I need to do is put OSLauncher and the img for the OS I want to run in the same folder and it should work?
It might work,
I couldn't get it working on my nspire clickpad non-cas =/
and you must give the .raw's name as described in the path of the sourcecode. ..
-
Yeah! I got it to work after many tries, just to notice that i had to downgrade to 2.0.1.60!!!
I had 2.1.0.631 and I got stuck at the black screen with the watch on it. (Should have RTFM... but hey! There isn't one:)
In the emulator this was the last message it printed in the console:
(nonCas)
* P3 mode battery door detection
(Cas)
* P1R2 mode battery door detection
However 2.1.0.631 CAS did startup ONCE in the emulator and show "* P3 mode battery door detection". Which I don't know what it means. I might have a bash at making 2.1 work but with 3.0 out I might check that one out.
Now I am a happy bunnie! :w00t: Even though I have 2.0.1.60, but I guess there's not much difference to 2.1 couldn't find quickly the release notes for 2.1 to see whats the difference between them...
Thanks Lionel for OSL, Goplat for the emu and all the other ppl who worked on NDless and opened up this platform!
You ROCK! :thumbsup:
-
Indeed, there's no manual distributed alongside OSLauncher. I wasn't going to officially describe how to run the CAS OS on the machine sold as non-CAS, but perfectly CAS-capable :)
TI-Planet, which replaces TI-Bank, is now online, so you can find OSLauncher, the program for decompressing boot2 and decrypting the OS suitable for Clickpad & Touchpad :)
-
Indeed, there's no manual distributed alongside OSLauncher. I wasn't going to officially describe how to run the CAS OS on the machine sold as non-CAS, but perfectly CAS-capable :)
I know, I meant it as a joke...
TI-Planet, which replaces TI-Bank, is now online, so you can find OSLauncher, the program for decompressing boot2 and decrypting the OS suitable for Clickpad & Touchpad :)
Yeah I know about TIPlanet, but I had to do it the hard way with GDB and all that!
In any case, it's awesome that it works!
-
Does OSLauncher support 3.0.2 so I can put both 2.1 and 3.0.2?
-
Since OSLauncher doesn't need to worry about signing (Since you can just run any boot2 you want) couldn't we try out some OS mods with this? I bet the OS itself (nucleus RTOS and its gui) support a ton of stuff TI cut out, like having other types of applications, or shells.
Remember OS 1.2, from the old prototypes? That actually had some pretty cool features in it.
-
Due to the way TI made their OS, launching a different OS version (e.g. CAS 2.1.0.631 on non-CAS 1.7.2741) fails for most versions. So it's probably safe to say that OSLauncher does not support OS 3.0.1.1753 and 3.0.2.1791.
And yes, OSLauncher-type programs could perform arbitrary patching before launching the OS.
This has use cases that obviously belong to the well-acknowledged right to do what we want with the hardware we own, such as installing Ndless. However, other usages, such as a weak form of faking the PTT mode (which would not resist to reboot anyway), ought to be possible as well.
-
well, there are plenty of other reasons to want to patch the OS as well, like the AMS patches for the 89 that fixed bugs and increased speed.
So wait, if it can't boot other OS versions....doesn't that mean CAS on non-CAS (or vice versa) is its only current purpose? :P
-
well, there are plenty of other reasons to want to patch the OS as well, like the AMS patches for the 89 that fixed bugs and increased speed.
Indeed. But with Phoenix, we are very far from the level of familiarity that we have with AMS.
So wait, if it can't boot other OS versions....doesn't that mean CAS on non-CAS (or vice versa) is its only current purpose?
Theoretically, the purpose of OSLauncher is booting arbitrary OS. I have purposefully released a toy OS at the same time as OSLauncher, named DummyOS :)
But since DummyOS is completely useless, for practical matters, the main purpose of OSLauncher is, indeed, launching Phoenix version x from Phoenix version x. AFAIK, nobody has tried to find exactly why launching Phoenix version y from Phoenix version x, with x != y, fails, but a possible cause is known: mismatches between the OS and the other files in the filesystem, e.g. the string IDs of the commands...
On AMS, TI kept the string IDs consistent across AMS versions, added new strings at the end, and provided the XR_stringPtr ROM_CALL for themselves, and users, to get the localized string corresponding to the given ID...
However, on Phoenix, examining primary_tag_list shows that the string IDs change from one version to another. This is yet another proof that Phoenix is explicitly designed and implemented in order to make native code programming hard...
-
I did some testing and I got some weird results for OS 2.1.
On 2.0.1, OSLauncher successfully launched 2.0.1 CAS every time. However, on OS 2.1, it refused to launch both the 2.1 CAS and 2.1 non-CAS.
-
Well, maybe there's a good reason for the changing string IDs, such as keeping them alphabetically sorted even when you add new ones. Plus, if the SDK they use is updated for every release, then it would stay code compatible.
I wish it could just run linux :P
-
Well, maybe there's a good reason for the changing string IDs, such as keeping them alphabetically sorted even when you add new ones.
That's probably what they do indeed. But it completely breaks direct backwards compatibility (which, from the user's point of view, is usually a desirable feature).
Plus, if the SDK they use is updated for every release, then it would stay code compatible.
Yes, but only after rebuild, unlike the TI-68k series.
-
But, they don't have any intended third party developers anyways, so they don't really care if they throw us a loop once in a while by accident.
The 68k line, on the other hand, was open to 3rd party asm programming for a long time.