[derefr]

AFAIK, that transition wasn't complete until the current-minus-one gen (PS4/XBO/Wii U).

This was also roughly the point when consoles switched from "rebooting into" games (i.e. console SDKs being library exokernels that games pulled in; making each game, essentially, a unikernel — previously running on bare metal, later running under a hypervisor whose dom0 runs on a separate core) into finally having enough processing headroom that games could just now be regular user-mode applications running as processes under a pre-emptive OS scheduler.

[klodolph]

There are various Nintendo 64 codebases you can find, such as the Turok 64 source code (which was taken from a workstation sold on eBay, of all places). Generally speaking, they're written in C. I haven't encountered hand-written assembly outside the SDK. I know of a couple games that do use custom RSP microcode but those games are the exception.

The original Xbox shipped with an OS, and games ran under that OS. The OS gave itself a fixed time slice every frame. My understanding is that Microsoft was a bit quicker to move to a "normal" type of OS on their consoles, and the other vendors were a bit slower, but I think PS3 / Wii software ran under the console's OS as well, rather than the Unikernel style from the previous generation. The Xbox system software was forked from Windows 2000 (and heavily modified).

I guess it depends on what you mean by "regular user-mode applications". The PS3 runs what is believed to be a fork of FreeBSD. The Wii had system software, and new games shipped with a copy of the latest software bundled (so you would still get updates without a network connection).

[fredoralive]

AFAIK the Wii is still mostly in the "no OS" era, the game replaces the system menu in memory and runs in kernel mode. With Wii games official games use a standard set of libraries to do things like show the exit menu / battery level when you press home, but that's part of the game disc / binary, not from an external OS.

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.

[kevingadd]

Yes and no, for example Morrowind on the Xbox used a trick where it would silently reboot your console at loading screens to free up memory, and the console would boot directly into the game. https://kotaku.com/morrowind-completely-rebooted-your-xbox-d...

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.

[iforgotpassword]

> The original Xbox shipped with an OS, and games ran under that OS.

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.

[derefr]

> I haven't encountered hand-written assembly outside the SDK.

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.)