Wow it's late October already?

LOL. :)

You mean "Early 2000", right?

By the way, with a particular program I wrote with the SDK, it crashes the SDK when I try to build it. But, when I copy the file to the TI-GCC IDE and make the necessary changes it works. The program involves a single dynamic dialog box using example code from the documentation. I just had to define some flags for the TI-GCC version to work.

-Sean

>By the way, with a particular program I wrote with the SDK, it crashes the SDK when I try to build it. But, when I copy the file to the TI-GCC IDE and make the necessary changes it works. The program involves a single dynamic dialog box using example code from the documentation. I just had to define some flags for the TI-GCC version to work.

That's rather odd. You'd think that TI's receiving $300 for each copy of its software would give it incentive enough to make its programs functional.

I really liked their "release date" for the USB graph link. It was "Estimated Availability: Late 2000". That gives them roughly six months of "give" as far as when they actually did release it. I finally got one, and it turns out MY 89 HAS A FAULTY LINK PORT!!! BAH!!!!!! I'll find some way around that, though. If not, TI won't exist to make us any more great calcs...

me + recovering from just seeing "dinosaur" = Fil

My link port was a bit broken itself when i purchased my Ti-89. If you email them and tell them that it is broken they send you back an email saying send them the calculator with the email saying that they will fix it for free.. Then they send it back in a few weeks. I dont konw how long exactly, because i was on vecation when i sent it out to them, and it was back before i got home. So just tell them that it was broken and they are nice about fixing it. Though it cost like 5$ to send to them. Take out the batteries before sending it to them though.

That's kinda my problem, I cannot afford to lose the memory. As you may or may not know, I'm the author of The Legend of Zelda: Link's Awakening in BASIC, and I have A TON of important, priceless files on there. I can't lose those. I'll find a way to get it off, probably use another calc and see what happens.

me = tired Fil

Depending on how precious those files are to you, you may want to consider purchasing Fision2's radio link. You will need to get the transmitter and the reciever. Im not real sure of the price, but it is an option.

It isn't an option at all, really. First, he would have to purchase the internal version because his link port is broken. Then he'd have to open it up and install the chip. This voids his warranty. IF it even works, then things aref ine. If it doesn't, then he just wasted the money on transmitters and has to purchase a new 89. He'd have better luck just repairing it himself, than installing a radio link.

The link port broke on my 83 a few months ago. The contact that the tip normally touches snapped in half. At first I tried sliding a new metal piece in its place, but I could not get this to work. I then drilled a hole in the link port casing, put a wire in the hole and soldered the wire to where the old metal piece used to go. I have had no problems since I did this even though I am very bad at soldering.

The SDK looks pretty cool. If only I had an 89 (sigh). If someone wants to buy me one, I would be happy to port my 83 RPG to 89 C :) (see URL)

You don't need the SDK to make your RPG an 89 C program. Try TI-GCC... and from what I've heard from this DG so far, TI-GCC is probably a better option.

Yeah, I knew that. In fact I have TI GCC even though I have no 89 (donations anyone?). I have only made one program though, and it just displays a greyscale sprite and waits for a keypress.

The same thing happened to me, so I sent them my TI-86, TI-89 (with the broken link port), and the gray graph link cable. They decided to send me two TI-86s and a TI Resource CD. That makes me mad, it's been MONTHS. I've called them frequently but they screwed me out of an expensive calculator and a graph link cable.

Whoa dude, that utterly sucks. :(

Something you aught to try if your linkport ever goes out, take it to your local Wal-Mart. Mine and one not to far from here don't bother checking for receipts. I just walk up to the front desk with the 89 and everything it came with in it's original casing, and tell them the link port came broken and I lost my receipt, and they just let me exchange it. If they ask how long ago I bought it, I always say a month and a half, because usually someone has purchased one somewhere around then.

I just need to get my hands on another 89 with a good link port and hope I can get everything sent from mine to it okay. If not, I don't know what I'll do.

me = Fil

It's now the time that I tell to the public the worst thing related to the SDK. It really "solves" the compatibility problem between various AMS versions, because it generate the code which works ONLY ON AMS 2.05!!! I didn't check it actually with this beta release, but all alpha releases produces the code which strongly depends of AMS 2.05, even if you make a "Hello world" program!!! I don't expect that this is changed in this beta release, because TI don't want anything on their calcs which is not AMS 2.05...

I will tell more in the future, when I would have a bit more time to discuss...

Super, the graphing calculator equivalant of MS Visual C++ creating code only compatiable with Windows ME. I sent the Hello World program included with the SDK to VTI with a 92+ AMS 1.05 and it crashed it wonderfully. Does the same thing on the real thing, black bar + Line 1111 Emulator error. Thanks TI!

If anybody wants to know why code generated with SDK works only on AMS 2.05, I will tell you that it calls TIOS routines using a Line 1111 Emulator trap (which is redirected to a calling routine in AMS 2.05). On this way ROM calling is really very short (two bytes only), but much slower than usually, and it works only on AMS 2.05. Even "Hello world" program will crash on any other AMS release.

<SARCASM>
Sorry, it works on AMS 2.04 too.
</SARCASM>

I recently downloaded the SDK and made some small tests of its C compiler. It seems to be significantly inferior to GCC. However, I'm not completely sure that there isn't some hidden optimization switch I just haven't found yet.

One of the routines I tried to compile is a grayscale masked sprite routine I've written. The TI-GCC version of the main loop takes 230 clock cycles, while the SDK's compiler generates a 324 cycle loop. I didn't count this very carefully, so there may a slight mistake (it also varies on the amount of shift, but I just set an amount) but it is clear that the SDK's output runs much more slowly. A large part of the problem seems to be poor management; it stores some values on the stack even when there are unused registers that could easily hold them.

Pat, there is a setting under the Project menu called Build Settings, here you can set from Debug to Release which takes out all the debug information required for breakpoints, etc. Try setting that to release... If I remember correctly, when I tested it in earlier builds, it did help the size of the program (I couldn't actually test the speed effectivly)

For the interrupt installation routine I compiled a while back, the SDK actually optimized better than GCC, but both were very, very poor compared to the hand coded one.

I suspect that in a few select cases, the SDK version will be faster, but in general, GCC's build will be superior -- the Sierra compiler tends to avoid making any major changes in the code logic; it literrally compiles line-by-line. You can look at the ASM code (the .s file), and see each line of C code commented out, with its equivalent ASM directly below. This makes the sim's debugging possible, but it will often ignore possible optimizations that GCC will make.

It seems that whole AMS is written using a non-optimizing compiler: it is very often possible to reconstruct a C source from the code in AMS routines. Some AMS routines are so badly written that I sometimes wonder whether any C compiler can be so non-optimal...

In this case, I looked at the output code (in the .s file it generated), not the size of the executable. The code (in the main loop, anyway) is the same in debug or release mode. Even without counting the clock cycles, you can tell it's worse than GCC code just by glancing at it.