One nice routine would be the ability to fill the entire screen with one color (ideally the 15 home screen colors). That could be handy since there is a white gap between each line of text.

EDIT: This is what I mean:



This wasn't an issue with the CSE version because Doors CSE added an extra line of pixels below text.

This would also allow people to erase the gray status bar at the top of the screen.

DrDnar: FormReal equates are around the following:0020DA4h ;0020DA8h ;0020DACh ;0020DB0h ;0020DB4h ;0020DB8h. Sorry, I would look through and tell you myself, but I don't have the time. Thanks!

DJ: I already have the workings of a Basic library for the CE, but I am waiting to see what Kerm and others are working on. It would be relatively easy to install a parser hook somewhere so it wouldn't get lost, and to attach these routines to it.

I have an idea for your program, can you change size of the text? Hitting mode brings up smaller text so its got to be possible.

The smaller text (also shown when using the Text() function or when you hit ^ in MathPrint mode) is a different font. TI uses two fonts - the big, fixed-width one shown on the homescreen and the aforementioned small variable-width font. There's no way to change the size of the text as far as I'm aware, unless you include a custom font (which would look weird on the homescreen, since each token would still take up the same amount of space)

DJ_O, the gap the OS adds is actually two pixels. It appears to be intended to prevent text from overwriting the dotted horizontal line certain operations trigger. Unfortunately, I don't see any way to tell the OS to paint over that dotted line. But I have added a routine that draws a colored rectangle.

andressevilla, the OS is hard-coded to use a large, fixed-width for Output( and Disp. You can set a custom font, but it's still fixed-width. Without the ability to make apps, it's somewhat unsafe to do so, because RAM hooks can be overwritten. That's also why this is an assembly program, and doesn't hook into a function like real( like most BASIC libraries do. You can, however, use the Text( function to draw small-font and large-font text on the graph screen.

Anyway, I got a little carried away adding new functions. So that's why the update has taken longer than I said it would. New functions include the ability to get special tokens (I figured it would make sense for a program named TextLib), number-to-string conversion, a GetColors and SetColors functions that deal with both the foreground and background colors at once, a FillRect function, and some bitwise functions. I also fixed a bug on the TI-84 Plus C SE with reading from the text buffer.

The new version is a lot bigger. The largest functions are NumToStr, which doesn't seem large until you add the code to tokenize the string; GetTokenByte, which has to check for the existence of the string and whether it is archived, and then parse it to find the given token, and extra code to allow returning a one or two byte list; FillRect, which has to do a bunch of simple math before calling the OS _FillRect routine; and FillRectRepaint, which has a loop to redraw glyphs. I also added a relatively large custom function for converting floats into Z80 integers, allowing BitTest to work on full 16/24 bit numbers.

Ah right, two pixels, not one. I didn't check carefully the first time.

You could ask Kerm how he painted the dotted line area in Doors CSE, but it most likely uses hooks. I can live with the extra line gaps, although I guess the rectangle routine or even screen filling would alleviate the effect.

Anyway good job

I use a fonthook to draw the missing two pixel rows in Doors CSE. I did extensive reverse-engineering to determine that while I can use flags to increase the size of that gap, it cannot be decreased beyond 2 pixels.

Ah right, it was the font hook.

And DrDnar nice update, by the way. The routine that changes the colors on the home screen without erasing the current characters was a nice touch.

A feature suggestion for future versions would be the ability to fill the entire 320x240 screen (including the gray status bar with the battery icon at the top) with a color. What I currently do is that I use your screen inverting program, ClrHome then run your screen inverting program again so that everything below the gray status bar ends up being black.


EDIT: Actually, integrating that screen inverting program into your TextLib would be a nice idea too, I think.

While I understand the desire for full-screen graphics, to me, full-screen graphics are beyond the scope of this library. Additionally, the status bar is part of TI's standard user interface, and erasing it violates that standard. And I don't want to become responsible for a major library or shell that needs maintaining.

For more advanced capabilities, I suggest waiting for more sophisticated, hook-based libraries to be published. Several people have noted that it is easier to create RAM-based hooks than on Z80 models, due to large amounts of rarely-accessed statically-allowed RAM always being in the physical address space. So other people can write and experiment with hook-based libraries until we get a signing key. But RAM-hook are unsafe, so I'm hesitant to develop one myself.

(Honestly, I expect that we'll end up with 68k-like TSR libraries---and people learning to deal with the relevant restrictions to prevent crashes---because TI will never release the signing key. I predict there will be a lack of interest in developing new educational software for the TI-84 Plus CE because there's no SDK, and TI will never release an SDK because there is a lack of interest. The educational division in TI deals with math and science, so they're probably not familiar with Catch-22.</sarcasm>)

And note that running the Asm( command is slow compared to hook-based libraries because the OS does a VAT lookup on it and then has to move a bunch of memory around to position the assembly program at the right location.

FillRectRepaint does, in fact, erase the current characters. It just redraws them afterwards. On the TI-84 Plus C SE, this repaint is visible.

Additional note: There is an error in the readme. The readme states, "{31}:Asm(prgmTEXTLIB):{35,Ans,8}:Asm(prgmTEXTLIB) will return 1 if shift2nd is set." In fact, it will return 8 if it is set. The intended use of the example was to follow it with something like "If Ans:Then". The text should read, "{31}:Asm(prgmTEXTLIB):{35,Ans,8}:Asm(prgmTEXTLIB) will return 0 if shift2nd is not set and non-zero if set."

Ah I understand the concern actually. And regarding the lack of an SDK and the key, I definitively think that with the TI-84+CE we will have to go back in the Ion/Venus/SOS era. That said, while Asm() is much slower than hooks, the much faster speed of this calculator compared to the CSE makes up for the Asm() slowdowns. And since your lib chains commands, that helps a lot as well.


EDIT: Possible bug report: The GetBgColor command always returns 12 no matter the background color at the current location.

For example, if I fill the screen with multicolor character backgrounds then scan all 10 rows and 26 columns, it still returns 12:


Code:


Basically, I am trying to implement some sort of color-based collision detection.

EDIT: GetColors also have the same problem. It will always return {12,12. Am I missing something there?

You have indeed found a bug, but not for the reason you think. As it turns out, I had a typo in an #IFDEF (used to allow assembling the program for both the TI-84 Plus C SE and the TI-84 Plus CE), which resulted in the program being unable to look up colors in its table. I am uploading an update that fixes the issue.

However, what are you are trying to do will not work anyway, because the OS does not retain color information for character cells on the homescreen, only the characters themselves. You can see this when you press ON to break your program. When you return to the homescreen, you see your old characters on the screen, but they're no longer colored. GetFgColor, GetBgColor, and GetColors return the current colors that will be used for the next text display. The only way to read the colors of a character that has already been displayed would be to read the actual pixels from VRAM again, and then attempt to figure out which ones are the foreground color and which are the background color. I am not going to implement that logic.

(By the way, French users, this library can be compiled for the TI-83 Plus CE, but if I remember correctly, some of the OS calls may be at different addresses, so somebody would have to get to work on a TI-83 Plus CE include file. The reason is that the TI-83 Plus CE exact math engine has extra system calls associated with it, but those calls are not included in the TI-84 Plus CE OS; and moreover, TI didn't make those calls no-ops, but rather omitted them entirely from the system call table.)

Ah right, I see now. I am experimenting for collision detection in another program (my game), which is why I was trying to use the GetBgColor command. I have now decided to settle for the command that gets the character instead.


As for the TI-83 Premium CE, I cannot test your lib on a real calculator because I do not own it, but I did with the TI-SmartView CE emulator that emulates the 83 Premium CE and whatever command I used in your lib worked perfectly.

I ran into some oddities when programmign FF:MF CE: In CLASSIC mode, sometimes when color text is enabled via the ASM utility, two rows of pixels will be missing under character lines, meaning that lines of text with colored backgrounds will be separated by 4 pixels instead of 2. I think this might be a TI-OS issue, but I could be wrong. But the readme states "Some
functions work best with MathPrint disabled." so it might be better to state that in some cases, it's MathPrint that might be preferable to use.

There's a TextEraseBelow flag that should be set whenever this color mode is used.

Ah, I discounted textEraseBelow because it seemed to have no effect when I was playing with inverse text. But now I see it is important for color text. I'm uploading a v1.12 that fixes that. The two-pixel gap issue is now fixed for classic mode.

How can I use the second and alpha coursers?

Ah I see now Kerm and DrDnar. I wasn't too sure if this was something fixable. It reminded me a bit of that one issue on 84+ calcs that sometimes prevented Contra 83 from working properly, thanks to the extra row of pixels with small fonts that appeared under certain circumstances.

Also DrDnar have you checked your inbox on Cemetech?

RE: DJ_O: Assume public domain. I suggest using the AsmCmp function to squish the hex code, not because the CE is tight on RAM, but if the program is unsquished, the OS has to squish the program to run it every time it gets run, so it's a bit faster.

Ok thanks. And yeah I noticed that back in the days when I had no link cable and was using Cirrus Programming' hexadecimal->8xp converter. Everything unsquished seemed to run twice slower.

Is it possible to use the second and alpha coursers in this program?