So is it possible for me to use this to help me convert TI-83 plus programs(.8xp) to TI-89 Titanium programs (.89p)...

Please someone help me.

I would like to see a ti-basic program that makes the TI-82 like a TI-34 or 30 etc. Example::: In Math class, it is faster to press a button for a exponent then then manuraly type it in. And fractions, and all of those other fetures. It is just simpler and easy. Please e-mail me if someone has an answer for this.

Perhaps SmallC could be the soultion? I am currently working through the manuals to write a header for the 83 and the 85, with the same functions on both. Of course, the programs would have to be compiled seperately, but a batch file could include a "#include <ti83.h>" or sth like that in the file before compiling.
If anyone has got an emulator or a good documentation for the other calcs (and a SmallC port for it), I could extend it to the other calcs.

I know this is off topic but I don't know where else to put this. Is there a program for the TI-86 that can factor like the TI-89 or TI-92? Onw of my friends has a TI-92 and al he has to do is put in the factor program and then type x2-7x+28 and it'll give him the answer in this form: (x- )(x- ). He can type anything he wants and it'll give him the answer. If anyone has a program like this please e-mail me. Thanks

First I'd like to say that your idea is pretty good for the cross compiler. I wish someone had thought of and implemented this a while ago. However one your idea about the multi-calc shell I'm gonna have to say that that idea is pretty dumb. In order to do this first you'd have to have the cross compiler so it'd work on all the calc's. If you had the cross compiler you wouldn't need the shell cuz you could just compile the games for the specific calc you wanted. And if you in fact did make the shell itd be one huge honkin shell! Which would suck for TI-83 user due to the smaller memory size of it so with the big shell their "huge library of games" would be useless because all their free memory would be used by the shell. Unless of course they make one of those Expander thing-a-ma-whatsitz for the 83 then it would work but I don't know if they do or not. In closing I'd like to say that I hope someone does make this fabled cross compiler, it'd be a great addition to the TI community and I'm sure everyone would rejoice and dance in the streets while stark naked. J/k I hope that doesn't happen well the naked part of course =)

how would it take more memory? i don't think the convertor is on the calc, it just converts your standard source into each calc. format...

The shell wouldn't be bigger because of the convertor but because of the part that would find and change the ROM calls. That would be the bigger part and would eat up the memory of the 83 because it i memory impaired.

(to anyone who may still come to these posts)

You don't understand what a compiler is, versus an interpreter. You are still thinking of an interpreter that would sit in calc memory (a "shell") and assign ROM calls to a basic code. Hello? then what would be the point of a COMPILER??? this is not a JAVA type of thing, this is a C++ type of thing where the same code can be compiled under different systems and distributed for those systems.

However, this would still be useless exactly because of the differences in ROM that restrict the functionability of program code by the lowest system it runs on.

A GOOD idea is to build a high-level language as an alternative to ti-BASIC that would compile on a computer to be run on the calc as machine code.

I found HAL on ticalc which would do the required job (contains a library for all calcs, but which is incomplete). If a sprite routine for all calcs was implemented, it would be the cross-compiler you are looking for. Z80-inline-assembly (but platform-independent, of course) can be mixed freely with HALBasic, which contains standard calls for all calcs. There are only two problems:
1. Permanent storage is not supported on the 83 even if it is not too difficult when using ZASMLOAD (so no hex conversion is needed), and also a Send(9prgm can be patched easily.
2. SPRITEs are missing on all calcs except the 85
3. You cannot edit the library as you can in SmallC
4. You need BASIC to call the library and cannot just do a CALL in asm code (perhaps a FNCALL asm macro?) (SmallC also suffers from this, but because its C, you can put arguments on the stack and call the function w/o parameters and only a warning is issued. You know what code is generated)
5. (the most important) there is nearly no documentation about HAL, only examples

I think it would be a good idea except for:
A) The shell for all calculators is dumb now, since we have at least 2 shells for every calculator.

B) There is a problem with memory. You would have to put the Expander SF or Expander 2 Drivers on it with just the shell. What's the point for those of use without an expander?

Actually, Mike, I like your idea. And the idea of one shell for all calculators, although you have to go against all the competition, and some fierce objections will be here, I think that it's a great idea. The only thing is, how are you going to do this? I have both an 82 and an 85 and I can tell you the interfaces are totally different. I can only imagine a TI-92 trying to send to a TI-73. Well, more power to ya.
David Dynes
XaVIëR (BallisTiC Software)

First, I like the idea of a cross-compiler. Not only would every game be the same on all calcs, but the multiplayer games would be cross-calc compatible- eliminatating the need to do what they've done with Ztetris. One thing that is needed, however is to say "this game is designed for a TI-8x or better" due to screen sizes. That way, the compiler could "Center" the screen of a TI-83 on the higher res 85 or 92, but a 85-designed prgm wouldn't run on a 83 (just have the prgm generate an error) or it could cut a portion of the screen off. Second, a shell that has calls made to it would be fairly large, although it would be doable and acceptable with the mem on any calc. What I would perfer, however, is merely a stadard shell. No calls necessarily, but a uniform interface on every calc. Just my two cents.

This isn't a solution for the Z80-based calculators, but for the TI-92, TI-92Plus, and TI-89, there is a cross compiler available. I've got a book, "Microprocessor Systems Design: 68000 Hardware, Software, and Interfacing" that comes with a demo of a 68K cross compiler (and other software) on a CD-ROM that runs under Windows (sorry, not Macs, not Linux). You can also download the software at
ftp://ftp.pws.com/pws/compsci/clements/
The compiler is made by a company that specializes in embedded systems development tools. You can also request a demo of the compiler at
http://www.tasking.com/products/68xxx/demo_req.htm
(I suppose you could also order the full development kit, but I imagine it's probably beyond most of our budgets).
cb

Oops. Two things I left out. "Microprocessor Systems Design" is authored by Alan Clements, published by PWS Publishing Company (www.pws.com). Also, a disclaimer: ** I haven't tried using this compiler myself! I do not know that it works, or that it works like we want it to. ** I plan to try it out in a couple weeks, when I've got some free time, but until then, please don't blame me if you get unsatisfactory results.
cb

You have some good ideas, but easier said than done. First, the cross compiling. If you use striaght ASM, call only ROM calls that are on all calcs, and not specify and ram addresses (use defines instead), all you really have to do is change header files and recompile. But then there are more underlying problems. Such as differences in ports, and how the 82 uses them to access the LCD where the 85 uses the memory. Sure all of these problems can be overcome with a library, but as before mentioned, would be huge. But hey, anything is worth a try. Good luck

Good idea, but ther eare some things to think about:

A) Those that know arom calls well already would have a harder time adjusting to the new calls and thus make it a bit more difficult for veteran programmers.

B) There would still have to be different include files for each different calculator so that the assembler did not go nuts and report errors(make sense? Prolly not, I cant really explain it).

C) Having the shell interpret all the calls would be like an emulator and it would prolly tack on several extra bytes to a shell.

D) There are slight differences in the calcs that would still prolly need slight modifications to the source code before it could be compiled for each.

Thats my 2 cents, agree with me if you like. But Im not sure I know enough about some of this and I may be wrong :(. Oh well, btw, I have been working on an include file that will make porting of ASH 3.0/CrASH games to the SOS much easier. Most of it works but there are still some mods that must be made to the source, though minor.

Jacob Boyce

So, you finally resurfaced... =)
We were working on this a while back, or at least tossing around ideas, when I had to ditch the project. Well, I dug up my old white papers on it, seeing as I lost my website so many months ago... (d'oh)
So, here goes. XCalc revisited. I analyzed the major shell of last year, Usgard, and have had to revise that since the release of 1.6 and of course, ASE for the TI-86. The main updates for assembly shells have involved the use of libraries, and also emulation and primitive file management. However, no one would bother with emulation on any calc other than an 86, due to memory limitations.
What I propose with XCalc is to use a general purpose library directly into the shell. An interface layer, if you will. All programs would make the same pixel routine calls, text placement calls, and so on. Programs would be restricted to the 96 pixel 82/3 limit, but could make use of the extra 32 pixels by expanding the game screen, or other enhancements. A game that absolutely needed more than 96 columns would have to utilize scrolling, or become 85/6 specific. Most games, however, would just give the player a larger game field to work with.
Grayscale would probably have to be an external library, due to its rarity, but an individual version would have to exist for each calc.
Most importantly, however, is the need for an interface plugin layer, so that we can all modify the interface as we like, but also use a standard, much like the CoolShell which was taken into AShell/ASE. The 82 is also behind the curve, lacking proper VAT editing support, a necessary feature for Level Editors, Expanders, and anything else that involves variable addition/manipulation.
Then there's the issue of screen addressing. We have to deal with a port based system and a memroy mapped display, and 2-bit grayscale is too slow on the 82/3. The shell could POSSIBLY use a graph buffer and then run a transfer to the screen port/mem region, but that would mean a 768/1024 byte overhead.
Yep, lots of technical considerations, not to mention we need uniform bytecodes for function calls, a new variable type, and so on.
No wonder I gave up on this... Too much work :(

Hehe, I hate to say it guys, but something that comes very close to accomplishing this was written over a year ago (just after the 86 came out in fact). http://HAL-8x.home.ml.org

Incase you don't know my name I'm the one who wrote the article. I'd like to thank you all for your comments but in regard to HAL I do know that it exists but it is more like basic. It may be easier but the problem is that it's not as highly optomised and pure ASM (which is what I'm talking about) would be.

Use SmallC and write a common #define library (I am currently doing this for the 83 and the 85). You can write asm functions and call them from your ASM code (you only need a different TASM include file with a CALL_ macro for non-85s), so you can optimize your code and SmallC is only providing the function call mechanism and the library. But, however, you would have to use different SmallC versions for every calc (in my case SmallC 85/Usgard and SmallC 83/86) and therefore only a subset of both.

I'm working on an ANSI C compiler for DOS that currently only compiles for 86 and simple 85 stuff, but that will eventually compile for 82 and 83 as well. Check out <a href=http://home.tpu.org/psion/tcc/>my TCC page</a> to get what I have so far. The text on the page is somewhat outdated.