The SNESticle Liberation Project

You could certainly still say that the 'game ran under the OS' in this case since the kernel and drivers were underneath it, but I think it's fair to consider that a different beast from more modern consoles that have a full OS available underneath that you can summon with the home button and does things in the background like maintain a persistent network connection, do background downloads, etc.

There is however the ARM coprocessor that handles things like Bluetooth, USB, crypto etc. (basically, most of the stuff the Gamecube doesn't have). This does run its own IOS[1] software loaded from flash that is isolated from the PowerPC side of things where the game is running.

[1] No, not that one. Or the other one.

Not really, maybe by a stretch. Games run under a heavily stripped down Windows 2000 kernel, which most people would not really consider an OS on its own. It's a... kernel.

The SDK that got compiled into the game contained a full tcp/ip stack as it was not included in the kernel, as well as directx, sound libraries etc. The kernel was really just barely what you needed to get things going. It was crammed into 256kb, including the entire bootup animation/sound. Everything else came from the game.

Right, that was my point — that there was always still hand-tuned non-portable code "in" each final game build, since such code was 1. part of the SDKs, and 2. the SDKs were themselves built using some sort of macro-based code-preprocessor framework (i.e. a custom compilation toolchain that did whatever the platform owner wanted it to do), rather than just being a regular linkable library of extern-C symbols that you could use with any compilation toolchain targeting the correct architecture.

And, further, the reason for this, was that the 8th console generation was the first time we ended up, unilaterally across all platforms, with OSes that acted to provide Hardware Abstraction Layers for games, with "driver" code living in the OS, opaque to game application software, and able to be upgraded independently of game application software. Until then, games were mostly expected to know how to do MMIO against the various device ports of the CPU/GPU/etc. themselves — and the SDK helped with that by compiling down directly into manipulations of those device ports. (In short, the "device drivers" were part of the SDK, rather than in the console firmware.)

We didn't get truly "just a C library, that just makes system calls to the OS kernel" SDKs until the 8th console gen. (It was a distinct shock to see when I first read through the Wii U SDK docs, after having been a Wii developer.)

This was also precisely when we started to see third-party vendor-neutral game authoring solutions (e.g. Unity) ship "export to console title" features — because doing so now just meant cross-compiling the game for a known ISA, and linking against a plain-old directory of SDK libraries.

And while yes, the Xbox was an interesting exception — "the Windows 2000 box" — it wasn't entirely immune from this. Much like Wii games shipped with their own customized/patched exokernel forks (the "IOS" firmware), Xbox games shipped with their own vendored [and potentially customized-by-Microsoft] versions of DirectX et al. And these weren't like the user-mode Windows DirectX library: they didn't go through the OS, but rather did MMIO directly, just like other platforms' SDKs were doing. (And this is why HLE emulation, which you'd intuitively expect would work great for the Xbox, actually sucks! You need to low-level emulate each game's variant of each DirectX library to get everything perfect.)

> I guess it depends on what you mean by "regular user-mode applications"

"User mode" has a specific meaning: that the CPU has virtual memory management, and privilege levels that mask out certain instructions; that there are privileged / ring-0 processes that run with full ability to execute instructions, and unprivileged / ring-3 processes that run without full ability to execute instructions, but which must instead use system calls to context-switch to an OS kernel that itself is privileged and will perform the privileged action on behalf of the unprivileged process.

As of the 8th gen, all the consoles have a CPU of this type, and do this with their apps. It's the first gen where you can really call the games "application software." (Which all the platform owners seem to realize — they actually use the words "application" or "software" in the OSes for these consoles in ways they previously didn't.)

> Why is that sad? It looks like progress to me.

It is progress, yes, and I wonder where compiler authors are going to come from in the future. If we forget how to write in assembly, we forget how to tell computers how to do it.

I think of it by way of analogy: I can buy bottles of water in the store, so why do I still want drinkable water from my tap? Bottled water is progress, and drinkable water from the tap is "the old way." The old ways are important. Especially when they are the foundations of our modern technical society like compilers are.

It is true that new people can learn assembly when it comes time for them to write a compiler, or contribute to one, and as the number of assembly authors falls, the fewer opinions we will have about things, and the more monolithic things will be. When lots of people are part of a community, there is great diversity of thought in that community. If it's just a few (hundred?) people who speak assembly, the diversity of thought, and thus innovation in compilers will be almost nil. It is literally better for everyone if there are more who can write assembly well.

Secondly, people are avoiding learning assembly because they are afraid of it, which makes some sense to me at first glance, and makes no sense to me after writing some assembly. There is literally nothing scary about assembly; it just SEEMS scary. It can be quite fun to see just how little it takes to do things, and then observing just how unbelievably fast those programs are when run.

Part of the sadness I mention above is just "old man yells at cloud," but some of it is, I believe, bad for us in the long term if assembly does truly become a black art.