Check the status bar when you're in the Memory -> Delete -> Apps menu.

Image example of that:

AMS has a direct ROM_CALL to obtain a FlashApp's size from its TaskID, which is the HANDLE of its ACB: https://debrouxl.github.io/gcc4ti/flashapp.html#OO_GetFlashAppSize . Very oddly, it was one of the ROM_CALLs TI didn't feel like officially naming and documenting, despite the fact it was far more useful than a number of other named ROM_CALLs...
If the TI-eZ80 series doesn't have ACBs, it has another built-in method for obtaining the size of a FlashApp so that the above screen can be filled. At worst, on both the TI-eZ80 and TI-68k series, one can parse the FlashApps' data in the well-documented certificate format.
See GCC4TI cert.h. I hope that the TI-eZ80 OS contains an equivalent to some of those functions.
Also, FWIW, I added certificate parsing functions to libtifiles (new cert.c file) several weeks ago. They're a prerequisite to auto-detecting the model when receiving a FlashApp. They were suggested by Benjamin.

Ah, Kerm, I believe you meant an App's info, not the OS. Sorry, I got confused. Anywho, please remember everyone that there are a thousand or so system calls that still have yet to be documented... And a substantial amount appear to be C wrappers of some sort. It's going to take some time to sift through them and determine exactly what they do.

I think he meant an APP's info actually ? Well, he can reply to make sure.
In fact when you're on the Mem menu, scrolling through the apps you'll see the header on the status bar changes, to display the app's version and the copyright info.
That's what my image was trying to show but admittedly a still image is not as good as a gif, in this case.

One of the markers of cert field parsing functions is code which reads 1 byte if the size part (4 LSB) of the 16-bit field is 0xD, 2 bytes of the size part is 0xE, 4 bytes if 0xF. Field IDs are big-endian.

Argh, that was absolutely my mistake; I meant App info. Indeed, I'm sure that we'll find lots of goodies in the as-yet unexplored system calls, and I hope it didn't seem like I was rushing you. I appreciate everything you've already done to document the OS!

How to achieve double buffering in 8bpp mode:

So, as many of you are aware, the LCD supports changing the LCD base address in order to achieve double buffering. This is a lot more useful than copying the data from the buffer to the screen, as you can simply swap the buffers. However, it is not a simple as setting the new base address and continuing perfectly. In layman's terms there is a time difference between when the address is changed to when it actually has any effect on the screen. Basically, a wait time, kind of like the old LCD I guess. Luckily there are some useful interrupts that can be taken advantage of, and plus the ez80 processor interrupts don't have to be enabled for the LCD controller to trigger them. So, here we go:

Near the beginning of your code, setup the 8bpp mode, and set the LNBUIM bit (2) in the Interrupt Mask Set/Clear Register. The LNBUIM bit(2) tells the controller to generate an interrupt when the LCD base address can be updated (Halfway through a frame redraw). LCDIMSC is the interrupt controller register.

Code:


Now, whenever you want to update the screen, just call this function:

Code:

LCDUPBASE is the address of the LCD base (It's upper because of the style of this LCD). LCDICR is the Interrupt Clear Register; we need to clear the fact that the LCD base address ha not been yet copied to the LCD's current address. LCDRIS is the Raw Interrupt Status register, this tells us if it is okay to update the LCD address (Otherwise is is probable you may get some flicker).

Here are all the defines you will need:

Code:


Hope this helps, and I can't wait to see what you come up with!

EDIT: This is rather important; it appears that some OS calls make references to the data strings:
5452414E53464F524D4154494F4E20202020204752415048494E472020202020415050
and
494E455155414C49545920202020204752415048494E472020202020415050,
Which are:
TRANSFORMATION GRAPHING APP
And:
INEQUALITY GRAPHING APP
respectively. TI did something not quite right here.... Uh oh. These strings are used to display text in the following locations:


Been looking through some RAM lately:

Code:


Also, here's a nifty call:

Code:

Depending on the graph setting, it returns:
DE->Color Indexes
HL->Type Indexes
BC=Number of Equations

Onward!

Here's the listname equates (They are used in the editor; they are just names, ASCII specific): This is technically 100 bytes of safeRAM if you call _SetUpEditor afterwards. But I guess it does mess with the user... But who cares?

Code:


Here's some more calls:

Code:

These draw the text on the second line of the status bar, with the string to display pointed to by HL. Kind of nifty and useful, _DrawStatusBarTextClr calls _ClrLCDAll before executing.

And now for the full list of RAM Equates I have so far:

Code:

It's getting bigger!

Here's some more:

Code:

I have discovered that the _FindApp equates are still in the same general region, however they have been transformed into C calls. This here is what I believe is _FindApp (I'm about 95% sure). The arguments and returns I am working on right now.
EDIT: int FindApp(char* name) or something like that. It should return a pointer to... What? Let's see...


Code:


If anyone would be willing to figure out the arguments for this C call, I would be much obliged. I can do it, but a little help would be nice.

Code:

I'm not exactly sure what you mean by "figure out the arguments" for that second block of code, but I'm guessing that the C source looked something like this (pardon any extra newlines, blame Cemetech):

Code:

*x is passed in hl, and the return value is also passed in hl. For fun, here's what the function would look like in assembly if it were optimized (16 bytes versus 38 bytes):

Code:

On my flight today, I worked quite hard on Doors CE, and in order to try to find some missing RAM equates that I needed, I made a program to display a scrollable view of the contents of memory. Using this, I was able to find the following three equates in more or less their expected locations:
Code:


Edit: Thanks to some help from Mateo, I've been able to make a few additional discoveries:

Code:

D17748h and D1774Bh are used by many C wrappers as the symTable and (pTemp) respectively. This should help some in determining what the C functions do. As near as I can figure, this is located in the DATA section of the OS, which makes sense.


To Dim or not to Dim. That is the question.


Code:

Since no one seems to have investigated this so far, I grabbed screenshots of the character map in the large and small font on the TI-84 Plus CE. Notably, the large font has lost a few characters, and the small font gained at least a lock icon.

I don't see any characters missing. The only actual change I see compared to the monochrome calc character maps (post MathPrint) is that superscript 4 was swapped with dollar sign in the large font. Then there are the two added characters at the end. And although the lock character in the small font certainly looks novel, it did in fact already exist. It just looked nothing like a lock.

Update: It looks like two new characters and higher definition lock icon were actually added for the 84+CSE. So the only change between the 84+CSE and the 84+CE is the switched superscript 4 and dollar sign in the large font.

Interesting, on closer inspection there were indeed no characters removed. For some reason I remembered the plot type icons being in the large font as well. The "space" symbol, the thick forward slash, the thick dotted graph style backslash, the dotted rectangle, and the low (multiplication?) dot are all new, though.

*bump* I believe some of the FormReal-related equates are wrong. Based on experimentation and code examination, I believe the following corrections are necessary (old name equ equate -> correct name):

Code:

If anyone would like to help out discovering and organizing C calls within the OS, a google docs page has been created for easy management: https://docs.google.com/document/d/17Lj-2MN6rHBH1g2vRyEjal9n5dZ9KdHOYiQ3Mkogv0k/edit?usp=sharing

Many thanks to jacobly and others so far

Mateo, I try to change the LCDbuffer address...unsuccessfully
(I'd like it to use one of the faster memory area, like $e40000 )
Here's my attempt:


Code:


Unluckily , I can't see any byte modified on screen
Did I miss something somewhere ?

I succeeded in changing lcdbuffer to $ff0000 area , and resolution 4bpp...
But it seems I can't write anthing : all I can see is a "sparking" purple screen (and no freeze, no reset)