Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: willrandship on April 11, 2015, 07:58:56 am
-
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.
-
I'd like to see faster graphing, some of the things you mentioned will already do that as a side effect but it could probably benefit from some direct attention.
-
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 TI-BASIC interpreter (I bet this is loaded with goodies)
That would be awesome!
-
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?
-
This sounds like a really diffucult project, but if it works, it would be awesome.
A suggestion if you have extra time at the end of this project would be a better mathPrint. I know the OS you're trying to optimize doesn't have it, so it might be hard to do, but I've seen calculators that are much simpler than the 84+ that had something similar to MathPrint that was far better and also faster than what the 84+ MP OSes have.
And better floating points would be cool too (I heard that if you use real binary floats, you can get both better performance and better accuraccy), but that would probably require a rewrite of almost the entire core of the OS (and also of huge parts of the BASIC interpreter).
BTW: are you mainly trying to increase performance, or could it be possible to also free up an extra page or two?
-
Wait, wouldn't all the bcall adresses change? Or do they have a fixed jumptable?
-
@harold faster graphing is a possibility, especially if I optimize the line drawing and screen updating functions.
@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.
@ben_g Mathprint functionality isn't impossible (Kerm demonstrated it actually works on the 83+ BE as is) but if I use it I'll have to extensively modify the code. Also, I definitely plan on improving the floats. Changing from BCD to IEEE or similar would be difficult, since so many routines use it, but it would make several things far faster.
Also, another important point: I'll be avoiding anything that causes incompatibility problems in general. BCALLs won't be changing positions in the table, although unused ones may be moved and new ones added, etc. All LCD drivers should work, no matter how buggy and slow. TI-BASIC programs should work without modification. Timings for various things will change, but programs that don't rely on extremely precise timing should continue to work.
-
[...]
@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 :)
-
How is this going? Any news?