Sounds very much like a cross between DexOS and my as-yet unimplemented plans which I've written about rather more than necessary on this very forum!
DexOS was a 32-bit single-tasking OS; it pretty-much predated 64-bit systems. It had a command line and a games-console-like program launcher because it was envisioned as a console with PC hardware. (There was a window system in a later version. I don't know why.) It didn't have a split screen.
My plans involve just such a split screen, but I'm not really planning for single-tasking.
PeterX wrote:
I think Plan9 (and its many derivates) have a similar divided screen like you mention.
That's the Sam text editor. It is one of the editors included with Plan 9 (and one of the few editors ported to it altogether.) It's just the default configuration of Sam's windows, but it is a fairly good one. Plan 9 itself has a window system which would look fairly normal if it had title bars.
I was inspired by a bunch of things:
- colorForth where you can type commands with the last program's display routine still running
- Sam
- the split screen modes of my Ataris in the 80s, where you could type BASIC commands in a 4-line window below the graphics display
- a color picture on a magazine cover when I was a very impressionable kid, which had 2 80s monitors with commands on one one and graphics on the other
Anyway, I
obviously think the UI is really cool!
Single-tasking on the other hand... I don't know, there's a ton of things that could be said for or against. Turning the computer off is an issue primarily due to disk caching, which you likely do want. If you used a disk cache in MS-DOS, you couldn't just turn it off. (And drives have built-in caching since the 90s.) On the other hand, Plan 9's diskless 'terminals' were multitasking systems which could just be switched off.
As for responsiveness, while my single-tasking Palm m515 is possibly the most responsive device I've ever owned, Linux was not noticeably far behind
before they implemented preemptible kernel, fast timer ticks, and real-time features. In fact, all of these seemed to reduce the responsivity of my Linux systems, so I tend to distrust common wisdom here. A lot of what I do on DOS is starting programs (in an edit-compile-debug cycle), where DOS (MS- or Free) is far less responsive than Linux! It's better with a software disk cache. Bear in mind that a disk cache may need to do things in the background, especially if it caches writes. This isn't exactly meeting the goal of single-tasking. Then again, you could dedicate a core to the disk and maybe other IO.
Game performance... eh... I assume you mean 2D games. Load up an OpenTTD game with a lot of trains moving at once. I'm looking at one with 16 trains - 144 individual graphics - all as smooth as silk on a rather poorly-maintained Win10 machine. It's a multi-threaded game; can't even be build for DOS any more.
There *are* some tricks which can only be done on single-tasking systems, I think, but they depend on knowing precisely what hardware end-users have. This was once possible for PCs, but not for a long, long time. There's a document floating around the net and a website too which purport to be assembly-language references but are actually *timing* references for the 386 and 486 specifically. That's about the last time these tricks could be used, I think. Even then, there was a fairly wide range of bus and CPU clock speeds. Oh by the way, PCI will not help if you want very tight responsiveness, but really that comment applies to 33MHz PCI buses...
Overall, I think responsivity problems these days are caused by Linux (Android) trying to be clever and I guess app programmers not knowing they must use real-time facilities for accurate timing.
Edit: I once thought a single-tasking system with its hooks into interrupt handlers for driver extensions and other TSRs might well be more complicated than a well-designed multitasking system, but I don't remember my full reasoning now.