Okay, with a lot of discussion with Runer112 over IRC/Discord, and a lot of coding, here is an update!
First, it seems like there might be an accuracy issue with the lower bits of xdiv, but that could just be an issue from truncating the input.

xsqrt is averaging ~9183.443cc
xmul is averaging ~9925.527cc
xdiv is averaging ~11107.370cc

Comparing to the old set of routines from a few years ago, division is now almost exactly 40% faster, multiplication is still about 8.5% faster, and square roots are three times faster.

Comparing to the OS routines, multiply is about 3.59 times faster, divide is about 3.65 times faster, and square root is about 9.45 times faster.

Pretty much the one thing the OS has better is converting floats to strings, which the OS, using BCD floats, is wayyyyy faster for. I project that converting to a string could take on average 50000cc with my method, versus maybe 600cc for a TI float (assuming no special formatting).

As an update and backup to Omni, I have been working on some of the extended precision routines. At this moment, I've rewritten multiplication and square roots, and I am about to work on division.

The square root routine is now averaging 9183.443cc, a full three times faster than the previous implementation ! (and over 9 times faster than the TI-OS float algorithm).

The multiplication routine is now averaging 9925.527cc, a more humble 8.5% improvement. (still ~3.5 times faster than the TI-OS float multiplication). A good chunk of the speed improvement comes from a slightly faster 16-bit multiply routine from Runer112, which also has much nicer/more useful output registers.


I had an issue with the new square root algorithm, so for now I have patched it up so that it works, but it's about 1000cc slower than necessary. In the process of implementing this new algorithm, I rewrote some faster division routines and I might be able to get division down below 13000cc, a 30+% speed improvement (3 times faster than the OS routine).

TICalc.org's Program Of The Year polls are open!
For the TI-83+/84+ category, it looks like a bunch of older projects split between two authors-- myself and squidgetx (ticalc profile).

Up for the vote are the following programs (in the order listed on ticalc.org).

Batlib (ticalc link)
Batlib is a huge library for BASIC programmers. It has 120+ functions mostly for graphics and string and data manipulation, list and matrix manipulation, compression, and much more.



CopyProg (ticalc link)
This is a small program that allows users to copy variables from RAM or Archive to another variable. CopyProg2 has a few other features as well (like line reading and reading the names of the variables on your calc). It allows you to do things like copy an archived appvar to a temp program for execution



Embers (ticalc link)
Embers is an ARPG that won Omnimaga Contest 2012. This was a really well put together game. It features good graphics, good AI, and storyline.



FloatLib (ticalc link)
Floatlib is an app that holds many single-precision float routines from addition to hyperbolic tangent. It comes with a built-in reference manual and there are some examples like computing the Mandelbrot Set.



Gravity Guy (ticalc link)
Gravity Guy is "a port/variation of the popular iphone/flash game" of the same name. You basically get to flip the direction of gravity to help navigate obstacles.


LblRW (ticalc link)
LblRW is a small utility for BASIC programmers that lets you read or modify data within the BASIC program, using a label offset. That's a mouthful. Basically, "Hey, I want to store player data in my RPG, let's store it after Lbl PD." Or you can store monster data for quick access for example
(no screenshot, sorry )


StickNinja (ticalc link)
StickNinja was an Omnimaga Contest 2011 entry that earned 3^rd place. It's basically a platformer with awesome Stick Figure and Ninja graphics. Collect coins, destroy enemies; It's got it all.

Oh, I'm glad you figured it out! That was the first mistake I had to fix in my first implementation

13 Nov. 2018
  - Cleaning up code, removing (at least temporarily)
    routines that aren't vital, or useful.
      - Fire graphics code.     **Probably temporary.
      - Factoring code.         **Probably permanent.
  - Optimized CopyHex
  - ConvHexStr is reorganized to be smaller
14 Nov. 2018
  - Optimized ConvOP1 to be smaller, updated performance
    analysis
  - Optimized GetPixelLoc 3 bytes smaller, 10cc faster
  - Optimized ReadArc routine. 3 bytes smaller, 18cc
    faster for archived data, 3cc slower for data in RAM.
  - Removed LoadTSA as the only internal usage was to load
    the ReadArc routine. Instead it is a specialized routine
    that no longer destroys IX. Next savings of 11 bytes,
    even after extended the mov9 LDI chain to a mov13. Saves
    172cc overall (186cc, actually, since no more ld ix,**)
  - Error also takes advantage of mov13, saving 2 bytes.
  - Added a few more fixed-size moves, including mov768.
    Total cost was 6 bytes.
  - ClrHome uses the faster SetSmallMem, saves a byte.
    Makes it 901cc faster, roughly 21% faster
  - I removed the unknown routine I labeled "lbl000", as it
    isn't used anywhere (or shouldn't be!) It looks like an
    attempt at making an off-page call, probably when the
    low mem scared me.
  - Optimized and fixed IsHexTok. It used to accept the
    ' and ' token as equivalent to 9. Saved a byte and 2cc
    when the token was 0~9.
  - Optimized DE_Times_BC. No change in size, 120cc faster
    in the average case. No longer leaves A=0.
  - optimized HL_Div_BC to be 264cc faster on average, with
    a net cost of five bytes. DE_Div_BC is now the
    subroutine, though, and is 272cc faster than if you had
    called it previously. Nearly 18% speed up
  - Fixed SearchString at a cost of 8 bytes, but should
    perform roughly 4 times faster. Also, there is now no
    risk of it entering an infinite loop, an issue the
    previous routine had.
  - SqrtHL is optimized. Actually replaced with SqrtDE.
    Saved 2 bytes, on average 261cc faster (20.17% faster).
    Worst case is still 165cc faster (12.75% faster).
15 Nov. 2018
  - I replaced the Sqrt routine with Runer112's from Axe.
    It is 221cc faster with the small modifications on my
    part to fit the output registers, and 2 bytes smaller.
    That's roughly 21.5% faster.
  - Removed ConvNumBase and HL_Div_C. HL_Div_C was only
    used by ConvNumBase, and ConvNumBase wasn't used
    anywhere in the code.
  - Changed Is_2_Byte. It's no faster or slower, just
    a little more sensible and readable.
  - Removed HexTok and GetHexAtDE.
  - Moved CompatCall so it didn't have to JP to
    IsOP1GrammerProg, saving 3 bytes and 10cc
  - Removed EndHook2 as it appears unused?
  - Optimized ONErr to be 1 byte less, 2cc faster.
  - Optimized TileMap1. 21cc faster, 2 bytes smaller.
  - Removed HL_SDiv_BC replacing the only use of it
    with a wrapper around a call to HL_Div_BC.
    Net 21 bytes smaller. Signed division command now
    averages about 47cc faster.
  - Removed PutIM, ParseFullArgI, CallI, CopyZStr,
    CreateZVar, FindVar.
  - Renamed memory addresses in the Menu command.
    May have messed something up.
  - vPutscr is 1 byte smaller, 3cc faster.
  - Optimized DrawRectToGraphI since it didn't need
    to preserve registers. Saved 9 bytes.
19 Nov. 2011
  - Did some testing and fixed some new bugs.
  - Fixed LoadReadArc. Needed 6 more bytes, saves
    another 76cc.
  - Opted to use interrupts for the Pause routine. It
    isn't as close to 1/100 seconds, but it is more
    energy efficient, smaller, and more reliable.
No screenshots as it's just behind-the-scenes code modifications.

After only 7 years, a real  menu!:

Scrolling up is noticeably slower than scrolling down.

Thanks for weighing in, Stefan, you are probably one of the most knowledgeable 68k/nSpire BASIC programmers here, so you'd really know what was feasible ^_^ And the link looks pretty useful.