As I don't own a TI-83 or TI-84 calculator, I am not as familiar with them as I am to my TI-84+CSE, but I would like to make some of my programs work on both types of calculators. Here are my current questions:

Is there anyway to detect the type of calculator the user is running the program on without using the graph screen?

Is it possible to link a CSE and a monochrome calculator together and play a multiplayer game, if the same program can run on both calculators individually?

How would I convert this into something a monochrome calculator could use? Would I still have to convert the colors to numbers if I jump over this part of code with a If statement?
Code:

No, you need to use graph screen coordinates, but you can do it without changing graph screen coordinates. We have a topic somewhere about various techniques for that. I tried looking for it, but I'm afraid I couldn't find it.

Yes, GetCalc() uses the same protocol on both calculator versions. And if I or anyone ever gets around to porting CALCnet, that's an option too.

Yes, you would, but it's pretty easy to do. Also, you shouldn't execute those det() statements at all on the monochrome calculators, as under Doors CS det(12) is something completely different, and under the OS, it's nonsensical. Of course, on the monochrome calculators, you have only black text on a white background (and the reverse, if you use DrawText) available to you.

I've found this forum (Sticky-ed) http://www.cemetech.net/forum/viewforum.php?f=19. Which one of the ways mentioned to you recommend? I prefer to stay on the homescreen without opening up the graph, if that's an option.
So what would I use? Is there a library or something that can adjust the darkness of the output to have the different shades of gray?

unfortunately, to do gray on the calc, it needs the screen to be switched really fast to a second, similar image. in other words, for 90% of basic, no. it would be cool if we could control voltage output to specific parts of the screen to get real grays, but the TI doesnt work like that, unfortunately.

Looks like I'm left with learning sprites.

Also which type of multiplayer is recommended and/or faster:

Where the game runs off one calculator. For example, Calculator A is the "host". It gets the inputs from calculator B, processes those inputs with the main game stuff, and gives the outputs to calculator B to be displayed.

Where the game runs off both calculators. Each calculator gets their own variables, sends those variables to each other, processes them, and displays their own output, which should be the same.

The second approach is faster, since there's less data to send and more processing power available. However, it's easier to run into bugs that make the calcs desync.

I understand what you're thinking, but I have some concerns with it.
Sure there's twice as much processing power, but there's also twice as much data to process (a set of data for each calculator). I think there will still have to be a host for the random variables, though.
The calculators syncing is my concern too, especially when running it on 2 different calculator types.

At the same time, the other way does have more stuff to transfer, like you said.


When I tested GetKey( on my friend's 84+, I've noticed that it is slow, even for just one variable. Also, the other calculator has to be doing nothing for it to transfer, what would I have to do to keep the game from pausing to just send variables?

You could set both RNGs to the same seed by storing a value to rand. But yeah, marking one calc as a host sounds like a reasonable idea.
That's just how GetCalc( works. If you don't want to pause the game, you need to find another (probably assembly-assisted) linking method.

Thanks for correcting me, by the way. I ment GetCalc( instead of GetKey(.

Anyway, is there a way to get the sending calculator to unpause itself after the variables are sent? Doesn't the receiving calculator unpause itself automatically?

Unfortunately, no, there's no way to do that. One alternative would be to use BASIC CALCnet for the monochrome calculators, although unfortunately there isn't a version for the color calculator yet. It is a much more comprehensive networking protocol that includes polling for messages, and continuing execution if a response or message has not yet arrived.

oh! by the way, is it possible to enable a monocrome 84 program to run on a color 84 program? I would seriously like to know