Yep, with the 83+/84+/SE models, there is a delay that is usually not constant. Even on my newer calculators that often write immediately (so have a much tinier delay), occasionally the delay bumps from <12 clock cycles up to around 40. This happens sporadically but seems to happen every few hundred writes. There are times when you can be fairly certain that you have enough of a delay, though, and for some graphics routines, I like to interleave the algorithm with the LCD updates (so essentially compute the new value of the byte, then write the updated byte to RAM and then the LCD). If the operations take a long time, to compute, this can save up to about 35000 t-states at 6MHz.

As an example, say it takes 100 t-states to transform a byte into its updated value. It takes about 45000 t-states to update the LCD on a typical calculator at 6MHz, (longer at 15MHz). So to change the whole LCD buffer, it would take about 76800+45000 t-states per frame or about 120000 t-states (50FPS). By interleaving the routines, you can use the transformation time of 100 t-states as a long enough delay between LCD writes and shave off about 35000 t-states of wasted cycles. This updates the LCD about every 87000 t-states or about 69FPS.

An advantage to this is more consistent timings for LCD updates. I usually only do this when I know that the the byte conversions take much longer than the typical needed delay (I interleave routines in some of the fire animation, plasma animation, some cellular automata programs and a few others that I have written to boost performance).

A while ago, I was trying to think of a way to detect if certain libraries were required for a given program. For BatLib, you would need to check for dim() commands that have a non-negative numerical argument first, then for FileSyst, you would check for first arguments that are negative or strings. For Celtic 3, you would need to check for 'misused' det() commands, imag(). For Celtic 3, you can check if Celtic 3 or DoorsCS7 is on the calc. For Omnicalc, you can check for real(nn,), and xLIB you can check for real(nn) as well, making sure nn is within the appropriate range. For xLIB, you can check for xLIB, Celtic 3, or DoorsCS7. Check the sum() commands for DoorsCS7.

I wrote a file system application last year that, when running a program, looks at the file extension and opens the appropriate app or program. For example, running DonkeyKong.ion would attempt to open an ION compatible shell (ION, MirageOS, DoorsCS7) in order to run the program. However, this requires the user to manually add the file extension, so I wanted to make a super complicated routine to analyse source codes and figure out the best file extensions and for extracting image icon data.

Also, welcome to Omni

Well, remember that (9x+3x^3)/(9+6x^2) is not the end of the modification (see the first post for the best fit dealing with 9 as the first coefficients).

To arrive to the estimation of (9x+2x³)/(9+5²), you can observe that atan(1)=pi/4. Since 22/7 is a good approximation of pi, 11/14 is a good approximation of atan(1).

From here, you can guess the coefficients so that at x=1, (9+a)/(9+b)=11/24 and you get a=2, b=5

Using this, the biggest error is around .00065.

I am trying to get a formula of the form (ax+bx³)/(a+cx²+dx⁴) using the ratio of 353/452 to approximate atan(1).

Actually, series expansions like Taylor series are really not good for arctangent (and ln()). Instead, I used a few terms for the continued fraction of arctangent and then I adjusted values to account for the error in the rest of the terms not included. So basically:
x/(1+x²/(3+4x²))
(next term in the continued fraction divides by 5+?, so I use x² instead of 4x²)
x/(1+x²/(3+x²))
=x/((3+2x²)/(3+x²))
=x(3+x²)/(3+2x²)
=(9x+3x³)/(9+6x²)=f(x)

From there, I leave the constants the same (9 and 9) because those should be the same in the numerator and denominator (as x→0, this makes f(x)→x which is best for series expansion of arctangent around 0). Then I just adjusted the other two coefficients. It is possible that there are even better approximations using different numbers, too.

I have updated the 24-bit floating point routines. Most of the routines have easy input/output. If there are two inputs, it is BHL and CDE. If it is one input, it is AHL or BHL. Outputs for the floating point routines are AHL or BHL. There are also a handful of extra routines, such as:

BC_Times_DE (returns 32-bit result, worst case is less than 700 t-states)
normalise24 to renormalise 24-bit floats
SetInf to return a float as infinity (keeping the original sign)
FloatToUInt to convert a float to an unsigned integer
FloatToSInt to convert a float to a signed integer
SqrtHL_prec16 returns the square root of HL to 16 bits of accuracy.

The actual floating point routines are:

Float24Mul
Float24Div
Float24Add
Float24Sub
Float24Lg
Float24Sqrt

Yes Also, 'GOOGLE.ORG'

I think I figured it out. After looking back through my pseudo-code for the algorithm, I noticed that for n bits, I needed a variable with n bits, n+1 bits, and n+2 bits. I fixed it by taking the last two iterations as special cases. It bloats the code a little more, but it works:
SqrtHL5:
;input: HL
;Output: A
;63 bytes
;749 t-states worst case
ld bc,600h
ld d,c
ld e,c
sqrt16loop:
add hl,hl \ rl e
add hl,hl \ rl e
rl c
ld a,c
rla
sub e
jr nc,$+5
inc c
cpl
ld e,a
djnz sqrt16loop

sla c \ ld a,c \ add a,a
rl h \ rl e
rl h \ rl e
jr nc,$+6
sub e \ jp $+6
sub e
jr nc,$+5
inc c
cpl
ld e,a

ld l,c
    ld a,l
add hl,hl \ rl e \ rl d
add hl,hl \ rl e \ rl d
sbc hl,de
rla
ret
Also, <750 t-states as promised (assuming I computed it correctly).

Yeah, I dunno about joining that team, but you are free to use any of these routines. They haven't yet been rigorously optimised (obviously, if I managed to make a routine twice as fast there is huge room for improvement). My hope was that these would actually be used for an OS, whether it is an OS I write or an OS others write. I also planned to use these routines if I ever finish Grammer 3, or Grammer 4 (an OS).

I might make a concept programming language using these 80-bit and 24-bit floats, or I might incorporate them into FileSyst somehow.