I found an error in the way the token hook is handled. When you copy the text string to ram, I noticed that you don't actually configure the first byte of the string. Since most of the tokens end up being somewhere in the 01xx range, the first byte of the ram string is 1.

But here's the problem. On closer analysis of how this hook works, that first byte actually means something. The format looks like this:

[Key code][length of string][string]

Where key code is the actual key you press to signal the token. As you can see, the key codes you are returning are incorrect and then that leads to all sorts of problems. (01 translates to right, when you use axe tokens in a Recall queue, the calculator hangs because tokens aren't actually being inserted)

So the simple fix is just to put the proper key codes in. The quickest way to get the proper key code is to simply put the token in DE and call _GetKeyPress, that will return the proper key in A.


Edit:
    If you are going to call _GetKeyPress from within your hook, make sure you temporarily disable the hook. Otherwise you're going to have fun with recursion.

Can you elaborate on this problem? I haven't noticed any problems with the hook in my testing of it. And I can't seem to cause any problems by recalling strings that contain Axe tokens or by entering Axe tokens into the recall prompt.

Without displaying numbers, an optimized z80 assembly loop structure could count to 10000 in about 1/30th of a second. Although I would not recommend comparing processor/language speed by seeing how fast they can count to 10000, simply because there are multiple variables that will skew the results an extreme amount; display or not, scroll or not, how fast the system text routine is, how the screen is updated, and so on. If you have a project in mind, I would say the best way to compare speed is simply to start coding the project for both platforms and compare simplified, test versions of them.

Hmm, so the folks that have received theirs, do you receive an email after you made your selection?

I've sort of been wondering this too... I submitted my assessments on Thursday of last week and received an email congratulating me and asking me which prize I wanted. On Thursday at around 10pm EST, I responded that I would like a Prizm. It is now about 6 days later, no response and no Prizm.

I think just returning the offset would work well. And for programs that do want traditional error scrolling, perhaps you could add an API entry point for scrolling to the error? The program or application could clean itself up after the compile error and then give control back to Axe to handle the rest.

As a temporary fix, I would suggest putting a +1 before the variable in the final argument, like this:

Copy(SizeX*SizeY→P-1+L₁→N,N+SizeX,+1P)^r

I know it looks strange, but the issue is a faulty optimization that relies on the final argument being just a variable, so putting in that +1 avoids the optimization with minimal size cost (1 byte). And yes, that is valid syntax. Axe has very loose syntax rules.

The easiest solution is to test your program in Wabbitemu without the skin enabled. You should then see Wabbitemu's built-in FPS feature on the bottom of the window, which should be accurate for any Axe program. (It may not be accurate for assembly programs with custom screen updating methods, but you don't need to worry about that)

However, if you need an actual FPS counter built into your program, I would suggest using interrupts in your program and using them to keep track of and display an approximate FPS.

Here's a bug that's my fault. The tokenhook.inc file that I suggested you include in the Axe download must've been some strange unfinished version that I accidentally uploaded, because it doesn't even assemble correctly without errors. I have re-uploaded a correct version: http://www.ticalc.org/archives/files/fileinfo/445/44517.html.

Draw0 isn't a routine you should be calling, I just have that label there as an optimized way to combine the routines that redraw the left and right edges. DrawC was my old method for redrawing the left and right edges that I got rid of because it was less optimized than DrawR and DrawL. I guess I forgot to remove the references to it.

Regarding shifting more than one pixel per frame: is this really necessary? It shifts very quickly already, I think it's something like 72 vertical pixels per second and 55 horizontal pixels per second with only one pixel shifted per DispGraph. But if you really wanted to shift more than one pixel per frame, you may as well just perform the 1-pixel shift in a loop, because there isn't a method for shifting multiple pixels at once that's much more optimized.

I could make it work with a map larger than 256*256, I think you'd only have to tweak a few numbers. But do you really want an image larger than 256*256? A 256*256 image is already 8KB, if you go larger than that you may not even be able to fit the images in RAM.