Another bug ?
I have this in my prog:
[]→°Test .état
This gives an error, and jumps on the first "t" in "état". I guess it's because it didn't get that the "." started a comment but why ?

Thanks for the report. I looked into it and was able to fix it pretty easily. (perhaps deceptively so?) If you'd like to grab the fixed version and confirm that I didn't horribly break anything, you can test the developmental build.

That's not really a bug. Quigibo added this undocumented feature for easier Axiom prototyping, and it's an easy enough thing when the Axiom is in RAM because you only need to change the VAT type byte. But when it's in archive, you have to unarchive it, change the VAT type byte, and then archive it again. And unarchiving/archiving operations are potentially complicated to pull off safely mid-compile.


EDIT: As Streetwalrus pointed out in the post below, this behavior is actually documented. Here's the official documentation:

The code must be an appvar in ram or archive.  However, if you have it as a program in ram, Axe will kindly convert it to an appvar for you.

Considering the delay would only be a hundred cycles or so, compared to the ~60,000 that DispGraph takes, I'm not worried about the delay time being significant. And it would probably only costs 3 bytes.

I have 2.55MP, and I almost always use MP in my math classes. It's especially nice in the classes I'm taking now, one of which uses matrix math and the other of which uses integrals and summations. And I don't think I've experienced any bugs with it, only a few incompatibilities with Omnicalc and zStart that I can't blame TI for.

Speaking of which: opening the editor with MathPrint enabled in the latest official build of zStart (no small font editor) always leads to a crash.

You can indeed jump to/call arbitrary addresses in native Axe. But I'd propose that doing anything that results in running custom assembly code is against the sprit of the competition and shouldn't be allowed.

By "shakes like crazy," do you mean like this?



The Game Boy has a screen size of 160x144, while the calculator has a screen size of 96x64. To make the former come close to fitting on the latter, it is shrunk by 50% in both dimensions to 80x72, squishing every square of four pixels into a single pixel. I believe the emulator achieves this by quickly cycling through all four source pixels to display for each output pixel. One very important thing this does is retain some level of text readability. Compare this:



To what it would look like if it just statically selected one out of every square of four pixels:



Some characters look pretty good, but others are missing parts and are completely unrecognizable. This made the text in basically every game unreadable, which was a huge problem. Non-text graphics also suffer a lot when downsized statically:



I can barely tell that the figure on the right is Red/Ash, and I absolutely can't read any of the version text.

If you want a somewhat clearer image, the only option is to zoom in with the + key (you can also zoom out with the - key), although you will of course be cutting of parts of the screen in doing so. Zoom levels under 100% will still have the "flickering" effect, but should be less pronounced at higher zoom levels. You can zoom all the way into 100% for the original, crisp graphics, but your viewing area will be severely limited if you do so. You can also enable grayscale by pressing Graph/F5, but be warned that it doesn't look too great when zoomed out; I'd just recommend sticking to the black and white mode, then. For more zoom/graphics controls, refer to the readme.

If this wasn't the shaking you were talking about... well then I'm not sure what to tell you, and I wasted a lot of time making this post.

To make it easier for people that come here later, please add [SOLVED] to the topic title and edit your OP.

Since I happened to be around, I have done this. But yes, this is good advice that we should probably all do for own topics when we can remember to.

Yeah, it's the same. I just like to know exactly where and how many bytes I am copying so I always give the three arguments

I like this syntax more as well. The copy command can copy any kind of data and doesn't seem like it has much business performing buffer-specific logic. The one-argument version is exactly the same as the much more appropriately named and categorized RecallPic, and the two-argument version could just be a two-argument RecallPic or StorePic. For those reasons, I've actually had ideas of simply removing them.