TI Flash Studio - signing flash apps

[rsc...@t-online.de]

The Flash Studio is still available on the net - the keys are available
also.

What i can not find on the the net is an instruction how to use the keys
with flash studio to get apps signed. I think i must put the keys in the
dir where Flash Studio is installed. But what about the required
filenames and format of the files? What about the Datestamp key?

I have already written some functions in C using TIGCC and considering to
port some of them to Flash App format. Everything open source, not for profit of course. Most of it is already available in ASM format at ticalc.org (search for CUtils if interested). 

Thank you for your support.

[Benjamin Moody]

From what I can remember, the Flash Studio requires a key file in the
"RSA" format (i.e, the file must include the private exponent for
signing apps, rather than including the two factors as is used in
"Rabin" format key files.) See the RabbitSign documentation for
details about these formats.

You can also, of course, use RabbitSign to sign Flash apps; it accepts
key files in either format. However, before doing that, you'll need
to first link your app using the correct header and relocation format
- which is possible to do using the Flash Studio, but as far as I know
there aren't any existing free software tools for doing so. The
format is somewhat documented, however, so if you're up for it, it'd
be a cool project to add that support to the tigcc linker.

Benjamin

[Lionel Debroux]

Hi,

> > The Flash Studio is still available on the net - the keys are
> > available also.
> >
> > What i can not find on the the net is an instruction how to use
> > the keys with flash studio to get apps signed. I think i must put
> > the keys in the dir where Flash Studio is installed. But what
> > about the required filenames and format of the files? What about
> > the Datestamp key?
> >
> > I have already written some functions in C using TIGCC and
> > considering to port some of them to Flash App format. Everything
> > open source, not for profit of course. Most of it is already
> > available in ASM format at ticalc.org (search for CUtils if
> > interested).

I noticed it in the past, yeah.
For my information, which AMS features would you like to take advantage
of, but cannot with ASM programs made with TIGCC/GCC4TI ? True TI-Basic
extensions ?

> From what I can remember, the Flash Studio requires a key file in
> the "RSA" format (i.e, the file must include the private exponent
> for signing apps, rather than including the two factors as is used
> in "Rabin" format key files.) See the RabbitSign documentation for
> details about these formats.
>
> You can also, of course, use RabbitSign to sign Flash apps; it
> accepts key files in either format. However, before doing that,
> you'll need to first link your app using the correct header and
> relocation format - which is possible to do using the Flash Studio,
> but as far as I know there aren't any existing free software tools
> for doing so.

Correct. IIRC, there's been at least one code base nearly entirely
compiled to m68k-coff with the better GCC in (at that time) TIGCC, the
remaining small amount of FlashApp glue being compiled by the sub-par
Sierra C compiler, and linked with the Sierra linker: GTC.

> The format is somewhat documented,

Yup, by TIFS's documentation.

> however, so if you're up for it, it'd be a cool project to add
> that support to the tigcc linker.

This has been part of the wish list of a variety of persons for a decade
- since the new TIGCC linker was made, in fact. However, the fact is
that nobody ever did it.
At first, there was the annoying signing requirement; then, the TI-68k
programming scene belittled in 2006-2007, over 2 years before we
factored the public validation keys and deduced the signing keys.


Bye,
Lionel.

[rsc...@t-online.de]

Am Mittwoch, 1. April 2015 08:27:59 UTC+2 schrieb Lionel Debroux:

Hi,

> > The Flash Studio is still available on the net - the keys are
> > available also.
> >
> > What i can not find on the the net is an instruction how to use
> > the keys with flash studio to get apps signed. I think i must put
> > the keys in the dir where Flash Studio is installed. But what
> > about the required filenames and format of the files? What about
> > the Datestamp key?
> >
> > I have already written some functions in C using TIGCC and
> > considering to port some of them to Flash App format. Everything
> > open source, not for profit of course. Most of it is already
> > available in ASM format at ticalc.org (search for CUtils if
> > interested).
I noticed it in the past, yeah.
For my information, which AMS features would you like to take advantage
of, but cannot with ASM programs made with TIGCC/GCC4TI ? True TI-Basic
extensions ?

Yes, mostly basic extensions. Maybe also also shared libs. As far as i understand using TIGCC shared libs are possible also but i can load only one at the same time. Having only one would not help because it would become to large. Using static libs i waste memory because i have some functions that are quite large and that i need in more than one program. Btw. the linker in TIGCC also tends to create executables that are larger than necessary (i suspect it includes functions without references sometimes). At least when removing those unneeded funcs from source leads to smaller programs.

I think that i understand the filename convention for keys in Flash Studio. I also know what to put on line 2 and 3 in RSA format. But im unsure which is the correct keycode on 1. line for TI-89?

I will also try signing using rabbitsign (Flash Studio would even allow postprocessing command for automation). Maybe i must use the resign switch because TI Flash Studio already signs them for use in the emulator? I have not seen any option to suppress signing. I do not expect that it can be supressed by removing/renaming the keys supplied by TI because Flash Studio creates an output dir for every key it finds to store the signed flash app. It also stores a *.cer file there - what is the purpose of this file?

Bye,
Lionel.

Thanks.

Regards
Ralph. 

[Lionel Debroux]

Hi,

> > > > I have already written some functions in C using TIGCC and
> > > > considering to port some of them to Flash App format.
> > > > Everything open source, not for profit of course. Most of it is
> > > > already available in ASM format at ticalc.org (search for
> > > > CUtils if interested).
> > I noticed it in the past, yeah.
> > For my information, which AMS features would you like to take
> > advantage of, but cannot with ASM programs made with TIGCC/GCC4TI ?
> > True TI-Basic extensions ?
> Yes, mostly basic extensions. Maybe also also shared libs. As far as
> i understand using TIGCC shared libs are possible also but i can load
> only one at the same time.

Yes, that's the main limitation of the very limited shared library
support in TIGCC/GCC4TI. It was designed for programs whose size would
be between ~64 KB and ~128 KB of code, but not for arbitrary library
splitting, offered by PreOS.
Note that when HW2/3Patch is installed (most 89T calculators have it,
because it's required for many programs), or much more infrequently, the
OS is patched with tiosmod+amspatch, to remove that silly RAM execution
protection, loading multiple libraries is quite simple. See
http://tict.ticalc.org/downloads/launchmultiple.tar.bz2 .

> Having only one would not help because it would become too large.
If you really have lots of code and want to frequently jump from > 1
chunk to another, yeah.
Technically, tiosmod+amspatch's disabling of the Flash execution
protection can help to some extent here. Libraries and ASM programs
_can_ execute from Flash memory on such OS; of course, extremely few of
them are designed for that purpose (by using separate, dynamically
allocated, and probably resident .data and .bss sections, like FlashApps
do).

> Using static libs i waste memory because i have some functions that
> are quite large and that i need in more than one program.

Exactly.

> Btw. the linker in TIGCC also tends to create executables that are
> larger than necessary (i suspect it includes functions without
> references sometimes). At least when removing those unneeded funcs
> from source leads to smaller programs.

Chances are that you did not pass -ffunction-sections -fdata-sections to
the compiler, and/or --gc-sections to the linker (or for the latter,
tick the appropriate checkbox in the IDE, if you're using that).
The default options aim at maximum compatibility but yield poor
optimization. See my TICT S1P9 tutorial for a number of tips on that
topic, some of them deal with the platform-specific toolchain's
capabilities.

The product IDs for the TI-68k series are 0x01 for the 92+, 0x03 for the
89, 0x08 for the V200 and 0x9 for the 89T. The corresponding FlashApp
keys are respectively 0x0101, 0x0103, 0x0108 and 0x0109.
With the appropriate content in TIFS's key files, it can directly sign
FlashApps using the freeware signing keys.

> I will also try signing using rabbitsign (Flash Studio would even
> allow postprocessing command for automation). Maybe i must use the
> resign switch because TI Flash Studio already signs them for use in
> the emulator?

Yup, you can always resign FlashApps after the fact anyway. It's up to you.

> I have not seen any option to suppress signing. I do not expect that
> it can be supressed by removing/renaming the keys supplied by TI
> because Flash Studio creates an output dir for every key it finds to
> store the signed flash app.
> It also stores a *.cer file there - what is the purpose of this file?

I don't remember what this one contains exactly, it's been many years
since I had a look at one...

Once upon a time, there was a developer certificate system, for testing
development versions of FlashApps on real calculators before sending an
hopefully stable version of the FlashApp to TI for signing with the real
keys. The emulator in TIFS is laughably incomplete and inaccurate, so
developers really had better perform some testing on the real calculator...
FlashApp developers sent some information to TI, and received a
developer certificate (.89q / .9xq file on the computer) in return.
IIRC, only the serial number was to be sent to TI, but it's been over a
decade since I did it to contribute a bit to SuperStart, so my memory
might be at fault here :)
After installing the developer certificate to their respective real
calculators, developers could test FlashApps signed by their TIFS on
their calculators.

Flashappy at first (to allow updates to community FlashApps, especially
GTC, after TI stopped responding to signing requests), and later the
factoring of the public RSA validation keys, and the subsequent trivial
computation of the private signing keys, made all of that moot for
practical matters.


Bye,
Lionel.

[Ralph Schenn]

Hi Lionel,

I could sign the example flash app from developer manual and load it to TiEmu using rabbitsign! It also executes there as expected.

I think the next step will be to port one of my programs to flash app format. Than i will look at the size and the runtime performance... Maybe i will be dissapointed using Flash Studio - but i do not think that it will cost very much time to port a single program to give it a try.

Until now i have only activated the optimizations TIGCC is offering on the linker tab in project settings dialog.

Btw. im no longer able to start TiEmu from TIGCC (must load the progarms manually). This worked for me under Windows 7 (i have killed that OS in the meantime). After that im using TIGCC+TiEmu under Windows NT. I also have problems debugging in TiEmu. This also worked better somewhere in the past under Windows 7.

TiEmu ist a big CPU hog unter NT. It needs 100% CPU even when nothing is running inside the virtual calculator (on a 400MHz Pentium II with 192MB RAM).

Regards
Ralph

[Lionel Debroux]

Hi Ralph,

> I could sign the example flash app from developer manual and load it
> to TiEmu using rabbitsign! It also executes there as expected.

Good, as expected indeed. Even if your FlashApp were not properly
signed, Flashappy or tiosmod+amspatch solve the problem.

> I think the next step will be to port one of my programs to flash app
> format. Than i will look at the size and the runtime performance...
> Maybe i will be dissapointed using Flash Studio

-maybe +almost certainly. The IDE itself is unreliable (frequent
crashes), its emulator is a sick joke, the Sierra C compiler only
supports an old (K&R) dialect of C while the GCC 4.1.x in TIGCC/GCC4TI
supports the superior GNU C dialect, and TIFS's documentation
(sdk8992pguide.pdf) is very limited (or occasionally plain wrong) on
lower-level aspects.

As I mentioned earlier, in order to (hopefully) get the best of both
worlds, you should be able to compile to COFF with TIGCC/GCC4TI, compile
the FlashApp glue in TIFS, and link with TIFS (the Sierra toolchain).
That's what I'd try myself at first if I wanted to write a FlashApp
nowadays.

> - but i do not think that it will cost very much time to port a
> single program to give it a try.

Probably not, indeed :)

> Until now i have only activated the optimizations TIGCC is offering
> on the linker tab in project settings dialog.

Then you're missing out on a number of useful items described in my S1P9
tutorial ;)

> TiEmu is a big CPU hog under NT. It needs 100% CPU even when

> nothing is running inside the virtual calculator (on a 400MHz
> Pentium II with 192MB RAM).

That's partially the price of increased accuracy and features, compared
to VTI.


Bye,
Lionel.

[Ralph Schenn]

Hi Lionel,

i could not get my example (moving average from CUtils) to compile today. There are only a few errors left, but they are not obvious. Will continue tomorrow.

The support for complex numbers is poorer in Sierra C than TIGCC? But i have not read the chapter in TI Devel Manual until now.

In what dir does rabbitsign search for key files under Windows? Is there a env var to tell it where to search? I was trying to omit the -k flag and give the key files the expected names - but it seems that it searches only in the current dir which is not what i want.

What do i need to build TiEmu myself? Or is it possible to change the shortcuts for TI-89 keys without recompiling? Its annoying to enter things like () using the mouse only... But in this respect the emulator of Flash Studio also seems to be less than perfect. But at least debugging seems to work and in doesnt need excessive CPU time.

Regards.

Ralph

[Lionel Debroux]

Hi Lionel,

> i could not get my example (moving average from CUtils) to compile
> today. There are only a few errors left, but they are not obvious.
> Will continue tomorrow.

I'm not surprised. It's not a problem with your code, it's that the
old dialect of C understood by the Sierra C compiler is, well, old.

> The support for complex numbers is poorer in Sierra C than TIGCC?

For complex numbers, it should be pretty much the same: there's a
limited number of ROM_CALLs dealing with complex numbers.

> But i have not read the chapter in TI Devel Manual until now.

On raw count, the TIGCC documentation contains documentation for more
functions than the TIFS does, and the GCC4TI documentation is a
superset of the TIGCC documentations, with several dozen more functions,
originally contributed to TIGCC as far back as 2002.
The GCC4TI documentation remains lacking in the area of FlashApps,
mainly. But nearly 10 years after TI stopped caring about the TI-68k
platform, with so few TI-68k developers left (and even fewer as time
passes by), FlashApp documentation in GCC4TI is never going to happen,
unless someone has lots of time to waste and isn't willing to spend it
on more useful endeavours :)

> In what dir does rabbitsign search for key files under Windows?
> Is there a env var to tell it where to search? I was trying to
> omit the -k flag and give the key files the expected names - but
> it seems that it searches only in the current dir which is not
> what i want.

I've only used RabbitSign under Linux, but looking for files in the
current directory sounds about right. Just don't omit the -k flag :)

> What do i need to build TiEmu myself?

Uh... I suggest you don't dare doing that :)
* the Visual Studio-based build system was last tested in 2009;
* the Linux-based cross-build system was last tested three years ago or so;
* I'm not aware anybody managed to do a native MinGW build. I sure
didn't: building autotools-based programs under virtualized Windows was
hilariously slow for me (a combination of Windows' slow process creation
and virtualization) and triggered an error, which I didn't bother
examining because the Linux-based cross-build system is much faster.

> Or is it possible to change the shortcuts for TI-89 keys without
> recompiling?

Sure, through the ".map" files.

> Its annoying to enter things like () using the mouse only...

Maybe you're using a German keyboard layout, and parentheses are not
where you'd expect them to be, or mapped to keys which do not exist ?

> But in this respect the emulator of Flash Studio also seems to be
> less than perfect. But at least debugging seems to work and in doesnt
> need excessive CPU time.

The fact that it doesn't need excessive CPU time is a consequence from
the fact that it emulates extremely inaccurately... It barely emulates
enough for running TI's OS, that's all.
VTI, despite its known shortcomings, is still much better than the
emulator in TIFS; both are noticeably faster than TIEmu, whose users
understandably pay a price for emulating more hardware ports, emulating
the 68000's pipeline, etc.

From my own experience on old computers, I know that:
* VTI maxed out a 100 MHz Pentium without being able to emulate the
calculator at 100% of real calculator speed (maybe 50%, it was really
noticeable);
* IIRC, emulation speed on a K6-200 was close to real calculator speed;
* the UI part of TIEmu's is known to be very slow under Windows 9x/ME,
due to their graphics stack's failings. Opening the debugger took ~3
seconds (which led Romain Liévin to add some pre-loading code after
witnessing the problem on my computer), just switching pens for
different text output colors measurably slowed down, etc. Windows 2000
and XP had decent graphics stacks; I don't know where NT4 stands.
It's not too surprising that TIEmu eats lots of CPU power on a PII 400.


Bye,
Lionel.

[Benjamin Moody]

> In what dir does rabbitsign search for key files under Windows? Is there a
> env var to tell it where to search? I was trying to omit the -k flag and
> give the key files the expected names - but it seems that it searches only
> in the current dir which is not what i want.

It should search first in the current directory, then the directory
given by the RABBITSIGN_KEY_DIR environment variable. On *nix it will
also search $prefix/share/rabbitsign/.

Benjamin

[Ralph Schenn]

Hi Benjamin,

now it finds the keys after setting the var.

But i must be very stupid today. Yesterday i could sign for TiEmu
emulating TI-89 using 0103.key. Today i get no errors when signing but
when trying to copy to TiEmu i get "wrong target".

Regards
Ralph

[Ralph Schenn]

On 04/03/2015 11:01 PM, 'Lionel Debroux' via ticalc.org-advanced wrote:
> Hi Lionel,
>
>> i could not get my example (moving average from CUtils) to compile
>> today. There are only a few errors left, but they are not obvious.
>> Will continue tomorrow.
> I'm not surprised. It's not a problem with your code, it's that the
> old dialect of C understood by the Sierra C compiler is, well, old.

It has mostly other reasons. Some things have just different names, a
few things i used in TIGCC are missing using Flash Studio.

>
>> The support for complex numbers is poorer in Sierra C than TIGCC?
> For complex numbers, it should be pretty much the same: there's a
> limited number of ROM_CALLs dealing with complex numbers.

The question is if i can declare complex variables... I have not found
that until now in Sierra C. Maybe i must do a typedef struct to keep it
together? I hope i must not also reinvent the complex arithmetic rules.

Yes, could be the reason. I will look at map file afterwards.

>> But in this respect the emulator of Flash Studio also seems to be
>> less than perfect. But at least debugging seems to work and in doesnt
>> need excessive CPU time.
> The fact that it doesn't need excessive CPU time is a consequence from
> the fact that it emulates extremely inaccurately... It barely emulates
> enough for running TI's OS, that's all.
> VTI, despite its known shortcomings, is still much better than the
> emulator in TIFS; both are noticeably faster than TIEmu, whose users
> understandably pay a price for emulating more hardware ports, emulating
> the 68000's pipeline, etc.
>
> From my own experience on old computers, I know that:
> * VTI maxed out a 100 MHz Pentium without being able to emulate the
> calculator at 100% of real calculator speed (maybe 50%, it was really
> noticeable);
> * IIRC, emulation speed on a K6-200 was close to real calculator speed;
> * the UI part of TIEmu's is known to be very slow under Windows 9x/ME,
> due to their graphics stack's failings. Opening the debugger took ~3
> seconds (which led Romain Liévin to add some pre-loading code after
> witnessing the problem on my computer), just switching pens for
> different text output colors measurably slowed down, etc. Windows 2000
> and XP had decent graphics stacks; I don't know where NT4 stands.
> It's not too surprising that TIEmu eats lots of CPU power on a PII 400.

It eats 100% CPU even when idling around completely. Dont know what it
must do more acurately when being idle. Must not even repaint the window
idling.

Beside from that i still can not start TiEmu from TIGCC anymore. The
idea to start it directy with parameters entered in TIGCC IDE is great
but breaks easily (maybe depending on Windows version - had more luck
with 7 than with NT or XP). I even had the situation that it succeeded
maybe in one of ten tries without changing anything in between). Flash
stududio does not pass parameters to emulator, must call function
manually. But at least it loads new version after building every time.

Without starting TiEmu directly from TIGCC (loading the programs
manually in TiEmu instead) debugging never worked for me. May because it
doesnt know where to look for the sources than? Assembly level debugging
seems to work, but not at C source level.

Bye
Ralph

[Lionel Debroux]

Hi,

In idle mode, the number of emulated instructions per unit of time is
lower than in full-time operation mode, but AMS still does something
nevertheless. To begin with, AUTO_INT_1 is fired at 256 Hz on HW2+ or
350+ Hz on HW1.

> Beside from that i still can not start TiEmu from TIGCC anymore.
> The idea to start it directy with parameters entered in TIGCC IDE
> is great but breaks easily (maybe depending on Windows version -
> had more luck with 7 than with NT or XP). I even had the situation
> that it succeeded maybe in one of ten tries without changing
> anything in between). Flash stududio does not pass parameters to
> emulator, must call function manually. But at least it loads new
> version after building every time.

I see.
The last time I used this aspect of the IDE post-dates the creation of
GCC4TI, as I made some testing with both TIEmu and VTI, after restoring
the VTI support which was removed from TIGCC years earlier, but it's
been years nevertheless.

> Without starting TiEmu directly from TIGCC (loading the programs
> manually in TiEmu instead) debugging never worked for me. May
> because it doesnt know where to look for the sources than?
> Assembly level debugging seems to work, but not at C source level.

Debugging at C source level requires using a version of TIEmu which
provides support for such debugging, usually dubbed "GDB-enabled
version", or "+gdb" for short.
The fact is that this version of TIEmu is slower, has more bugs, and has
always worked better on Linux than on Windows anyway.
The latest +GDB Windows build, from early 2008, is linked from TIEmu's
ticalc.org page: http://lpg.ticalc.org/prj_tiemu/win32.html


Bye,
Lionel.

[Ralph Schenn]

Hi Lionel,

You understand the inner workings of both AMS and the Emulator much
better than me :-) But im still wondering why it takes so many cycles
emulating a CPU that is maybe 4MIPS without FPU on a CPU+FPU which is at
least 200MIPS... We are not simultitang that beast at transistor level
using hopefully...

>
>> Beside from that i still can not start TiEmu from TIGCC anymore.
>> The idea to start it directy with parameters entered in TIGCC IDE
>> is great but breaks easily (maybe depending on Windows version -
>> had more luck with 7 than with NT or XP). I even had the situation
>> that it succeeded maybe in one of ten tries without changing
>> anything in between). Flash stududio does not pass parameters to
>> emulator, must call function manually. But at least it loads new
>> version after building every time.
> I see.
> The last time I used this aspect of the IDE post-dates the creation of
> GCC4TI, as I made some testing with both TIEmu and VTI, after restoring
> the VTI support which was removed from TIGCC years earlier, but it's
> been years nevertheless.
>
>> Without starting TiEmu directly from TIGCC (loading the programs
>> manually in TiEmu instead) debugging never worked for me. May
>> because it doesnt know where to look for the sources than?
>> Assembly level debugging seems to work, but not at C source level.
> Debugging at C source level requires using a version of TIEmu which
> provides support for such debugging, usually dubbed "GDB-enabled
> version", or "+gdb" for short.
> The fact is that this version of TIEmu is slower, has more bugs, and has
> always worked better on Linux than on Windows anyway.
> The latest +GDB Windows build, from early 2008, is linked from TIEmu's
> ticalc.org page: http://lpg.ticalc.org/prj_tiemu/win32.html

I have tried +gdb a few months ago, but on windows and not linux.

I had some success today. I have ported 9 functions now. They seem to
run after my first tests in the emulator from TI. Have not measured
execution times on real HW compared to ASM version using mostly the same
code until now - but i am very curious. But at least i save a lot of
flash here: its minimum 40% less. In this example i do not even share
code very much between functions. I expect to have functions where i can
save much more than 40% compared to the sum of the sizes of the
individual statically linked ASM programs.

Im unable to sign again - yesterday it worked at least one time. Must be
because of my own stupidity.

Bye.

Ralph

[Lionel Debroux]

Hi,

> > > > It's not too surprising that TIEmu eats lots of CPU power on a
> > > > PII 400.
> > > It eats 100% CPU even when idling around completely. Dont know
> > > what it must do more acurately when being idle. Must not even
> > > repaint the window idling.
> > In idle mode, the number of emulated instructions per unit of time
> > is lower than in full-time operation mode, but AMS still does
> > something nevertheless. To begin with, AUTO_INT_1 is fired at 256
> > Hz on HW2+ or 350+ Hz on HW1.
> You understand the inner workings of both AMS and the Emulator much
> better than me :-) But im still wondering why it takes so many cycles
> emulating a CPU that is maybe 4MIPS without FPU on a CPU+FPU which is
> at least 200MIPS... We are not simultitang that beast at transistor
> level using hopefully...

Indeed, we aren't simulating a M68000 and its peripherals at transistor
level - otherwise it would be immensely slower ;)
Among the explanations of a significant emulation cost:
* a software implementation of a foreign pipeline is costly (and very
few TI-68k programs rely on it anyway, though one of them is important);
* the x86 (IA-32) family has few usable registers (AMD alleviated that
for the x86_64 - AMD64 series), which means that virtually none of the
registers of the emulated processor can be kept into one of the host
processor's registers for any extended period of time - they have to be
read and written to memory all the time.
Most ISAs have more registers than the x86 does, which is a good thing
for programming those other processors, but bad for emulating them on an
x86. x86 and the IBM PC didn't come to dominate the processor world for
nearly two decades because they were technically better (far from
it...), but that's another story.

> I had some success today. I have ported 9 functions now. They seem
> to run after my first tests in the emulator from TI. Have not
> measured execution times on real HW compared to ASM version using
> mostly the same code until now - but i am very curious.

Your programs use many ROM_CALLs, so their speed will be mostly
dependent on AMS's speed anyway, even if the way to perform ROM_CALLs
has some impact on size and speed:
* TIFS uses F-Line ROM_CALLs, which are by far the slowest method (an
exception handling for unimplemented instructions, followed by several
dozens of instructions for turning the unimplemented instruction into a
function call), but also the smallest one;
* your TPRs request direct ROM_CALL format, which is the default value
for compatibility, but the second slowest, and the largest solution.
IOW, the worst choice for optimization (but the most compatible one)...

> But at least i save a lot of flash here: its minimum 40% less.

You can do much better on that front even if sticking to ASM programs in
the superior TIGCC/GCC4TI environment ;)

> this example i do not even share code very much between functions.
> I expect to have functions where i can save much more than 40%
> compared to the sum of the sizes of the individual statically
> linked ASM programs.

You're right that sharing some code will help reducing size, but
switching to optimized compilation options saves _far_ more, with almost
zero work :)

Case in point: I've just tried raising the minimum AMS version to 2.09
in MyLib.tpr, and switching to F-Line ROM_CALLs:

diff -Naurbp '--exclude=*.o' '--exclude=*.a' '--exclude=*.89z'
'--exclude=*.9xz' '--exclude=*.v2z' CUtils_orig/MyLib/MyLib.tpr
CUtils/MyLib/MyLib.tpr
--- CUtils_orig/MyLib/MyLib.tpr 2015-04-04 15:38:04.021741137 +0200
+++ CUtils/MyLib/MyLib.tpr 2015-04-04 15:38:42.729739518 +0200
@@ -36,10 +36,10 @@ Optimize Calc Consts=0
Use Kernel=0
Use PreOS=0
Minimum AMS Version Defined=1
-Minimum AMS Version=1.00
+Minimum AMS Version=2.09
Unofficial OS Support=0
Reloc Format=AMS
-ROM Call Format=Direct
+ROM Call Format=F-Line
BSS Ref Format=Kernel
Data Ref Format=Kernel
Use F-Line Jumps=0

Then, I recompiled MyLib, and IsFreeOf. The end result is that the
computer-side size of IsFreeOf.??z went from 2391 to 593 bytes, >75%
decrease.
I didn't try using -mregparm=5, or one of the other optimized
compilation options I mentioned in my TICT S1P9 tutorial. I didn't try
to look inside the code and perform some optimization either.
TIFS doesn't support functionality equivalent to -mregparm=5, anyway.


Five final notes:
* "float input[][]" and "_Complex float input[][]" in Stack.* do not
compile here. The more usual "float **input" and "_Complex float
**input" do, however.

* I see what you meant by having to rework complex number handling.
TIFS / Sierra C do indeed not have anything of that sort. You'll have to
significantly rework all of your code which uses complex numbers - if
you really still want to have TIFS build everything.

* a 2.09 minimum AMS version is extremely high. You should decrease that
to 2.05, as:
* you're probably not using the several AMS 2.07-2.09 ROM_CALLs
which aren't in AMS 2.05, they are barely documented anyway;
* users have a good reason to stick to 2.05 on 89 calculators:
official 2.08/2.09 spill onto one more Flash sector, and therefore
deprieve users of 64 KB of user, i.e. FlashApp + archive, memory.

* you should remove all *.o and *.dbg files before distributing CUtils,
it would reduce the size of the CUtils ZIP distribution :)

* I still strongly think you should at least investigate interworking
between TIGCC/GCC4TI and TIFS, in the hope that you can get the best of
both worlds: a FlashApp with TI-Basic extensions, while keeping the
existing code base, on which you already spent lots of time, compiled
with a much superior environment...
The conditions for testing interworking are optimal: your multiple
separate ASM programs are written under a void _main(void) function, as
all other AMS native ASM programs. Those functions are all the small
FlashApp glue code declaring TI-Basic extensions needs to see.

I'll try to cook something up for you to test. I think it would be way
too much of a shame for you to waste time rewriting some of your code to
try and cope with an inferior environment, because the interworking
between GCC4TI and TIFS wasn't investigated by anybody...


Bye,
Lionel.

[Ralph Schenn]

Hi Lionel,

enough devel for today. But i think that now i can port quite rapidly to
Sierra C (if i do not need complex numbers)... The error messages Sierra
C gives are somewhat more difficult to interpret than gccs messages. And
all varaiable declarations must be on top of the functions, otherwise i
get strange compile errors...

I do not consider the x86 to be great also... Maybe one of the weakest
architectures of that time. But it was a commercial success, thats all
what counts afterwards.

I still have binaries around 500 bytes for this trivial is*-wrappers.
Now they got bigger without your changes because i added much more
functions to Stack.c. Without those unreferenced functions even today i
get a size around 500 bytes or even smaller.

> I didn't try using -mregparm=5, or one of the other optimized
> compilation options I mentioned in my TICT S1P9 tutorial. I didn't try
> to look inside the code and perform some optimization either.
> TIFS doesn't support functionality equivalent to -mregparm=5, anyway.
>
>
> Five final notes:
> * "float input[][]" and "_Complex float input[][]" in Stack.* do not
> compile here. The more usual "float **input" and "_Complex float
> **input" do, however.
>
> * I see what you meant by having to rework complex number handling.
> TIFS / Sierra C do indeed not have anything of that sort. You'll have to
> significantly rework all of your code which uses complex numbers - if
> you really still want to have TIFS build everything.

I think at least for complex code i will stay with TIGCC. Not having
complex numbers will make the code much more complex an less readable.

>
> * a 2.09 minimum AMS version is extremely high. You should decrease that
> to 2.05, as:
> * you're probably not using the several AMS 2.07-2.09 ROM_CALLs
> which aren't in AMS 2.05, they are barely documented anyway;
> * users have a good reason to stick to 2.05 on 89 calculators:
> official 2.08/2.09 spill onto one more Flash sector, and therefore
> deprieve users of 64 KB of user, i.e. FlashApp + archive, memory.

I didnt know of this reason to stay with older versions before :-)

>
> * you should remove all *.o and *.dbg files before distributing CUtils,
> it would reduce the size of the CUtils ZIP distribution :)

Sure, even Flash Studio has a Clean command. Maybe my internet
connection is much to fast to think of it before uploading :-) 16MBit
DSL is pure luxury.

>
> * I still strongly think you should at least investigate interworking
> between TIGCC/GCC4TI and TIFS, in the hope that you can get the best of
> both worlds: a FlashApp with TI-Basic extensions, while keeping the
> existing code base, on which you already spent lots of time, compiled
> with a much superior environment...
> The conditions for testing interworking are optimal: your multiple
> separate ASM programs are written under a void _main(void) function, as
> all other AMS native ASM programs. Those functions are all the small
> FlashApp glue code declaring TI-Basic extensions needs to see.

The problem is i do not know the internal workings of the linker and the
details of the executable formats and calling conventions (not even for
other target CPU/OS) inside out. I have focussed on math in most of my
work for TI-89. And my time is somewhat limited because im also working
as a programmer for an insurance company (C# web apps there). If i
should find a new boyfriend i will have even less time for this nerdy
calculator stuff :-)

>
> I'll try to cook something up for you to test. I think it would be way
> too much of a shame for you to waste time rewriting some of your code to
> try and cope with an inferior environment, because the interworking
> between GCC4TI and TIFS wasn't investigated by anybody...
>

Bye

Ralph

[Lionel Debroux]

Hi again,

> enough devel for today. But i think that now i can port quite rapidly
> to Sierra C (if i do not need complex numbers)... The error messages
> Sierra C gives are somewhat more difficult to interpret than gccs
> messages. And all varaiable declarations must be on top of the
> functions, otherwise i get strange compile errors...

Yup. Sierra C is not the only compiler which requires variable
declarations to be at the beginning functions; even nowadays, if one is
aiming at maximum portability of C code (to old / sub-par compilers),
variable declarations after a statement should be avoided.

CUtils 0.4, as available from ticalc.org, uses -ffunction-sections
-fdata-sections and --gc-sections, so I'm not sure why you experience
the cost of unreferenced functions...

> > * I see what you meant by having to rework complex number handling.
> > TIFS / Sierra C do indeed not have anything of that sort. You'll
> > have to significantly rework all of your code which uses complex
> > numbers - if you really still want to have TIFS build everything.
> I think at least for complex code i will stay with TIGCC. Not having
> complex numbers will make the code much more complex an less readable.

Staying with TIGCC/GCC4TI is wise :)

> > * a 2.09 minimum AMS version is extremely high. You should decrease
> > that to 2.05, as:
> > * you're probably not using the several AMS 2.07-2.09
> > ROM_CALLs which aren't in AMS 2.05, they are barely documented
> > anyway;
> > * users have a good reason to stick to 2.05 on 89 calculators:
> > official 2.08/2.09 spill onto one more Flash sector, and therefore
> > deprieve users of 64 KB of user, i.e. FlashApp + archive, memory.
> I didnt know of this reason to stay with older versions before :-)

Your code builds with a minimum AMS version of 2.05, besides.
tiosmod+amspatch can shrink AMS 2.08 and 2.09 for 89, in such a way that
they fit into the same number of sectors as AMS 2.05, but of course,
extremely few people use the result of tiosmod+amspatch (let alone
tiosmod+amspatch itself).

> > * I still strongly think you should at least investigate
> > interworking between TIGCC/GCC4TI and TIFS, in the hope that you
> > can get the best of both worlds: a FlashApp with TI-Basic
> > extensions, while keeping the existing code base, on which you
> > already spent lots of time, compiled with a much superior
> > environment...
> > The conditions for testing interworking are optimal: your multiple
> > separate ASM programs are written under a void _main(void)
> > function, as all other AMS native ASM programs. Those functions
> > are all the small FlashApp glue code declaring TI-Basic extensions
> > needs to see.
> The problem is i do not know the internal workings of the linker and
> the details of the executable formats and calling conventions (not
> even for other target CPU/OS) inside out.

I can precisely help with that ;)

> I have focussed on math in most of my work for TI-89. And my time is
> somewhat limited because im also working as a programmer for an
> insurance company (C# web apps there). If i should find a new
> boyfriend i will have even less time for this nerdy calculator
> stuff :-)

Alright :)


On my side, I followed up on what I wrote in my previous e-mail:

> > I'll try to cook something up for you to test. I think it would be
> > way too much of a shame for you to waste time rewriting some of
> > your code to try and cope with an inferior environment, because
> > the interworking between GCC4TI and TIFS wasn't investigated by
> > anybody...

using CUtils 0.4 as a starting point.
Basically, I:
* renamed and moved all of Projects/*/*.c into MyLib/wrappers;
* renamed the _main functions from MyLib/wrappers/*.c to e.g.
void ConRecEqMain(void);
* created a header file which just declares prototypes for those
functions - those are the functions you'd write into the APP_EXT_ENTRY
section of the FlashApp glue (see section 7.3.2 of sdk8992pguide.pdf);
* integrated the new files into the MyLib TPR;
* used the semi-undocumented -D_NO_INCLUDE_PATCH compiler flag, in order
to minimize the amount of spurious xdefs;
* used m68k-coff-tigcc-strip to strip lots more spurious xdefs I can't
easily strip otherwise. Only GCC4TI provides this tool (and a number of
others), that's one of the areas where the practically unmaintained
TIGCC is behind;
* added -save-temps to the compiler flags, changed the type inside
MyLib.tpr: Archive=0 and added a dummy main, so that all files get
compiled to .o, those .o files are kept, but no archive with spurious
assembler flags (--all-relocs --keep-locals) is created.
The end goal of that step was to produce bare .o files in m68k-coff
format, so that they can (hopefully) be generated without TIGCC/GCC4TI
extensions, and imported as is into TIFS. I'm not sure the Sierra C
toolchain can deal with the ar archives produced by the TIGCC linker and
the ar binutil (only available in GCC4TI).

This work could be re-done relatively easily with a newer version of CUtils.


To go beyond that stage, I'd need to gather .o files for a number of
dependencies from tigcc.a (which is trivial), and test something in
TIFS, which is less trivial. That is, I need to boot up the old Win XP
VM (the TIFS IDE won't run on anything newer, though the Sierra
toolchain can), but it's on another computer, whose RAM is currently
filled with other data. A task for another day.


Bye,
Lionel.

[Ralph Schenn]

Hi Lionel,

still failing to sign for TI-89. Using 0103.key as distribued on the net
(Rabin format) and -r flag. The first time i could sign i used the
example program for basic extensions from developer manual from TI
(containing the vars and folders functions). Two days before this worked
after a few tries. Now i do not get any errors when running rabbitsign
with -vv flag, but when trying to install to TiEmu emulating TI-89 i get
"bad target".

Im sure it worked before.

Regards
Ralph

[Ralph Schenn]

Hi Benjamin,

still not able to sign using 0103.key as supplid on the net for TI-89.

Can you please try to sign for TI-89 and if installable send me the
command line and key you used?

Thanks.

Regards
Ralph


On 04/04/2015 04:58 AM, Benjamin Moody wrote:

[Benjamin Moody]

Hi,

On 4/5/15, Ralph Schenn <rsc...@t-online.de> wrote:
> Hi Benjamin,
>
> still not able to sign using 0103.key as supplid on the net for TI-89.
>
> Can you please try to sign for TI-89 and if installable send me the
> command line and key you used?
>
> Thanks.
>
> Regards
> Ralph

Your app's header uses the key ID of 014F03 (if you look at your 89k
file in a hex editor, you'll see it contains "81 13 01 4F 03".)

The key ID has to match the key you use for signing, or the calc won't
accept it. And it's not trivial to change the key ID in an existing
app header, since you'd need to add or remove a byte of padding to
maintain alignment.

I think the Flash Studio uses the ID from its key file (sdk-89.key) to
fill in this header, so you might try changing that line to "0103" and
see if that helps.

Benjamin

[Ralph Schenn]

Hi Benjamin,

yes - it works after changing to 0103.

Now i will do some execution time comparisons to the ASM programs on the
real TI-89...

Thanks.

Ralph

[Ralph Schenn]

Hi Benjamin,

i can install to TiEmu now. But not to the hardware. Both have AMS 2.09
and HW 2.

What may be the reason? Im using TI GraphLink 2.1 under Win NT to install.

Will also try TI Connect under XP afterwards.

Regards

Ralph




On 04/06/2015 06:09 AM, Benjamin Moody wrote:

[Ralph Schenn]

Hi Benjamin,

using TI Connect i could install to real hardware TI-89...

Regards
Ralph


On 04/06/2015 06:09 AM, Benjamin Moody wrote:

[Ralph Schenn]

Hi Lionel,

have done my first test an real hardware today.

The performance of scalar real math functions seems to be the same as the ASM programs. Maybe they are even slower but because of avoiding loading to RAM the execution time is the same. I have done the measurement calling besselj from basic for 100 times.

At the moment im wondering why movavg and conreceq do not accept lists stored in variable as argument. When i pass the list as constant on TI-89 command line they accept it. So i think the list is not expanded before control is passed to the flash app function. In TIGCC i have not expended anything explicitly in function GetFloatListArg. Any idea what additional function i must call?

Btw. i have included a wrapper for SortA/D also now. Its much slower than the quicksort based sort (which doesnt accept lists with mixed types) but the function is much smaller also because of being just a wrapper.

Thanks.

Regards
Ralph

[Lionel Debroux]

Hi Ralph,

> have done my first test an real hardware today.

Good.

> The performance of scalar real math functions seems to be the same as
> the ASM programs. Maybe they are even slower but because of avoiding
> loading to RAM the execution time is the same. I have done the
> measurement calling besselj from basic for 100 times.
>
> At the moment im wondering why movavg and conreceq do not accept
> lists stored in variable as argument. When i pass the list as

> constant on TI-89 command line they accept it. *So i think the list
> is not expanded before control is passed to the flash app function*.

> In TIGCC i have not expended anything explicitly in function
> GetFloatListArg. Any idea what additional function i must call?

I'd have expected the list to be expanded.
On the TI-Basic side, when invoking the FlashApp, does using
expr(variable) instead of variable work around the problem ?

> Btw. i have included a wrapper for SortA/D also now. Its much slower
> than the quicksort based sort (which doesnt accept lists with mixed
> types) but the function is much smaller also because of being just a
> wrapper.

Sure.


Bye,
Lionel.

[Ralph Schenn]

Hi Lionel,

this code for getting floats from estack seems to work for the cases
that are important to me

/* get float from expression stack */
double estack_number_to_Float_inf(EStackIndex ptr) // ok
{
Access_AMS_Global_Variables;
double f;

TRY
f = ForceFloat (ptr);
ONERR
if (!is_free_of_tag (ptr, MINUS_INFINITY_TAG)) {
f = FLOATTAB[FPI_NEGINF];
} else if (!is_free_of_tag (ptr, PLUS_INFINITY_TAG)) {
f = FLOATTAB[FPI_POSINF];
} else {
f = FLOATTAB[FPI_INVALID];
}
ENDTRY

return f;
}

For expanding the list i suspect that im must use someting like
push_internel_simplify. Have not tested that until now, wanted to solve
the scalar case first.

Reagrds
Ralph