Yes, this is the long-awaited TICT official release of ttstart.
As usual, it contains binaries and sources.
Special thanks to Samuel Stearley for the new PPG decompression routines:
* one is faster and saves a number of bytes, especially when the extremely rarely used 
(if at all, PpHd told me about several files but never showed me them - and I think 
they're unlikely to work on the recent calculator models)
delta-LZ decompressing code is not inclued in the pstarters, but it must be in the 
ttstarts for the above reasons.
* the other one is slower (several tests show 30-50% slower than the previous version, 
more than twice slower than the fast version) and saves even more space. See below.
Sam's work is definitely a great achievement, and fullfills a wonderful challenge.

Note that the pstarters are still there, with a batchfile to generate them (mkpstart.bat), 
but starting from the last TIGCC 0.95 betas, they are not directly usable with TIGCC, as 
TIGCC now unfortunately generates only ttstart-universal instead of generating all three 
launchers if the programmer wants to. This means that compressed 92+/V200-only programs 
have to include the TI-89T support code - so much for saving space...
However, of course, I advise using these betas and TIGCC 0.95 Final, since a number of 
more or less nasty bugs were fixed through those versions.
Anyway, custom decompressors (specific launchers) are one of the easiest ways to waste 
kilobytes of memory. See below.
If you want to generate all four launchers for your programs (you should !):
* use mklncppg.bat to create launchers for a PPG program;
* use mklncasm.bat to create launchers for a large ASM program (no titanium launcher 
will be generated, since such a launcher is useless on Titaniums).
mkttstrt.bat generates the generic ttstarts.
All those batchfiles have to work around tigcc now deleting every executable whose 
name ends with "-titanium"...


Although it may not be extremely useful in practice, I inclued the slow routine since 
it's nearly certain that it will replace the current ttstart-universal in future TIGCC 
versions ! This is the only way I could find to have users and programmers know in 
practice and a bit in advance what they may have to cope with soon, which enables 
them to make up their mind on ttstart-slow.
The real questions are:
* do they find acceptable to increase significantly decompressing times (30-50% 
compared to the previous launcher, but more than twice compared to the fast version) 
in order to save only a few percents over the size (TI-Chess: less than 2%; Venus: 
less than 3%; nearly any compressed program: less than 10%) ?
* do they like being compelled to use only one kind of things (which Kevin already 
did once for launchers, looks like he's going to do it again) ?

IMO, using a compression routine optimized for size to the insane is simply addressing 
a non-issue: a single custom decompressor wastes more than three times what the slow 
decompression routine saves ! Not to mention that:
* the workaround the AMS twin symbol deleting bug eats up ~130 bytes by occurrence, 
and I'm almost sure that too many functions require it. Indeed, the fix has always 
been disabled in ebook. Has anyone ever seen ebook crashing due to that bug ?
* the TI-89T support eats up roughly ~150 bytes - pure waste in on-calc-incompatible 
(read: efficient size-wise and speed-wise, but Kevin fights them in unfair ways too) 
92+/V200-only programs.

Read the long topics about ttstart on http://pub26.ezboard.com/ftichessteamhqfrm10 if 
you don't understand what's going on. A quick summary of that harsh topics could be 
"Kevin and Sebastian do not once more really care about users and programmers, they 
do whatever they want on TIGCC, since they're the maintainers, and we have to shut 
up". Know that mean Kevin insults the GCC maintainers for doing exactly the same 
thing as he does (browse down http://pub26.ezboard.com/ftichessteamhqfrm13, that was 
a while ago, to read his rant); he's always feeding us up with extreme size 
optimization, but himself wastes kilobytes by using custom decompressors... Have you 
said "mean" and "incoherent" ? That's it.
Sibling topics on ExtGraph and TICT-Explorer show even more about him.


Alternatively, if your AMS is recent enough (well, AMS 2.05, which remains the best one 
IMO, has been available for more than four years...), you can/should use SuperStart, 
which, as a FlashApp, lies and executes in the FlashApp segment (which on most 
calculators is free enough to hold SuperStart). It requires only several dozens of 
bytes of RAM. That is to say, no need to take 2 KB of archive (permanently) and RAM 
(when launching a program) for ttstart. Not to mention that it may keep a faster 
decompression routine.
Note that the LZMA decompression routine, is way larger than the PPG decompression 
routine. That is to say, ttstart-lzma-* are likely to be around 2.5-3 KB large. LZMA 
is among the most powerful generic compression routines currently available, but it 
can be decompressed (well, more slowly than PPG, no matter the LZMA decompressor is 
currently plain ANSI C while the PPG decompressor is now full-blown highly-optimized 
ASM) on TI-68k calculators !
Additionally, SuperStart has nice features like command-line completion and simplified 
launching of PPG-compressed programs (and LZMA-compressed programs in the near future). 
The next version of TICT-Explorer will probably add tictex-sstart, which uses the 
launching abilities of SuperStart to save space in archive (probably more than 1 KB) 
in a permanent way.
BTW, Kevin's been talking about throwing away the PPG compression routine immediately, 
since what matters in compression is efficiency of compression, not slowness of the 
decompressing routine (10 seconds are acceptable for him !). This is a clever idea: 
what about backwards COMPATIBILITY (which is the most important thing for him, 
as he said me once) ?

