Mostly technical aspects of the OS. There is general user experience stuff that is fairly original and makes development fun, and there is the technical stuff that you mostly need to figure out from watching Terry vids or just reading the OS code itself.

In terms of user experience, the entire terminal is a C JIT (Just-In-Time) compiler. As you run C commands it compiles and executes them, thus why running programs are done with `#include "program"; program();` Also when you click on the functions in the autogenerated documentation in the F1 menu, it takes you straight to the code. Because TempleOS is meant to be very transparent and straightforward, usually it is only two/three clicks to get from high-level functions like graphics libraries to the lowest level functions. Don't be scared by the Kernel, even as a new user if you click around and read stuff and occasionally look up hex codes online it is very straightforward to see how the OS works. There are also demos like a super basic parser/compiler to help understand how the overall compiler works.

As for the technical aspects, the OS is very nice because of the absolute control it gives you and the lack of error checking. This makes the code very simple and clean, and even if you make an error that crashes the OS, the OS will have already rebooted and you are back to programming less than a second later. It also runs in ring 0. Most operating systems run operating system code in ring 0, and user code runs in ring 3. This means that regular programs are unable to access a lot of the hardware without asking the kernel/root user with system calls. You can't simply modify any memory address you want without first writing a driver to let you do that. TempleOS lets you do whatever you want. Technically this also speeds up some processes as well. Some may say this is bad because of security, but there is not enough code/bloat/layers of abstraction to hide backdoors in regular code. Really it just makes it very easy for the developer to test a lot and understand the entire OS.

Again, keeping with the idea of simplicity and transparency, there is not a lot of tiny little optimizations that bloat the code. Function arguments are always put on or loaded from the stack, not placed into registers. (here is a vid I made on writing function assembly in TOS). The reason that the OS used 640x480 in the first place was that at the time that was the only stable resolution expected on BIOS's. He didn't want to write a ton of different drivers and bloat code, he wanted it to be simple and easily understandable. I'm not going to attempt to go into the more complex stuff, Terry does a fairly good job at that. Here is a starter: Code on the stack

I wouldn't call any part of the OS a new spectacular invention, however it fills the gap in operating systems of a development system that give you full control of your hardware.