I've had this project sitting in a folder for over a year now, and I decided to pick it back up. I'm posting now because I'm actually making progress that I would consider release-worthy, rather than just a toy.

Everyone knows TI-OS is horribly bloated and slow, but we've built so much software into the existing system that no one's too anxious to leave. So, why not fix the problems and keep the OS as it is?

That's what I'm doing. Reprogramming bits and pieces of TI-OS to be faster, better, smarter, stronger, etc.

All the work is being done based on OS 2.41 for 84+SE at the moment. (Although, currently it's all taking place in page 00, so that's pretty much moot) Some of the optimizations will definitely be ported to the other models, but others (like improved USB) obviously wouldn't apply. Ideally, though, the modifications would converge to a single OS version that works on ALL the models in the 83+/84+SE range. (No, I'm not planning to support the CSE or CE. At least, not for now.)

If I release anything, to avoid copyright concerns, it will be patches against the ROMs I specify. It's a historically non-grey method of distributing hacked and modded software, so I hope I can avoid any nasty legal letters with this.

So, without further ado, here's what I've done so far: (I will edit this list with updates)

* Optimized LCD_Delay routine in Page00. It saves a minimum of 260 cycles per screen command on all models, for any software that uses the built in routines. (Not Axe, or most Asm). This results in roughly a 10% improvement in display-heavy routines in TI-BASIC, for example.

Here's what else I want to look into, but haven't done yet:

* The TI-BASIC interpreter (I bet this is loaded with goodies)
* Floating point optimizations
* Various frequently used system bcalls
* Improved Graphing (mostly through optimized fp and draw commands, but also ideally by not updating the screen until it's drawn fully)

Let me know of any suggestions, ideas, discouragements, etc. you may have.

A lot of Xeda's math stuff could probably be useful. I don't really use bcalls for stuff other than messing with memory, so i can't think of any other ideas. I'm not sure if this is essentially what you did, but GrBufCpy could use a speed bump too.

EDIT: Just realized "speed bump" might be misinterpreted, i meant a speed "boost"

A lot of Xeda's math stuff could probably be useful. I don't really use bcalls for stuff other than messing with memory, so i can't think of any other ideas. I'm not sure if this is essentially what you did, but GrBufCpy could use a speed bump too.

EDIT: Just realized "speed bump" might be misinterpreted, i meant a speed "boost"

The thing with the TIOS routines is that they use BCD while xedas routines use base 2, and thus rounding differences would appear.

Also, this is a nice idea! But, isn't the TIOS somehow copyrighted?

Wait, wouldn't all the bcall adresses change? Or do they have a fixed jumptable?

[...]
@Sorunome The patching should hopefully evade the copyright concerns as far as sending changes. Also, I'm intentionally padding modified areas to preserve their alignment in the system, at least until I can get a full build with dynamic bcall labeling built.
[...]

Oh, yes, patches should work, copyright-wise.

Also good to hear that everything should work without having to modify it