Indeed, there are no executables for any platforms. However, there are two things that you can use (well, especially the second one):
* the source code, but you need to figure out how to compile it yourself;
* the binary diffs explicitly mentioned in the README along with the software that applies them ("now distributing binary diffs suitable for xdelta 1.x, xdelta 3.x and bsdiff").


I have now created the Git repository for tiosmod, at http://github.com/debrouxl/tiosmod . But I haven't tested the shrinking of AMS 2.09 for 89 more thoroughly, and won't have time do so tonight.


[EDIT 20100916: I have now transferred the shrunk AMS 2.09 to my testing calculator, and certain operations in the Graph screen don't yield the appropriate result, or even corrupt memory and destabilize the calculator. Don't use the shrunk AMS 2.09 until it is fixed !]

Nice

From the updated README:

Users just interested in testing patchsets should use the binary diffs with the program whose name is indicated by the binary diff's extension.

Yeah but I think he wants to know what is a binary diff.

Well, free online information sources such as http://en.wikipedia.org/wiki/Diff give much more information than one needs to know for the specific purpose of patching TI-68k OS

(read: he is used to just double-clicking an executable and fill forms)

If someone made graphical frontends to the binary patching (the reverse operation of diffing) programs that can work with the binary diffs I provided, he can do that
If no such frontends exist, well, using the command line is a good occasion of increasing one's computer skills. Many people think that the command line is a complicated piece of evil coming from the past... their loss, because the command line can be a way to save time: some operations are faster when done through the command line, and automation is easier than that of GUIs.

A Qt GUI has been written for the TNOC program, which shrinks Nspire OS upgrades by removing the boot2 update (superfluous once the calculator's boot2 has been upgraded to 1.4.x) and samples from them.
But the patcher + patchset program we're talking about in this topic is of a different kind: it performs modifications that TI actively objects to: nullifying the protections they added, or even shrinking the OS (they could easily have done that themselves, but they probably chose not to, as a way to promote buying V200 and 89T). As such, the patcher + patchset is not going to be distributed in binary form (at least, by the original authors - if other people want to risk legal action from TI on their hosting provider, go ahead), and neither would be a GUI for the patcher + patchset. Binary diffs that users get to apply themselves on the one side, and source code that users get to compile themselves on the other side, are about as far as we can go (and it's not even sure we should distribute both together - to that effect, I have put the binary diffs in their own ZIP, so that it can be easily extracted).

TI could not, however, attack a GUI program for any of the three generic binary patcher programs that can be used to apply the binary diffs resulting of diffing between TI's official version and the patched version as created by the patcher + patchset posted in this topic. But maybe one already exists anyway.

Yeah but I think he wants to know what is a binary diff. He is not tech-savy on that stuff (read: he is used to just double-clicking an executable and fill forms)

LIES!

Anywho, I still dont understand how to apply the diffs

Uploaded v0.2.3b, which replaces one of AMS' traps (~software interrupts) by something useful, in order to fix a glaring bug in AMS: this trap is wired to a normal function, accessible through other means, which has a calling & returning convention for normal functions - but traps are no normal functions...

Even if the difference in calling convention can be overcome by writing the arguments to an exceedingly strange place (with the default value of the supervisor stack pointer, inside the display memory ), the difference in returning convention cannot be overcome by normal means (perhaps with the Tracing bit, but I'm not sure that this bit, which I've never used, survives the switch into supervisor mode performed by the trap), and the calculator will crash upon returning from the function... To sum up, the trap #3 in AMS is just plain unusable.

The replacement for TI's buggy trap #3 is the one that has been provided for many years by UniOS and PreOS: a HeapDeref (given a HANDLE, return the absolute address of the corresponding block of memory) with proper calling & returning convention.

traps are the 68000's software interrupts. There are 16 traps, about half of them being unused by AMS.
On TI-68k calculators, the hardware interrupts are usually called "auto-ints", but they're hardware interrupts.