I don't remember, but it should be easy to find in the several released 84+CSE ASM programs
http://www.cemetech.net/programs/index.php?mode=folder&path=/84pcse/asm/graphics/
http://www.cemetech.net/programs/index.php?mode=folder&path=/84pcse/asm/programs/
https://tiplanet.org/forum/archives_voir.php?id=11342

Thanks, Lionel. Yes, a handful of ASM programs have already been released. For what it's worth, the new prefix is $EF,$69.

And change the bcall addresses, the safeRAM variables, the text coordinates and graphics coordinates, the sprites routines used, the LCD update routines used... I just don't think it's worth it, personally.

It's surprising, $EF coresponds with rst $28, and the t2bytetok token isn't used anymore. But not least, the 0EFh token wasn't used before, would it be a new kind of 2-byte introducing token ?

mdr1 brings up a point: When G-T is set, ΔX's coefficient becomes 46. I'll see what can be done about this in a short while.

There's no problem for that :


Code:


The same thing could be done for the "Horiz" mode.[/code]

$EF has actually been the first byte of two-byte tokens for quite some time now. Many of the MathPrint-specific tokens are there, for example.

Horiz equates to Full along the x-axis. Non-CSE's Full is less than 100; CSE's G-T is greater.

This lightweight test covers all of that: If Xmin+E2ΔX>Xmax

This additionally puts the rounding issue to rest.

We could turn that E2 into any number from 95–99 if it would go faster. (I like me some 0b1100000.)

Hi, sorry if this is a daft question, but I'm just not 100% sure.
As mentioned on "Introduce Yourself", I tend to be quite slow in replacing my old calculators. The main reason for this is the prospect of rewriting all the programs I've made whenever I get a new one. So although this thread seems to imply it, I want to know categorically: If I buy an 84+CSE, can I connect it direct to my 84+SE, transfer programs direct, and they'll run? I appreciate I will probably have to edit them for the new screen resolution, but that's far less onerous than writing them out from scratch. So I'm not necessarily trying to create truly cross-compatible programs - I'd archive the slightly different versions each on its own machine - but this still seemed like the nearest thread to post my question. Many thanks to anyone who can help me here.

If they're BASIC programs, going from my knowledge they should run with minimal editing, however the assembly language based programs would have to be completely rewritten if I remember correctly. You are right that they can't be cross compatible, but the BASIC ones should be rather easy to edit and have different versions of.

As Link says, the TI-BASIC syntax for control structures like loops, menus, labels, the math primitives, and so on are exactly the same. The main differences are the bigger homescreen and graphscreen, new arguments to drawing functions to specify color and weight, and a few new commands for dealing with backgrounds and images.

Thanks both for your helpful replies! I knew from the TI site that syntax was the same, I just had a slight worry that if one calculator couldn't receive the other's files for some reason I'd still have to key in all that code the slow way.
I'll go ahead and place that order now, and look forward to learning how to tweak programs to take advantage of the screen capabilities.

Well, keying it in the slow way would be a strange way to do it anyway. You could use TokenIDE or SourceCoder to open and then save the program in the appropriate format. For example, TokenIDE can open TI-82 programs and export as TI-84+CSE programs!

I've been creating some cross-compatible programs so that my friends can use them at school as well.

With this at the beginning of the program:

Code:


Is there a way to optimize this?

Code:

The best I can come up with is based on this logic: 7+C6 = 1+6(C+1), 13+C12 = 1+2*6(C+1), 19+18C = 1+3*6(C+1), and so on. One way we could optimize this therefore would be:
Code:
This approach saves 2 bytes per line.

Okay. Thanks. I should have seen this earlier.

Not at all, it takes a great deal of practice to find the patterns in such code and build up an expanding mental library of tricks you can use to optimize TI-BASIC code. Out of curiosity, if you have my book, have you read over the optimization chapter?

Actually, I got that book over Christmas. I have yet to read the optimization chapter but I will have a look at it. I must say that it has offered much help so far.

I'm glad to hear it. I don't want to continue hijacking this topic too much, but please do let me know if you have any comments or suggestions, and if you would have a chance to write a short, honest review on Amazon, I would be very grateful.

You were right, it worked! I just transferred archive groups direct from old to new , and they ungrouped and ran perfectly. According to the manual, p341, Assembly programs would transfer successfully too (but not from CSE back to SE). However, as mentioned I don't have any of these! Maybe I'll try to learn how to do that too, now I've joined this site.

You're very right, and somewhat wrong too! Now that I've begun to appreciate the tools available from this site, I definitely intend to learn my way round the skills you mention. It's great (even if rather late in life) to discover that such wizardry exists!
Yet you should also recognize that there's quite a large number of people like me who have only really learned what TI publish in the manuals. Indeed, I'm widely regarded as "strange" already inasmuch as I read a calculator manual right through: most pupils I teach, and most colleagues, have a rudimentary Casio scientific and don't read (or even keep) its manual at all.
But don't worry, I know you didn't intend your post as an insult, but just to make sure I could see what I ought to be doing instead.