why all of a sudden is ticalc the last of the big 3 sites to report such important news? I mean, even ACZ and DimTI had this before ticalc..

Well ACZ posted it since they got the message directly (Dux did that is); Dim-TI simply was online at the right time. Not everybody sits online all day so that we can report news to you.

well, admission of inferiority is the first step to recovery. I knew about this news about 24 hours ago.

I was the second person to find out about it straight from the source. No big deal. Get on w/ life.

So did I.

After consuming some 128 or more ounces of Moutain Dew, I only have one thing to say: Yeah ACZ baby!

(I just had to do it Kirk, you know I did)

I don't think TiCalc was the last to report the news of the petition. I sent the petition to Texas Insturments so I was the one that recicved the response in my Inbox. Then I decided that I would give all the sites the news about the petition. So I sent one email to news@ticalc.org, adam@calc.org and mattchris@ti-files.org. The email that I sent was sent late on wednesday night. So whoever got to their computer first the next day was probably the first to post it. I don't think that Ticalc was slaking at all it they just did not get to their computers first. Big deal!
I apprecaite all the sites that put the news about the petition of their site. I would also like to thank all of you yes all 650 of you I guess 649 without me, who signed the petition. Without these people the petition would have never been sucessful.

---
Matt Peresie
matt@calc.org
matt.cc.st

Hmm..a bit off the topic, but has anyone noticed that the solve() function acts a little strange on the TI-89? When I solve a system with equations like (2x+1)/(3y-7)=4z the calc sort of freezes up and takes forever to get the solution. However, if I simplify all the equations so that there aren't any variables in the denominator: 2x+1=4z*(3y-7), it solves it almost instantly. Anyone know why that is?

86's do the same thing who knows

It wouldn't freeze up like that if you didn't have DoorsOS or Plusshell installed.... I tried that solve() equation you posted on a "clean" 89 and it was fast - not slow as you say. ::shrug::

SK

Symbolic equations take a lot of memory, even for simple functions that you can do mentally. As a general rule, the more you simplify the equation, the easier it will be on the calculator. It also helps to split it into parts -- try storing the numerator in a, the denominator in b, and typing solve(a/b=4z,z) -- it will be much faster.

It's not DoorsOS or Plusshell that's the culprit, it's the memory used by the games. The more free RAM you have, the faster the calculations will run - that's a given on any of the calculators, but most obvious on the 89/92(+) because they have symbolic manipulation.

-Scott Noveck (SMN)
smn@calc.org
Lead Programmer:
Pokemon 89 - Zelda 89
http://ccia.calc.org

Sean is correct. I have had problems with that situation before when I had DoorsOS. I love the shell, but it sometimes didn't allow me to solve one as simple as solve(2x-3=7,x). When I reset my calculator it could do it fast and easy.

What is a SDK anyway?

Software Development Kit

That's great, we got informations... BUT i think this is not enough:
We got only ROM_CALL, we don't have their parameters. We don't have any hardware info, and WORSE, some of the info they give us are WRONG.... For exemple they said that their is not relocation table for the EXEC function... BUT there is one; At the end of the file but without the extension F3 used foor asm format...

They are waiting too long...

Kty

Maybe you don't understand what relocation is. Relocation is the ability for a program to execute anywhere in RAM; not only should EXEC strings be relocatable, but so should asm programs (.89z), otherwise a shell is needed. There is no such "relocation table". So there is nothing wrong with the information TI gave us.
And the include file is very helpful, not because it tells us how to use each ROM call, but because it tells us which each ROM call is. For instance, it is now known which ROM calls will perform which BASIC functions and only a small amount of disassembly is needed to find the parameters.

I should add how cool I think it is that TI borrowed the names from ROM calls we already discovered when putting together this include file :-)

In fact, it is the contrary :)
The function names have been found by David Ellsworth for Fargo II, and he has found many names (HeapAlloc, etc..) in the ROM itself.

So TI didn't copy our names, but we did with theirs =)

Xav

Maybe you don't know what you are speaking about :
there IS a relocation table at the end of the string.

It has the same format as in the ASM format.

I have tried it, so I know what I am speaking about.

Besides, I think TI is laughing at us : their information are not usable at all...unless one disassemble some part of their system, which is forbiden by their license, of course.

maybe there's some sort of table at the end of the string, but it has nothing to do with relocation

It is a relocation table.
To be sure we are talking of the same thing, here is a description :

When you use a label, not relative to pc, like this :

Label:
lea Label,a0

then an absolute long effective address is generated. The problem is that the assembler do not know where the program will be in the memory at its execution time.
The table at the end of the string is a list of offsets that need to be relocated and offsets they should point to.

If this is not relocation, what is it then ?

Shells allow for absolute addressing, I thought it was done by copying the program to a specific address, but maybe the shells use some kind of table. But anyhow, those are only shells; a normally compiled program needs to always use relative addressing or it will crash. So TI's information is not wrong.

>Shells allow for absolute addressing, I thought >it was done by copying the
>program to a specific address, but maybe the >shells use some kind of table.

DoorsOS and the TIOS use a relocation table to make sure that all references to non PC relative adresses will be correct

> But anyhow, those are only shells; a normally >compiled program needs to
> always use relative addressing or it will crash.

I'm not sure about this. I think that all OS's have to ensure that they relocate progs before they run them

>So TI's information is not wrong.

It is, because they don't say that there is a relocation table.
But it is not, because they don't say that there is no table :-)

Well, I tried compiling using xdef _nostub and it kept crashing. I asked Rusty about what was going on and he told me that I needed to make all my labels use relative addressing, which remedied the problem. I really don't see why the program would have crashed if ti-os were able to handle absolute addressing -- or why TI would have said it can't. I suppose you know more about it than I do .. so should I believe you? heh
btw, you need to put a _nostub option into doors os :-)

It is wrong since they say :

>The string argument must end with four "zero" digits (0000).

Which is not true when you use a relocation table.

And :

>The Exec command expects the string to contain relocatable instructions. This implies PC-relative
subroutine calls and jumps and PC- and stack-frame-relative local data storage.

We are not obliged (as they try to say) to use only relocatable instructions since there is a relocation table at the end !

They gave us wrong information because they hide some things to us and say they do not exist.