Feature idea:
For now, when we are in the program editor, we have shortcuts to quickly compile an Axe source execute it and come back to editing.
Could there be the possibility to have the same (without the compiling part) for Basic and Grammer programs ?

I'm almost 100% positive it works with basic programs too. Grammer, maybe someday.

Suggestion: Checking the os of a 83+SE before isntalling run on ram clear instead of only making the calc ram clear (it did that with os 1.15)

Oops, that's a good idea.

Ok, I'll fix that when I fix stuff.

I had some stupid ideas you could implement if you get bored some day
-Add an APD function to zStaxe. It would obviously turn on APD then return to the program where it left.
-Add a turn calc off function to zStaxe. It would quit the program then turn the calc off "completely" and "truly". I mean not an APD and not a low-battery trick, but a power down that would trigger the 8scale picture and the startup program at startup.
-Add a still screenshot function (this one is really if you get really bored ). Pressing ON+whatever would copy the "screen" to zStart's clipboard (the same clipboard as the copy-paste function in the editor) in hex format (hoping the clipboard supports 1536 bytes).

Well, I'm not going to to add those functions to zStaxe because zStaxe is simply a way to call zStart's assembly API from Axe programs.


APD inside a program really isn't APD at all, it's just turning the calculator off temporarily and it looks like this:
ld a, 1
out (03), a
ei
halt

 Asm(3E01D303FB76)

Which, as DrDnar wanted me to remind you, is just as good as turning the calculator off with 2nd+ON as far as power is concerned. This is actually the exact same code the OS runs to turn the calculator off.


Properly doing an OS turn off is a bit more challenging. You have to deallocate your program from memory and then run bcall(_powerOff). This one would be a bit much to give you the Asm( for so I guess it should go in an Axiom. The only problem with this is that it doesn't play nicely with shells. Shells do their own thing. A good example would be if you were running your program from RAM. The shell would copy the program to $9D95 and then when you deallocate it, you would delete it. The end result is that you no longer have that program.


And the screenshot thing I could actually do and I don't think it would be that hard.

Edit:
   Optimized

Holy necro-update batman!!

So today I wanted to show someone a video on my calculator, but I didn't have any because they are just too big to keep on there all the time. So, since I never actually put this program into a usable state, I figured I'd finish it.

This program now operates exactly like TruVid and even has the same dithering patterns. But, what makes it better than TruVid for videos is that it also compresses them. The compression ratio varies, but anything from 1% to 70% is possible.

Here is the same 1:30 video rendered in all 8 modes:

b		a b	a
1,376,256  (2%)	1,359,872  (3%)	1,064,960  (24%)	1,032,192  (27%)
o	n	ao	an
819,200  (42%)	802,816  (43%)	622,592  (57%)	458,752  (68%)

The first number is the size of the video and the second number is the compression ratio. The flags are:
-   - Use flyod-steinburg dithering
- a - use absolute brightness cutoffs rather than per-frame cutoffs
- b - use both floyd-steinburd dithering and ordered dithering
- n - use no dithering
- o - use ordered dithering


It's interesting that the compression ratios line up rather well with quality. It would appear that to get the best video and still use compression, you should go for the -o flag. -a -n obviously gets the best compression, but it looks terrible. And I'm not sure which is better between (none) and -b, but they both basically have no compression.


In any case, here's everything you need to make your own videos and the -o video: (as well as sources

And this only works on windows because I use DirectShow.

it seems like it would be a lot easier to just insert a line wherever you are in the program, write whatever you want to find/replace on that, and then press some key combo. it wouldn't take up nearly as much space, either.

Yeah, I would think that it would search for whatever is in the clip board. You would have one combo that is strictly find, and another that is find/replace. The find would simply find, and the find/replace would find on the first press, and replace if it was sitting directly on the specific string.

Well, I made that easy enough that it might get implemented some day. Well see.

Well, I don't have a link cable, so I can't resend the OS. It worked Today, but I am afraid it may crash again. And yes, I did check the contrast. I think the batteries in it are new, but I don't have any backup batteries for it Since it is working for today, my main concern is learning what caused the problem. I have an ASM program on there to check the batteries, and it says they are low, so I will probably need new ones soon. I opened up the calc and used a meter to check all the LCD connections, and they seemed fine. Could low temperature cause an internal failure? It also was working a few days ago, after a few dozen hard resets. It started working today when I did a hard reset, and the message wasn't conjumbled. I pressed on to exit the reinstall OS thing, and when I turned it on, I t worked fine. I really, REALLY want to know why this sort of thing happens so I can prevent it in the future, and help others with their calc problems.

That line right there says to me that it was just a simple crash or something. In any case, here are a few things you can do:

1. Press Mode -> Alpha -> S (ln). And then press enter a few times and wait for the 0 to turn to a 1. If it does indeed turn into a one, then your OS is fine. If it say ROM FAIL, then your OS is corrupt and you'll have to work on resending it. (It's unlikely that it's corrupt).

2. Wait it out for now. See if the problem comes back. If it does, I would assume the "battery + DEL" combo will fix it

3. If it comes back, do "battery + DEL" and then clear all of your memory (2nd -> + -> 7 -> left -> 1 -> 2). Though, before you do this, I recommend you go find a link cable and send your stuff to your computer.

4. If after all 4 of these, you still encounter the glitch, then we can indeed call it a hardware problem. But until then, I'm going to guess it's just a crash.

You can do that in Axe? Also, page 83h? That's the same as page 82h on port 15h=55h models.

Anyway, according to WikiTI:
* RAM page 3, 977Eh–9A7Dh -- previous entries. Destroying this causes crashes.
* RAM page 3, 9A7Eh–9D7Dh -- homescreen graph buffer. Zero after destroying to prevent flicker.

If that's not enough information, try using an emulator: set up a memory watch on all addresses on page 82/83h and see what addresses the OS touches. Or, make a series of programs that overwrite blocks of memory and see which ones cause a crash.

You forgot about $4000-$4080. Use bcall(_fillBasePageTable) to restore that otherwise multipage apps could crash. (Asm(EF1150))

And don't forget Camdenmil that when you swap the ram page in, the high two bits of the address change depending on where you put it. Since I'm going to assume you put it in the $4000 region, the WikiTi ranges would be 577Eh-5A7Dh and 5A7Eh-5D7Dh. (I actually wrote that section and I have no idea why I used $9000 addresses.)