Which is pretty common for old-school emulators. ZSNES was written in x86 assembly, and Kega-Fusion was mostly assembly except for the UX in C. Both of these were, for a long time, the most popular emulators for their systems.
Thankfully ZSNES hasn't been relevant for some time, though Kega-Fusion is still a big deal because the Sega emulation scene is a mess (I think BizHawk is the only other decent Genesis emulator with Sega CD and 32X support). Hopefully Ares will catch up one day and put everything else out to pasture.
well, it was authored for the PS2 and GameCube, I think. for those platforms I imagine you'd need to use assembly at least a little to get the desired performance.
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.
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).
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.
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.
> 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.
> 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.)
Back in the era of these consoles they were using pretty exotic architectures, like the PS2 emotion engine with a MIPS CPU and wacky parallel vector/GPU processing engine (along with a whole PS1 CPU bolted on to poll inputs and other tasks). You didn't really get good C library support and were extremely lucky to even have a good C compiler and library in the early days of their launch. It wasn't like GCC had a command line flag to flip and suddenly get an optimized PS2 compatible binary built.
Well, you had libre SDK's and the 300mhz MIPS CPU for the PS2 is more than capable to emulate the SNES almost well, kinda on par on a Pentium II/ 450 MHZ III.
I mean, they're still mostly using C. You can find inline assembly even today in e.g. video decoders like x264. Not a ton of course, but they do use it.
really? just 5 years or so earlier the sentiment among the majority of game developers that I spoke to was something like "today, real games are written in assembly, and toys are written in C, though that's changing."
for a long time, the only way to get performance out of code was to write the most-used bits in assembly. even today there are some things, just a few, which still need to be in assembly if you really want to squeeze out all the performance that you can. most people just make a tradeoff elsewhere to get the performance, rather than using assembly.
just 25 years ago the game industry was filled with people extremely knowledgeable in assembly. yet today it is viewed as a black art. sad.
> just 25 years ago the game industry was filled with people extremely knowledgeable in assembly. yet today it is viewed as a black art. sad.
Why is that sad? It looks like progress to me.
Economizing on inputs is how productivity improvements look like. Human capital is an input like any other.
Similar considerations apply to more boring enterprise software development too: most developers these days could probably not write a hashtable from scratch. And that's good! We have libraries for that. Thus the industry is much more accessible to more people.
>> just 25 years ago the game industry was filled with people extremely knowledgeable in assembly. yet today it is viewed as a black art. sad.
> 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.
Yeah, I remember DreamSNES on the Dreamcast ran like a dog, so not surprised that a lot of assembler is needed to make it work on platforms of that era.
The original bsnes back in the day (before higan and the modern bsnes) required quite a high end machine to run playably in accuracy mode so yeah, this all tracks.
The 90 MHZ CPU for the dreamcast is not that powerful. A Pentium MMX would barely run ZSNES with a frameskip value of 2, 8000 hz audio and the lowest supported res.
Common for the era. I still remember the ad looking for C and assembly programmers at the end of the credit roll on the original Wing Commander (1990).
I guess that's his response to the liberation project :)