With my limited TI knowledge, the only way I can see to do that right now would be to change the cursor itself depending on what is under it. Of course, that is based on my knowledge of BASIC and not assembly. There may be a way to pull it off in assembly. With my current level of knowledge, I would need to set up an interrupt driven routine that checked what was under the cursor and changed it appropriately.
My current big project is an autorun program (named LOAD on disk,) that will bring up a menu of what's on the disk with descriptions and let me chose one to load and run. Actually very new to disks on the TI. I never had a PAB back in the day, though I do now. Though I'm not even sure if it, or the floppy drive, even work. Don't currently have a spot to set my TI up (working on it.) I'm doing all of this in emulation. Saving up for a decent desk to set up my 8-bit (yeah, I know, the TI is actually a 16-bit system, but that's the era its from,) systems on. Currently have a c128 and the TI. Looking to eventually get an Atari 800 and an Apple II. That would complete the collection of computers I worked with back then. My mid-level systems (16-bit, though again some are technically 32,) include a DOS/Win3.1/Win98 Voodoo system (Voodoo 3dfx driven,) an Amiga 2000 and an Amiga 4000. Those share space with my modern 3.4Ghz Quad Core system.
**dragging self back onto topic** The menu program I'm writing is mainly in Extended BASIC as that is the cart I'm most likely to have installed most of the time. So, put in a disk, hit 2, browse through the menu, and the program is loaded and run. Issues I have with that are what, generally, lead me to an assembly project. The PSTR program was in answer to how slow it is to use HCHAR or VCHAR to put a string up (which are the only way to use the full 32x24 screen.) Not to mention how slow partial screen scrolling is in BASIC. Its also looking like I'm going to have to write my own E/A option 5 (maybe option 3 as well,) loader. I only have 2 games I like right now that require it, and none of the ones I've found load them.
Currently, with what I want to do, my program will eventually autorun when XB loads up. Read a data file from the disk, and display the information. If the data file isn't there it goes to the editor, bringing up a list of all files on the disk. Or I can enter the editor manually to change the menu if needed. In the editor, I would chose the files that actually need to load, give them a meaningful name and a description of the program (mostly games,) in question. Leaving out any secondary files for each program. If the data file is there, it throws up the list and I can scroll through (with the description appearing on each entry as I scroll to it. Each game would have a code to tell my program the proper way of loading it and getting it running.
Some of the things I would like to do are:
1) Use reverse text to show which file is currently selected. Currently can't do that in XB. Can't even, currently, see how to do it in Assembly without going into bit-map mode.
2) I would like to color code each entry by what type of load it's going to be (Assembly Option 5, XB Assembly, XB BASIC, etc...) With a color for programs that will require me to switch carts. In those cases, when I say to load it, it will throw up instructions that I can read prior to shutting down and switching carts. Again, this looks like it will require bit-map mode.
3) Scroll only a portion of the screen as I scroll through the list. This is definitely going to need an assembly routine. I don't remember which machine it was, but back in the day there was a built in routine I used in BASIC that loaded a scroll buffer. Then you called the routine marking a portion of the screen & a direction. It would then scroll the buffer onto the screen from the appropriate position (top/bottom IIRC.) Fairly sure it wasn't the TI, though.
4) Load & run the selected program. This may involve loading an interim loader & clearing out RAM first. My system only has a 32k RAM expansion (assuming the PAB works,) so I can't use some of the memory banking tricks I've read about for the larger programs.
Now, with the name sizes of some of the programs I would like to set up with the menu, I could probably put load type information as text with the program names. As the program name itself precludes a multi-column menu. I also don't foresee having more than 14 programs on a single disk (my drive is probably a SSSD disk, so rather small.) 14 is the key number as I am planing to have 7 lines used up at the bottom (a box with 5 30 character lines of text for description,) and 3 lines at the top for system messages & such (2 lines with a separater.)
So, a pretty big project (for me & my current knowledge.) Right now, I'm looking into bit-map mode for the color coding & reverse text (which makes PSTR obsolete I'm afraid,) and disk access for reading the data file. Though, I might leave that up to the BASIC half. Unless I find an Option 5 (maybe 3 as well,) loader that works, I'll need it for the special loaders I will have to write for the E/A programs I have. One of them is 19k in size, which is probably what is making it difficult to find a loader for. Best I can think of is to write a loader that first moves itself to a portion of memory that the game in question won't be loading to, then load it from there. I found a loader that puts itself at the top of RAM, and was extremely small, so it should have worked. Only it used the DSRLNK & GPLLNK routines I mentioned, which E/A doesn't give XB equate values for. I used the ones from my Mini Memory manual instead, but that could be why it is failing instead of the game itself not liking it. Assuming the game loads at A000 (which is a pretty big assume, I know,) there should have still been quite a bit of space between the game and the loader. Though, I'm wondering now, if it removed itself from the DEF/REF table, would it work then?