What are the hex memory addresses of the buffer and back buffer?

0x9340 and 0x86EC?

Ok. Do you know which is which?

First one is the normal screen buffer, if I recall correctly.

0x9340 is "gbuf" or "Plotsscreen", which most iFastCopy clones (and bcall(_grbufcpy_v) use as the buffer. 0x86EC is SavesScreen, which is used most often as a second buffer, and gets destroyed at APD (this sentence was originally in error, please refer to Ben's post below).

Edit: Moved to z80 Assembly, where it should have been in the first place.

plotSScreen (as used by _GrBufCpy) is indeed $9340, but I'd say saveSScreen is more commonly used as a secondary graphics buffer (it is used by the calculator to back up the screen contents when entering APD mode); its address is $86EC.

appBackUpScreen is specific to the TI-83+ (as opposed to the TI-83) and has an address of $9872.

Duh, I knew that; how many years have I spent working with $9872? Thanks, Ben; I retconned my post above yours to not be incorrect.

Ok. And, those are the two buffers needed for 3-level greyscale, correct?

Sorry about putting it in the wrong spot. It was technically asked with Axe in mind, so I didn't think to put it in the z80 area.

Yes you need at least 2 buffers for 3 level gray-scale, at least without large amounts of work. You can actually do 4 level gray-scale with only 2 buffers but its a bit harder to pull off.

appBackUpScreen is the one Axe uses for the "back-buffer" (L3). saveSScreen is reserved for variables and L1.

It takes a minimum of two buffers to do grayscale of any sort because the calculator, being monochrome, stores one pixel in one bit. It saves a tremendous amount of memory (versus storing 8-bit or other size for a single pixel), but it means there are only two possible situations (1 on, 0 off). If you want gray, you obviously need another level; that's why you need two buffers, so you can define 0/0 as white, 0/1 as gray, and 1/0 as black. Having two bits per pixel, each of which has two states, allows you to have 4 distinct levels (0/0, 0/1, 1/0, and 1/1). Hence Axe allows a maximum of 4-level grayscale

EDIT: If you're using Axe, just use L6 for the buffer and L3 for the back-buffer. Those are their names in Axe.

Ok. Thanks Deep. And everyone who helped.

This is to Deep: How do you use the floating point variables in Axe?

I entirely disagree. The only difference between 3-level and 4-level is that you have to display one of the buffers twice as long as the other one, whereas for three-level you display both buffers for the same amount of time.

Acag, if you don't mind me saying, you don't use floating point variables in Axe. There is a way, but you would never do math with them unless you needed precision, in which case you would use Basic. Axe is made so that you can just use your 26(ish) variables and have values from 0 to 65536. The only way I know of (and I haven't throughly checked the new commands) to work with floating points is the Variable->Ans, which stores a 2 byte variable into a floating point Answer variable, which you can use in Basic programs.

You could use 8.8 fixed-point numbers, where the integer part of the number is store in the first byte of the two bytes, and the fractional part is the last byte.

Interestingly enough, that's what Obliterate for the TI calculators uses for the parabolic motion math. For the Prizm verison, I'll be using 14.18 math routines.

I would use Basic, except I need an ability to read data, held long term, in appvars, which basic doesn't support. And, since I'm a huge fan of programs being stable on their own (no external stuff needed), I would rather not need an asm routine or third-party app to do it. That's my dilema.

If you want to just read from a floating-point variable (like the real var A), use GetCalc("varA") to get a pointer to it, and use float{PTR} to get the 9-byte floating-point number and that point.

By doing that it gets converted to a two-byte integer, unfortunately, but if you know how floating-point numbers work you can get the value yourself, in 8.8 fixed point format.

You could just copy the nine bytes somewhere else and operate on it as a floating-point (there are OS routines to do that for you), but I really recommend against it. It's slow, as _player said, and you always need nine bytes to work with.

Well, if A is a two byte number, then how do you do 8.8 without losing data? Can't you just use Copy( on the "varA" pointer?

Yeah, you could copy it and use it as a floating-point. Just remember to keep nine bytes for that. And to do math with it, the OS provides bcalls like FPSub and FPAdd. Just search in the ti83plus.inc file for "_FP". You use them by loading the first operand (nine bytes) to OP1 (E8478) and the second (if there is a second) to OP2 (E8478), then do the bcall (remember it's EF for bcall).

There are smaller ways to do some of these commands, but I won't list them here unless you want me to. Just remember that floating point operations are always gonna be slow.

If you can afford to lose the precision, go for fixed-point It's easier to work with in Axe, too. Addition, subtraction, and division use the same +, -, and / as normal, and multiplication is simply **.

Yeah, if you want, you can list the "smaller ways" here.

And how would you do FP in Axe?