As you my know, the TI-84 Plus C Silver Edition has a 10x26-character homescreen, while the TI-83 Plus and TI-84 Plus families had 8x16-character homescreens. Your first impulse might be to take all of your TI-83+/TI-84+ homescreen math and science programs and games and re-format them for the 10x26-character screen, releasing special TI-84 Plus C Silver Edition-only versions of your programs. There's a better solution: you can use some tricks in pure TI-BASIC to detect if you're running on a TI-84 Plus C Silver Edition or not, and make the same TI-BASIC executable adapt to the homescreen dimensions of the current calculator. There are two steps to this. The first is to figure out what sort of calculator you're running on, and the second is to use that information to generate homescreen output appropriate to the current homescreen size. Of course, there's no reason that you should be restricted to using this trick to figure out the maximum coordinates for Output(; you can also use it to decide whether to use color codes or not (pro-tip: use 10 for blue, 11 for red, 12 for black, and so on instead of the color name tokens, so that your programs will be loadable onto the older calculators).

To detect the current calculator model, you can use the fact that the graphscreen is now 265 pixels wide instead of 95 pixels. The following chunk of code will set C=1 if you're on a TI-84+CSE, or C=0 if you're on any of the black-and-white calculators.
Code:
This code first saves the graph window, to be polite. It then sets Xmin=0 and ΔX=1, which will automatically set Xmax=94 on a TI-83+ or TI-84+, or Xmax=264 on a TI-84+CSE. We can then set C equal to Xmax>94, which will be true (1) on a TI-84+CSE, or false (0) on a TI-83+ or TI-84+. Then, based on whether C is 0 or 1, you can make your programs adapt to the current calculator model. Some examples of how it could adapt:

• If you are drawing a scrolling tilemapper sort of game on the homescreen, you can display 8+2C rows and 16+10C columns of the map at a time, which will work properly and fill the screen on all TI-83 Plus/TI-84 Plus-family calculators.
  
• If you are making a vertically-scrolling game or program, you will know that the homescreen is 8+2C rows tall, and that if you want Disp to always display on the bottom row, that you need to perform 8+2C dummy Disps first.
  
• If you are writing a graphscreen game, you can either make different sections of code run depending on the value of C, or you can adapt your Line, Text, and other commands to pick different coordinates based on C. Remember that the default line width for the TI-84 Plus C Silver edition is two pixels unless you tell it otherwise.
  
• If you're using colors, you can omit the color codes on non-TI-84+CSE calculators. Remember not to use the color codes like RED and BLUE directly in your program; otherwise you won't be able to transfer the program to TI-83+ and TI-84+ calculators. Instead, use the numeric equivalents, starting from 10 for RED.

I hope this helps, and I look forward to your own cross-compatible TI-BASIC games. What tricks of your own have you discovered? Is there a shorter/faster way to discover the calculator's model? I'll be expanding this post as suggestions roll in.

My thoughts on this, while ingenious in some aspects, it does tend to make the program bigger than it needs to be. Plus for something like what I did with TIFC, I was able to hold more options on the screen at a time than I was able to do on the normal 84+. I guess it will be on a program to program basis on when this is needed and being able to be implemented.

it really depends on the program. if your making a bigger game, you dont want to have to debug the game for every calc you do. instead, i would have it to where you simply detect which calc version is running the program. if it doesnt match up with what it was coded for, then it simply terminates or something like that.

simply do

Code:

Well, the nice thing is, if you try to throw an 84+CSE program at an 84+/83+, it will throw an ERR:VERSION. Though, the trick Kerm provides would be helpful to ensure that a message is put in that says they need to find a more compatible version of what they are wanting to run.

Hmm, rather than destroying a GDB, might it be better to just back up and restore Xmin/Xmax? Well, I suppose it's slightly less size-optimized that way, but GDBs take space too.

Edit: Here's another possibility.

Code:

I think you mean Ymax, right? Anyway, that's not bad, plus with a second Pt-Change() you could restore the original contents of the screen. However, that would fail if you had a 1:1 point-to-pixel window set up, and I'm not sure what happens to points in color when you Pt-Change() them twice on the TI-84+CSE. I like the way you're thinking, though.

Nope, YMin is at the bottom of the screen

Ugh, facepalm. Silly me. Also, I realized just now that TextColor( is a problematic token. That might throw a wrench into the possibility of this technique being used for graphscreen programs.

Do the 84Cs not have a regular text(?

It has regular Text(, but the text appears in whatever the most recently-set TextColor( is. If some other program set it to white, then things are going to go poorly for your program. I'm curious what happens if you force the version bytes to not flag a program as TI-84+CSE-only, and include a TextColor( command in a conditional anyway.

just guessing based on a past chat, but changing color is simply declaring a string and the string contents being a color, right?

Code:

that would be all you need at the start of a program.

or does setting the color require an actual command?

I am fairly certain that is only the case when the calc reaches that token. I think a quick test program would be in order to check the validity of that statement.

I'll try to write one momentarily..

Edit:


Code:


Ran on the an 83+SE, and it told me that it was for an 84+CSE only. Ran it on the 84+CSE, gave me a red HI. And it didn't error out.

I call graph screen abuse.

Code:

Weregoose: Does the calculator's EOS sufficiently avoid precision errors with that to make it reliable? If so, that looks like the perfect solution.

tifreak8x: Perfect, thank you for testing! That's exactly what I wanted to know. The only caveat is we need to use an editor like SourceCoder or TokenIDE that is capable of arbitrarily setting the version byte (or, I suppose, people could just use a hex editor).

These are all really nice finds! I know that TokenIDE would be especially helpful for making cross-compatible programs in this way because it has preprocessor directives - combining Weregoose's solution with them would create the perfect gate control.

On a related topic, have we confirmed that you can do the same thing in ASM to create similarly cross-compatible programs?

EDIT: Weregoose, shouldn't your code piece be

Code:

(with an = instead of a ≠)

Yup. "≠" was a stowaway from my earlier attempts to justify any use of round() here; for point-widths of one through 2^18 (and—trustingly—negative powers of ten thereof), the answer is "not yet."

I used TokenIDE to write the above code, and throw it both at wabbitemu and my 84+CSE at the same time to test the code. Unless I'm missing something?

Weregoose, your technique is not always available, I think we should use this :


Code:

In what cases would that work when Weregoose's code might otherwise fail?

No, because (1) the two bytes that indicate the start of an ASM program are different and (2) the address where ASM programs are placed in memory is different. Therefore, it would be up to a shell to do something cross-platform, if at all.

Really ? What's the new prefix ?


It wouldn't be a problem as a program is able to modify itself and so to change the addresses.