ticalc.org
Basics Archives Community Services Programming
Hardware Help About Search Your Account
   Home :: Community :: Surveys :: Should TI sacrifice assembly program compatibility between ROM versions to add new features and fix bugs?
Error!
Failed to query database!

Re: Should TI sacrifice assembly program compatibility between ROM versions to add new features and fix bugs?
Chris Moultrie  Account Info
(Web Page)

This ticks me off. I want to be able to use the flash apps, but I want to run asm programs! TI needs to fix their problems...and just re-relase v2.03...or maybe have v2.03r2 Something like that, whatever. Just have them fix it!

Reply to this comment    12 December 1999, 15:29 GMT


Re: Re: Should TI sacrifice assembly program compatibility between ROM versions to add new features and fix bugs?
Kirk Meyer  Account Info
(Web Page)

This is _not_ TI's problem... Rusty uses a different method for running ASM programs (with libraries, etc.) than using (waiting for) TI's method. TI does not have _any_ obligation to support the ASM programs. Not to mention that, I'd like to see you show how TI should have an obligation to support games on a _calculator_... There is a reason that I tend to stay away from programming games, and it is that game users are very demanding of things that are not rational... Users of math programs usually provide good, positive input.

Reply to this comment    12 December 1999, 23:00 GMT

Re: Re: Re: Should TI sacrifice assembly program compatibility between ROM versions to add new features and fix bugs?
ikecam  Account Info

ASM doesn't neccessarily imply games. They *could* be talking about assembly math programs (although I rather doubt it).

Reply to this comment    13 December 1999, 01:27 GMT


Re: Re: Re: Should TI sacrifice assembly program compatibility between ROM versions to add new features and fix bugs?
Keith Smith  Account Info

There isn't much of a point to have assembly if you can't have a lot of good games. I don't think TI would have even put assembly on their calculators if it weren't for games. There are probably a couple math and science programs that are better than their corresponding BASIC programs but lets get real, assembly is for games and that's why it's on our calculators.

Reply to this comment    13 December 1999, 06:04 GMT

Re: Re: Re: Re: Should TI sacrifice assembly program compatibility between ROM versions to add new features and fix bugs?
Samir Ribic  Account Info
(Web Page)

But after release of C compiler it is very possible
to write fast numerical analyse programs as SPICE
for nonlinear electrical circuits, STRESS for static
constructions, TCP/IP communication software etc.

Reply to this comment    13 December 1999, 07:43 GMT


Re: Re: Re: Re: Should TI sacrifice assembly program compatibility between ROM versions to add new features and fix bugs?
tmountjr  Account Info

I think some people here are missing the point. In fact, the release of Assembly was entirely an accident. It was a loophole that someone found with the TI-85. It was never actually intended to be. Once ASM hit TI, they (wisely) didn't make it a point to integrate it. Instead, they compromised and made it easy for programmers to utilize the loophole. Personally, I don't think TI will ever release official documentation on the 68000 processoor/assembly language.

Reply to this comment    15 December 1999, 04:05 GMT


Re: Re: Re: Re: Re: Should TI sacrifice assembly program compatibility between ROM versions to add new features and fix bugs?
The Quietust

No offense, but I think you're the one who missed the point. TI didn't compromise the ASM issue by making the loophole easier to access, they added direct support for it in their later calculators; namely, the 83+ (and 83?), 86, 89, and 92+ (whereas the 92 used Fargo via a similar loophole).

Besides, TI wouldn't need to release any documentation on the 68000; such information is readily available already.

Reply to this comment    17 December 1999, 01:24 GMT


Error: Your entry for the Subject is too long. It can be at most 128 characters
ComputerWiz  Account Info
(Web Page)

Calcs with loop hole:
82,85,92
calcs with built in support:
83,83+,86,89,92+

Reply to this comment    18 December 1999, 22:10 GMT

Re: Should TI sacrifice assembly program comp atibility between ROM versions to add new features and fix bugs?
Riba

Sure, features and bugfixes make calculators better.

But adding restrictions doesn't: I doubt that any user would benefit from 8kB limit.
Neither should TI try to extort money from users with nasty licensing schemes.

Anyway, most assembler programs won't run with AMS2.0x because they accessed heap or VAT directly. Most programs can be fixed by using appropriate ROM calls instead.
The problem with ROM calls is that they are mostly undocumented (only heap and windowing functions are documented). Perhaps the SDK will help with this.

Reply to this comment    12 December 1999, 16:31 GMT


Re: Re: Should TI sacrifice assembly program comp atibility between ROM versions to add new features and fix bugs?
Nick Disabato  Account Info
(Web Page)

$300 software better have a REALLY GOOD help file. :)

--BlueCalx

Reply to this comment    12 December 1999, 18:15 GMT

Sending this survey to TI
akadajet  Account Info
(Web Page)

I think that ticalc.org should send the results of this survey to TI.

~Jonathan Taylor

Reply to this comment    12 December 1999, 18:12 GMT

Re: Sending this survey to TI
The_Professor  Account Info
(Web Page)

The results are to close (about 40/60) to send to TI (at the time of this writing), but it would still be good to send the results if all of the comments were included.

I think that they should update bugs and add features, even if all ASM programs don't work with the update (as long as it is a big update - like AMS 2.03), but introducing limitations is stupid. What TI should do is release AMS 2.04, with no 8k limitation for ASM programs. The only place an 8k limitation would be OK is if the release a free SDK that only allows flash apps of under 8k to be designed - even then, there should be no limitation, but at least the limitation would only apply to new programs.

Reply to this comment    12 December 1999, 18:28 GMT


e, pi, and i - those are the best numbers
The_Professor  Account Info
(Web Page)

Sending the comments to TI would be especially good with that Big "I agree", ect.. chain at the top of the page.
And sending it to TI would make sure that TI has read the comments and thought about the error of their ways. (hopefully)

Reply to this comment    14 December 1999, 00:20 GMT


e^(pi*i)+1=0
Gary Moorhead  Account Info

They would never actually read them, they would hire a croney to read and interpret them then the croney would look and see us split about 50/50 and say the public cannot decide on what they want.

Reply to this comment    19 December 1999, 04:01 GMT


Re: Sending this survey to TI
Nick Disabato  Account Info
(Web Page)

This implies that people from TI never look at our web site. :p

--BlueCalx

Reply to this comment    12 December 1999, 19:24 GMT


Re: Re: Sending this survey to TI
Etec  Account Info
(Web Page)

Don't worry ti does look at your site, they even have it posted up on their site.

Reply to this comment    14 December 1999, 00:48 GMT

Re: Should TI sacrifice assembly program comp
Joey Mavity  Account Info

I think part of the reason that people voted 'yes' to the survey is because they feel no matter what TI does someone will find a way around it. If it asked "Should TI sacrifice assembly program *capability in *future ROM versions to add new features and fix bugs?" I'd have definately voted no. But look - 4 day's after the release of 2.3 there are already four or five working games.

Reply to this comment    12 December 1999, 18:48 GMT


Re: Re: Should TI sacrifice assembly program comp
rob smith  Account Info

well, when 2.01 was released, not by ti, we had 4 or 5 games then, now some of them don't work, othello, frogger, i think ti will never get rid of asm programmers, couse asm programmers will hack

Reply to this comment    13 December 1999, 14:09 GMT

Re: Should TI sacrifice assembly program compatibility between ROM versions to add new features and fix bugs?
Caio Assuncao  Account Info

The question here is not whether "TI should sacrifice assembly program compatibility between ROM versions to add new features and fix bugs?" The question here is whether TI calculators are Game Boys or the marvelous helper that allows us to understand math. I'm sure when TI came out with the first calculator they weren't thinking about games, and I'm sure that more then half of their users aren't worried about games. P.S. Yes, that is right, TI calculators not only can run games but they can do math too! Incredible hu?

Reply to this comment    12 December 1999, 20:00 GMT


Re: Re: Should TI sacrifice assembly program compatibility between ROM versions to add new features and fix bugs?
Mehdi Tibouchi  Account Info

Definetely.

*But* ASM could be a powerful scientific tool, as well, if TI provided decent APIs on an official basis. The "let-em-hack" attitude is not really productive, imo.

It would be great to be able to use ASM for advanced mathematics applications, beyond the scope of TI-Basic. Algebra for example (I'm into Galois Theory, and TI-Basic won't do it).

Besides, I do not dislike playing games on my calculator, however scarcely I actually do it. It is not a Gameboy, but a small computer (with the same microprocessor as my very first Macintosh, in the good ol' days). And every respectable computer platforms enable their users to play games as well...

Reply to this comment    12 December 1999, 22:35 GMT

Re: Should TI sacrifice assembly program compatibility between ROM versions to add new features and fix bugs?
Reno  Account Info

could that 8k limit thing be a problem that occurs when you gain the ability to use flash apps? I know the 83+ has this and it can run flash apps, so I'm just guessing here. No flames please :P

Reply to this comment    12 December 1999, 20:32 GMT

1  2  3  4  

You can change the number of comments per page in Account Preferences.

  Copyright © 1996-2012, the ticalc.org project. All rights reserved. | Contact Us | Disclaimer