BCALL of the Day
This is my "BCALL of the Day" page.
As you may or may not have noticed, I've been documenting quite a few BCALLs on WikiTI, and I have been keeping track of the unnamed BCALLs. When I reached the 365 mark, I decided to put up this page to make this process a little more exciting for me (and who knows, maybe for you, too).
Every day, a new BCALL will be documented and explained here with a link to the WikiTI page, if one will exist for it. And don't forget to watch the current BCALL list grow.
The current notes on all the remaining BCALLs and the complete ti83plus.inc file are available as well.
Hopefully within one year of this writing, we shall know a little something about every single 83+/83+SE/84+/84+SE BCALL!
Current number of undocumented BCALLs:
Displays information for a specified variable (archive status, name, and either type or size, as in the LINK DuplicateName and Mem Mgmt/Del menus).
I thought I'd start off the BCALL of the Day hiatus with a semi-useful one, and something that exists in all OSes. Ever wanted to quickly display the name, type, and/or size of a variable at the bottom of the screen like nifty link transfers do? Or maybe the Mem Mgmt/Del menu? Now you can!
This is internally used to display the DuplicateName menu, but it can be used to just display the variable info, or start to go about displaying the DuplicateName menu. Whatever you want to use it for, it actually has somewhat of a purpose! Enjoy!
Throws ERR:DATA TYPE if A is type program, protected program, picture, GDB, or anything above 0Eh.
Never throws it if A=0FFh. This almost certainly has a vital internal use, but is complete garbage to us. Typical.
Adds register E to register A and stores the result in A, I guess.
Look at it, people...LOOK AT IT!
Now, don't even read this any further. Just stop for a minute, click on the WikiTI link, read the text, and absorb it, soak it in...
What in the hell were they thinking when they put this in the BCALL jump table?
Okay, a little background is in order. At first glance, this looks like "add a,e" and nothing more. But no, it's a hook. An empty hook, hence the name.
This actually is used by _initSmallEditBox for some wacky reason. Why? Who knows. I have serious doubts about their need to even use this, but whatever. That's no excuse to put it in the jump table.
What if it's smaller to use a BCALL for "add a,e"? No, not that either. Because that's only one byte, and a BCALL is three bytes. So don't tell me "it's shorter, that's why they have BCALLs that do nothing but set/reset/check flags."
I want you to e-mail me, email@example.com, seriously, if you have an explanation for this piece of garbage. Because I'm e-mailing TI.
I've had enough of this BCALL nonsense...there is NO GOOD REASON TO INCLUDE THIS IN THE BCALL JUMP TABLE. IT IS USELESS. And I'm calling you out on it, TI.
I demand an explanation for this. Why? Was it just to screw with people like me, who pick apart all your little mistakes? Was it to daze and confuse me and make me think "wow, they're idiots" when in fact it was your plan all along, and you feel all high-and-mighty about yourself because you think you've outsmarted me?! HMM?!
Expect an e-mail from me about this. I expect a sane and rational answer for this. And if I don't get it, I'll lose it.
Are you happy now? This is what you've done to me, TI. This is what you've done.
Oh, and yes, this thing put me over the top. There are 212 BCALLs remaining, and I'm over halfway done (I started with 430).
Unfortunately, the rest of them aren't as asinine as this one. I have no doubt that they're all unnecessarily-complicated subroutines to existing OS routines that are just there to screw with me. But you know what? I don't care. I'm going to stick it to you, TI. You're the man, in a negative sense, and I'm going to stick it to you.
Now I'm going to sleep, at peace with the knowledge that you are idiots.
Copies an area of memory to the screen in rows (starting at the top).
Alright, so here's the story. I got up today thinking to myself "You know what? You haven't put up a new BCALL in a while...the masses must have their BCALLs and you're depriving them of exactly that..." Feeling guilty, I decided to pull out my trusty list of cached BCALLs to pick the lucky entry point which gets featured today.
I come across this fascinating and useful BCALL in my skimming through the list, and I say to myself "Sure, this sounds like a good change of pace...I'll document this one."
It had a couple of odd (redundant) inputs, so I decided to pull up the disassembly of it and write a quick test program just to make sure I've got all the facts straight. But it turns out I don't. It's a little more complicated than I first thought.
Frustrated at myself, I decided to say "screw it" and go through the list to find another...and then I found this piece of garbage.
This BCALL was added in OS 2.30. Now, for those who don't understand...that basically means it was added in a (very late) OS update, only for the 84+/SE series. So, what I'm saying is, they've taken it upon themselves to add a new BCALL for us which does ABSOLUTELY NOTHING DIFFERENT THAN GrBufCpy except you have to give this thing MORE INPUTS, and it only works on OS versions that ONLY A FRACTION OF THE CALCULATOR-OWNING WORLD HAS. So even if this was the greatest thing ever, no programmer in his right mind would use it. He'd just simply implement it himself.
I can see it now, some overworked and ready-to-break office worker at Texas Instruments Incorporated thinking to himself "Oh no, I can't believe I almost forgot about this one, I'd better add this BCALL into the table...can't forget that..." Why, you ask? Because this is the next-to-last BCALL added in OS 2.30. Someone actually deemed it necessary to include this. No, really. I know, crazy, right?
I sincerely hope someone from TI reads this and explains themselves, if at all possible. If not, then just stay in hiding.
Expect further outbursts by me as I delve deeper into the crazy and insane world of TI programming.
Displays configuration screen for Press-to-Test and returns the user's choice.
Pretty nifty if you're faking Press-to-Test, otherwise crap.
Finds the name of a Flash application given its base page.
Yeah...this is just a call to FindAppHeaderSubField and copying its contents to OP1. It's also OS 2.30+. So, worthless.
Cleans up flags and hooks before running a Flash application.
An odd one.
Displays the "Press-to-Test" "Reset Complete" message and waits for a key to be pressed.
Same as DispAppRestrictions...useful if you're writing a fake "Press-to-Test" program, useless otherwise.
Displays the end of the catalog on the LCD.
I'm not even going to comment.
Deletes all programs with a type byte of 16h (TempProgObj).
Your typical semi-useful BCALL...but it has an override: 6,(iy+33h). So that's pretty cool...understanding the hook flags a little more...
Ungroups a group variable to RAM.
Pretty cool. Wish I'd known about this earlier
Finds a Flash application alphabetically in memory.
You know, I take back what I said below...this is useless, because this and the one below are 2.40+ only. Glad to know they got to it eventually, though...
Finds a Flash application alphabetically in memory.
This is FindAppUp, only it's case-insensitive. I can't think of a use for it quite yet, but it's good to have around.
Finds a Flash application alphabetically in memory.
Rather than try to find something to say about this piece of garbage, I'll give a random fact about its address: it's the next-to-last entry point in the table. The last one, if you were curious, is equally useless.
This is just a combination of four other BCALLs.
Display "TestGuard 2"/"Press-to-Test" application/program restrictions screen ("APPS HAVE BEEN DISABLED", etc.).
This is pretty cool if you're writing a fake Press-to-Test or Testguard2 program, otherwise garbage.
Returns whether the floating-point value in OP1 is 12 or 24.
I know what you're thinking...but I'd like to believe this has a legitimate date/time use. So let's stay positive.
Forces a keypress at the graph screen.
Now this...is one nifty BCALL. I don't mess with the graph screen much, so I can't truly appreciate the greatness of it, but you can easily force a keypress at the graph screen (like to quit or something) from within a hook (or something).
Waits for either the enter key or ON to be pressed.
Yeah, this would've been useful a few OS versions ago, but since it's 2.30+, it's pretty worthless.
Oh, and it animates the "busy" run indicator, so it's probably the source of the BASIC "Pause " command.
Sets up the Y= editor context vectors.
This could be kinda useful, I guess. It's no different than "ld a,kYequ \ B_JUMP JForceCmd", really, but I suppose with this you could get the page:address of the cxMain vector and tinker with it for some reason (maybe even back it up to the previous context vectors, so the OS will fall back to the Y= editor if something goes horribly wrong). Or that could all be complete nonsense.
Gets the byte located at a specific offset from IX.
I kid you not, kids, the code is this:
I...I just don't know anymore.
Draws the table editor lines.
Creates a group variable backup of RAM.
This is kinda cool (as in, the fact that it exists), but practically it's pretty useless. It requires OS 1.13 or higher, but unless you live under a rock, you probably have at least that.
Displays a custom ERR: message.
Yay, now we can make our own ERR:WHATEVER messages without having to implement all that little menu crap ourselves. Especially useful for applications since it doesn't return.
Sends a Flash application to a connected TI-83 Plus or TI-84 Plus.
A pretty neat little BCALL to come across, which exists on all OSes. This also marks the last link-related BCALL that's likely to ever be documented (there are two or three, maybe four, more that make zero sense).
Sets up memory to return to the homescreen.
This is a pretty dumb one, as most of the 2.30/2.40-added ones are.
Loads the "new group" context.
You have to admit...it's kinda cool, especially the fact that you can choose the group variable it creates (name in OP1).
Sets OP1 to specified polar equation.
In memory of Pi Day...here's BCALL 5314! Not terribly useless.
Sets OP1 to either the floating point value 0 or 1.
This really doesn't even deserve a comment.
Draws a line on the graph screen, ignoring the graphics hook.
Finally, a method of drawing lines without being bothered by that pesky graphics hook.
Draws a vertical line across the entire screen.
HorizontalLine's friendly cousin, VerticalLine, makes an appearance. It refuses to draw into the bottom row, though, ignoring all flags.
Displays the "About" screen from the MEM menu.
Nothing spectacular, though it does provide another 84+-only way of retrieving the full calculator ID (to OP1).
Calls a function directly, by offset, or by name within a compatible Flash application.
Finally, we have an answer to the "IsDevice" string on OS 2.41! And finally, a useful BCALL.
Checks whether OP1 is the floating point value 1, 2, or 3.
It sets or resets two bits of (iy+3Fh) depending on the value, destroys OP2, and throws ERR:DOMAIN if it's not any of them. It's also only available on OS 2.30 or higher.
This has to be one of the stupidest ones yet. I guess they're unknown for a reason, right?
Draws a left-justified horizontal line.
This is a pretty useless entry point. It might have some internal use.