For the delay, do you mean the delay between writing to select a group and reading the result? At 6MHz, 8 cycles has always always been the traditional safe delay to put between out (1),a and in a,(1), although some implementations have been known to use 7 cycles. At 15MHz, I think the 16 cycles that thepenguin77 has suggested is not enough; Axe used to use 22 cycles and certain people reported that their calculators had issues even with that. I'm not sure of the exact number, but to be safe I'd go with at least 32 cycles or so of delay, if not more. An extra few cycles in a routine like this won't hurt overall performance anyways.

I guess I have one or two more questions for now... Sorry for the slew of questions but hopefully they'll help clear things up for people besides myself as well.

• I'm assuming that we are allowed to pre-calculate and store the values of the first few prime palindromes, like the ones with 2 or fewer digits (2, 3, 5, 7, 11), correct? Some algorithms can't really find some of these on their own and instead depend upon them being given. Storing these special cases should take less space and running time than modifying the algorithm to find them itself, and in some ways modifying the algorithm to find specific values is more or less the same thing, right?
• Related to the question above, should we agree upon some hard rule about what values can be pre-calculated and stored? I assume this rule would either have to allow a precise set of values or an maximum amount of values.

I have multiple questions:

• How large of numbers do we have to handle?
• How will speed be measured? Does our algorithm need to be fast for small numbers, large numbers, or both? If both, does one matter more than the other?
• Is there some limit on program size, or does size somehow factor into judging?
• Can we use pre-calculated data that isn't a list of prime palindromes? And if so, is there a limit to what/how much we can use?
• And a non-technical question, can we submit entries for multiple platforms/languages?

EDIT: One more question, can we store some prime palindromes as long as it's not just a straightforward list of them? If so, are there restrictions?

Sounds more like zStart has a hidden bug that is destroying your calc.

2.55MP. Before you bash MathPrint, let me mention some features added since 2.43. They may not help you, but they won't hurt you either:

• The ability to scroll up on the homescreen and view command/response history, and to copy any item in history to the active line (works with or without MathPrint enabled). I use this feature all the time, it's great. It's so much better than repeatedly pressing 2nd + ENTER to try to find a past computation, only to accidentally skip over it and then have to go all the way back around to it. And you don't just have to replace the active line with it, you can insert it into an already partially written expression.
• More graph zoom options. I'm meticulous with my window settings so always set them manually, but if you graph a lot, you might find them useful.
• Some new math commands, like logBASE(, remainder(, and randIntNoRep(. The first two could obviously be done before with a combination of a few commands, but having one command to do it is nice. The third could not be done before, and could be a huge boon to TI-BASIC programmers. You do have to keep in mind that using any of these in a program you plan to distribute will prevent any users of OSes older than 2.53MP from running your program, but for programs/computations just for yourself, they can be useful.
• Stat wizards for more clear use of the regression commands. If you don't like them, just turn them off.

As for MathPrint, we all know it's a little slow, occasionally a little buggy, and doesn't play nice with some assembly programs/applications, like Omnicalc. If you don't want MathPrint, just turn it off. Turn it off and you essentially have 2.43, but with the added features I mentioned above. But if you do want homescreen math to look a bit neater, it's there if you want it. And despite the ridicule you may hear, 2.55MP is not inherently any buggier than 2.43, especially if MathPrint is turned off.

Finally, it's worth noting that the addition of all of these features has caused no reduction in the amount of available user archive. So even if you never use a single one of the new features, you aren't losing anything.

The sprite drawing routines (and for that matter, pretty much all drawing routines) in Axe have always treated the position inputs as 8-bit numbers. Probably the main reason is that it makes the underlying assembly code simpler, smaller, and faster, while still doing enough for almost all uses of the commands. I always wondered in the back of my head if this would ever be a problem for anybody, but I think you're actually the first one to ever come forward with this issue.

Unfortunately, I shouldn't/can't really change it from 8-bit clipping as it is now. There is the issue of increased code complexity, size, and execution time as I mentioned before, but those alone probably wouldn't stop me from thinking about making the change. What would stop me is that, although you use 16-bit positions, I know a lot of other coders and their projects are fine with, and use, 8-bit positions for objects/entities. The issue arises if these 8-bit positions are negative, because the sign information is really lost with Axe's standard, unsigned 8-bit memory read (the value is actually converted to a 16-bit value, it's just a value from 0-255 so the high 8 bits are always 0). And having negative positions is important in some cases, like having sprites that are partly off-screen on the top or left side of the screen.

Anyways, tl;dr: sprite commands use, and must keep using, 8-bit positions. So I think your possible solutions are either to find a way to downgrade to 8-bit positions or to perform initial major clipping with your own code. The first option is definitely easier and more efficient, so I'd be interested to know a bit more about your project and entities to determine whether or not it's possible.

68, 128, freeze

In regard to MathPrint causing weird display issues, I was recently in the process of trying to make a command to disable MathPrint for the duration of the program to combat this issue. But after I had mostly finished it, it appears that it may not even have been necessary. It seems that a simple ClrHome once in the program makes all homescreen text operations following it work just fine with MathPrint enabled. Can someone confirm that I'm not just crazy and that this actually works? In this case I can just cut out what I was working on and advice people to make sure they use ClrHome before any homescreen text operations if they're worried about compatibility with MathPrint.