Why would you detect this ? The only interest here is CPU speed no ? Not sure you need 128k of ram nor 2MB flash. Anyway the os can differentiate SE models so it's feasible to distinguish these as for 83+ vs 84+ you can check the OS version string (1.x is 83+ and 2.x is 84+).

how about you just detect if the calc can go in 'full' mode?

Nah. I've been requested to not use 15 mHz mode. Something I plan to comply with.

My theory is this... if we are getting data too often, then we will be not processing the data quickly enough and the game will slow down. THIS is dependent on the base speed of the hardware, so by determining what hardware we are on, I can create a refresh rate for getting data from the server that doesn't overload the calc's CPU speed.

Also, @Sorunome. How difficult would it be to implement the following... a calculator connected to the server. If a new update of this game (client side) is available, we create a temporary downloading program, quit the game, overwrite the local game copy with the update, and then switch back to the game. Like an automatic update... ?

Should work in theory if you can let it create a new asm program, run that, delete the old one and in that new asm program write the enw version, switch back and delete that temp asm prog
Do i amke sence?

The issue about calc speed is that if you take 8 TI-84 Plus calcs, for example, none will run at identical speed. Even if you detected the calc model to fix speed issues, you would still have issues with newer hardware being slightly faster than older hardware.

If it's for link play, I think that the only way to do it would be to do something like this

1st calc (host):
1) Check if other calc is ready
2) Start of loop
3) <game code> (at this point gameplay is frozen on the other calc)
4) Sends data to other calc and tells it it's ready
5) Wait for other calc data
6) End of loop

2nd calc:
1) Send ready state to other calc
2) Start of loop
3) Wait for other calc data
4) <game code> (at this point the other calc gets frozen)
5) Sends data to other calc and tells it it's ready
6) End of loop


That way, there is no risk of calcs getting out of sync, especially if a crappy cable is used or if someone disconnects one end by mistake. It would need to allow the player to exit at any time, though, in case somehow the connection can no longer be made. It would most likely also be much slower.

I recently checked updates but the last time I really checked was last May IIRC. I forgot some stuff over time probably, though, especially that this went on hiatus a few times before (or at least with no public updates)

Second announcement. Anyone willing to do sprites for this game can send me a PM. Sprites should be of a ship, viewing from four angles... looking at the left side, looking at the right side, looking at the front, and looking at the back.

Ship types are Federation, Klingon, Vulcan, Romulan, and Dominion. If you want to see any additional classes added, please post below. This means 4 sprites per ship type. Sprites can be 12x8 or 16x16.

Also, should I draw a set of large sprites (for a close up view) and small sprites (for a farther away view), or should I use one sprite set with a routine to scale a large sprite down if the ship is farther away?