Until having this spark o' inspiration, I thought running TIOS programs under KnightOS would be impossible.  This would be really quite cool.  I think applications would have the best compatibility for lack of SMC.  DCS would probably tie into the KOS GUI system quite well, and there is heavy kernel support for most of MirageOS's functions.
We should work together to try and get good compatibility going between OSes.  We could probably use a similar code base.

What do you mean by data actions?

It would be quite an inconvenience on the programmer, I'm afraid.  KnighOS is designed in such a way that it can be convenient to the developer and could still probably manage to handle an architecture with specified data sections for compatibility layers.  Also, it makes sounds like an easy road to precompiled programs for location independence, and that stops SMC from being possible with calls, jumps, and relative loads.

Life's been getting in the way
I think I'll be able to start progressing again soon, I hope

sorry to hear, I hope you have time before summer time. X.x

Holy fuck, it's been three years (and one week). To be brief, it's on permanent hold. Sorry (Xeda reminds me it's in my signature, so I've taken it out)
I'm definitely still interested, at least theoretically, in making a TI-83+ series OS, with goals similar to the ones I've named for this project.
What happened, mainly, was that I was never sure how to achieve those goals while maintaining efficiency. (To save you from looking it up, my main goals were to have unlimited extensibility and abstraction. I don't know how much programming you've done, but unlimited extensibility, as I envision it, requires theoretical support for arbitrary-precision numbers (or at least 4-byte ones), which are not efficient. And unlimited abstraction requires that everything be indirected; I, again, don't know if you've done any assembly programming, but bcalls are horrendously slow in comparison to doing whatever they do directly, and I'm basically proposing making every external call a bcall.)
Of course, all this slowness is theoretical--the system never got to a state where I could see it for myself--but it was enough to prevent me from writing code. In retrospect, I do think I worried a bit too much, and there likely would have been optimizations available to help some (KnightOS's use of SMC to make relocation efficient is one example). After all, the whole thing is a hobby project, and it's not like blazing fast performance was ever an achievable goal . (To really give up on performance, maybe I should just make the OS a LISP interpreter )
Unfortunately, I'm now busy with other things. I've just talked myself back into doing this, which is unfortunate because I'm not sure I have the time. I think I will try this again, but it will be quite slowly. (Admittedly, anybody who's been following this has been doing so for years, so I think they can be patient ). With luck, there'll be an update from me here within a month.
(And as a plus, if I design it correctly, it should be easy to optimize, at least in parts, due to the very separated nature of it. So I'm feeling optimistic again)

calc84dude is back! Woot! Rejoice!
Excited to see the results

Is it possible to install a custom OS on a Game Boy/Game Boy Color anyway?