This project was based on a discovery from a piece I wrote back in 2017, a backstory on the NESticle era of emulation. I essentially dug into a rumor about SNESticle appearing in an EA boxing game for the GameCube, and once I did, there it was.
The real question is whether EA has a big ole target on it over this, depending on how the emulator works, or did legal coordinate with Nintendo over this for proper license
Possible that it doesn't matter, but it is interesting and we'll never know
The Super Punch Out!! unlockable game was a promoted feature on the box of the GameCube version of Fight Night Round 2 and Little Mac was actually a character in the game, so that much isn’t a surprise.
How the game was emulated, however, definitely was.
> Data mining revealed the strings "SNESticle" and "Copyright (c) 1997-2004 Icer Addis" (Addis being Sardu's real name) on the game disc. This raises a lot of questions, perhaps most importantly (and unanswerably): did he really have SNESticle ready to go back in 1997 and then chose to sit on it just to spite the people who were bugging him for it? Or is the 1997 date just a joke, to spite the very same people now? Or is the whole thing a joke? Who knows, ...
Author of this emulator really sounds like a man with an insane amount of skills and an even larger grudge assuming he actually did either of the two things just out of spite. Got to respect his dedication either way.
Totally different motivations and goals, but also, the JS stuff was hilarious too. And more importantly, like with left-pad, if your software delivery pipeline is that fragile for mission-critical systems, you got what you deserved. Better learn your lesson from downtime now than leak a bunch of user data because the developer of is-uppercase.js lost a thumb drive with their github keys and somebody pushed a backdoor in a package update.
He didn't make NESticle or Genecyst or Callus for anyone but himself. That much should've been obvious by the UI for each emulator. Obviously, he wanted to write a 65(C)816 and SPC700 emulator in 1997, so he did.
Considering how badly his privacy was violated during the late 90's, it's not even a little surprising that he never released it.
> Considering how badly his privacy was violated during the late 90's, it's not even a little surprising that he never released it.
It seems people never learn: just look at the effort to find who Satoshy or _why_ are. This is not respectful: they gave you something cool and asked to be left alone. Their work is theirs and they generously shared it with you. Why do they believe they are owed anything else? Why can't some people take "please stop" for a response? Why do they keep trying their best to alienate the very people who accomplished miracles way beyond their capabilities?
It seems self destructive in any way I take it, and driven only by spite/jealousy/beggar-chooser spirit.
> Satoshi likely became filthy rich off of his invention
Should I do like you and exclude from the sympathy due to every human being those who are filthy poor if I don't like the poors? Or will you invoke some special exemption clause making it totally ok, like it's ok to punch up but not down?
If I should not, maybe you should ask yourself if respect should exclude those who you dislike, because other people may dislike those you like... or even yourself.
Perhaps I phrased that poorly. It's not Satoshi's wealth that matters, but rather the source of his income—he became rich from his invention. I believe that should open him up to scrutiny, for the same reason that publishing investment advice should open you up to more scrutiny than publishing sports trivia.
(I don't want to imply that Satoshi did anything untoward, because I don't think he did. However, it's a valid thing to want to investigate.)
Still phrased pretty poorly in my opinion. You've sort of just reworded your original comment with some additional assertions that don't really make any sense. How is the individual(s) in question and their hard work that they've decided to unleash free of charge for anyone to use as they see fit even a little bit close to publishing investment advice? Your argument really comes off as being envious in some way or otherwise bitter.
The 90s emu scene was full of soap-opera-tier drama. Mr. Foo was mean to Barbazzz one time in IRC, so Barbazzz takes down the beta of his extremely promising Casio Loopy emulator and cancels any future emulation projects. In retaliation, Mr. Foo disbands his emu group, known throughout the web as a great emulation resource, with the stated reason being to avoid well-poisoning by lamers like Barbazzz. That sort of thing. Look up what happened to Damaged Cybernetics and VSMC.
The emu scene still has lots of drama, but it's different and I won't get into why on Hackernews.
EDIT: In fact Damaged Cybernetics, which was indeed the group to go to for emulation news and information back in the day, was disbanded because of the backlash against its leader, who had the friendly nick "MindRape". MindRape stole and released the source code to... NESticle, leading to Sardu's withdrawal from the scene and the lack of a SNESticle we can all enjoy.
If there's any program you'd like to see the source to, it's NESticle. I get it that we live in an era now where you can't even trust Norton AV with spare cycles, but in it's heyday we're talking about an emulator for running (I don't think it's a stretch to say) mostly pirated binaries. Which also happened to have dripping bloody menus and a severed hand for a cursor. It didn't exactly look harmless! Would have been nice to see under the hood.
NESticle, as I recall, had plain blue menus (but it did have the severed hand cursor).
It was Genecyst that had the bloody menus.
Back in the day, we didn't really worry about software like this being malicious just because of the author's gruesome sense of humor. It was all part of the fun. Back in the 90s, people were edgy like that. It's not like today where you're suspected of cryptofascism for not properly reciting the right nostrums. If it were malicious, someone would've found out, word would have spread around the scene, and the author would be branded the worst of lamers. People had reputations to uphold and good will to farm out of the community, even when running quasi-legal programs to play pirated ROMs.
This reminds me of any time you'd download a serialz pack, complete with the demoscene loadscreen and just wonder to yourself "am I installing a virus right now? but this midi chiptune shit is pretty great!"
> the author would be branded the worst of lamers. People had reputations to uphold and good will to farm out of the community, even when running quasi-legal programs to play pirated ROMs.
There's a certain irony in the fact this is exactly how it works today.
I guess the difference is back then you were in on "the right nostrums", some people likely weren't and felt just as alienated by that scene as you do by today's...
In fairness, a big part of the soap-opera tier drama from the 90s emu scene was centered around one very big thing: ROM begging. I mean, you go through all the trouble of writing an emulator, you release it at no cost, and for your trouble you wind up getting an avalanche of people begging for ROMs... yeah, I'd be a little annoyed too.
AFAIR he ran windows share on public IP with no firewall (default on win95), someone got his IP from IRC? hmm <furious googling> there it is https://patpend.net/articles/zd/article2.html
"Sardu was running Windows 95 at the time. He made the mistake of leaving drive sharing on (which should not have been on by default, but for some reason, it was on). MindRape was then able to mount Sardu's hard drive (since drive sharing was enabled) with Samba. Pretty clever, right? Regardless, he did this and not only was he able to retrieve the NESticle source code, he was able to look through all of his drives. His Zip drive. His hard drive. His CD-ROM drive. Whatever he wanted. Such an invasion of privacy is ridiculous, but this is what transpired."
I played nesticle/snesitle/genecyst on my earlier Windows PCs and absolutely loved the emulation. The UI wasn’t the greatest but IIRC they were DOS 4g based and ran well under Windows.
The author of this page doesn't seem aware that the nesticle author's PC was hacked way back then, and the source code released against his will which led him to never release SNESticle.
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.
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.
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.
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).
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.
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.
> 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.)
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.
I think it's more "old man yells at cloud" than you realize. Do you think people who manually input programs by moving wires around lamented bytecodes and assemblers? I would guess they did. The better C compilers get, the less there is to do in low-level code, and the less there is to innovate on that will be missed by no one knowing more than what's left. They can already compile themselves.
This lament draws a straight line back to concerns over books hurting memory and a culture of oral and visual teaching and storytelling. Books probably did have that effect, but the gain was worth it. There would have been no books to hold on to the progress of the ancients through the various rough patches Europe went through without books. "How much progress was lost because it wasn't written down?" and "how much progress was lost because the tools were inaccessible to the person with the right idea?" are the same question.
Assembly is fairly easy to learn (going by my few attempts) in the same way picking up the syntax for most languages is easy, but doing anything non-trivial is at least as involved as any other way of communicating with thinking sand.
Keep in mind that the industry has grown so much, that in absolute terms we might have more people who knew assembly than ever before, even if the relative proportion has gone down.
Btw, compiler writing has also improved a lot. Thanks to projects like LLVM, you don't need to know assembly to write a compiler for your new language.
Also: there's plenty of people with interest in obscure technologies and languages. Have a look at the demo scene where people still write new material for the Commodore 64. Or the trend of making new games for NES and the original Gameboy. There are plenty of people who work close to the bare metal, because it's fun.
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.
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.
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 went a little ways down the rabbit hole with some of the links in this article and ended up looking at the trailer for "The Knobbly Crook", a very peculiar point-and-click game by the art half of Bloodlust Software. Who, after drifting away from the programming half, apparently ended up at a Canadian game team called "Strategy First", then as a level designer and writer at Ubisoft.
It's free but Windows-only so I can't check it out. Looks pretty crazy.
If you're on Linux, Steam has a pretty solid compatibility layer baked in (Proton, which they use on their Steam Decks and such). Just right click the game in your library, hit Properties, and then 'Force Compatibility'.
NESticle has nearly as much nostalgia for me as plugging in the NES. There was this magical feeling at the time. I can play my favorite games on my computer? Don’t have to blow in the cartridge? Save states???
excellent SNES emulators exist and are open source, including bsnes which is probably as good as is possible, and is certainly as good as is needed. it's 100% compatible.
is "liberating" another emulator going to get anyone anything new?
That makes sense. I followed the emulator scene for a while and had never heard of this one until a recent article somewhere. Or maybe I just forgot about it?
Either way, bsnes meets all of my needs. I have no nostalgia towards an emulator that I have never used previously, and I can count SNESticle among the emulators that I have never used.
This is the second article on SNESticle to reach the front page within the last few weeks and neither talks about whether the emulator is actually any good, only that it’s legendary.
It was never released originally, so no-one really knows for sure. However the source code was only released ~5 days ago so I guess it's wait and see, or you could build it yourself to find out ;)
I have so many fond memories of running Genecyst on college machines when I should have been working. At the time it felt like a super power running software that emulated an entire games console on a computer that could barely run Windows 95. And those games ran well too. I don't recall seeing any slowdown on Sonic The Hedgehog.
It was actually Genecyst that lead me to Windows software development (before then I was mainly focused on older micro computers, DOS and a little bit of web development if I was bored). But I wanted a way to hide my gaming activities on college machines so wrote some Windows software to hide Genecyst from the task bare, "boss screens" and such like. This lead me onto Win32 APIs and a whole other rabbit hole of fun and nefarious projects that would have likely lead to a criminal record if it happened today. But it was a great learning experience and lead to the reputable career I have today.
86 comments
[ 2.8 ms ] story [ 155 ms ] threadI wrote something about this reverse-engineering effort, including an interview with the developer who created this page: https://www.vice.com/en/article/akvkyb/programmer-uses-nsa-t...
For those curious about how it runs, this video does a good job highlighting how it works in a variety of games: https://www.youtube.com/watch?v=2fXQbWm2iMg
Possible that it doesn't matter, but it is interesting and we'll never know
How the game was emulated, however, definitely was.
Author of this emulator really sounds like a man with an insane amount of skills and an even larger grudge assuming he actually did either of the two things just out of spite. Got to respect his dedication either way.
Considering how badly his privacy was violated during the late 90's, it's not even a little surprising that he never released it.
It seems people never learn: just look at the effort to find who Satoshy or _why_ are. This is not respectful: they gave you something cool and asked to be left alone. Their work is theirs and they generously shared it with you. Why do they believe they are owed anything else? Why can't some people take "please stop" for a response? Why do they keep trying their best to alienate the very people who accomplished miracles way beyond their capabilities?
It seems self destructive in any way I take it, and driven only by spite/jealousy/beggar-chooser spirit.
Should I do like you and exclude from the sympathy due to every human being those who are filthy poor if I don't like the poors? Or will you invoke some special exemption clause making it totally ok, like it's ok to punch up but not down?
If I should not, maybe you should ask yourself if respect should exclude those who you dislike, because other people may dislike those you like... or even yourself.
(I don't want to imply that Satoshi did anything untoward, because I don't think he did. However, it's a valid thing to want to investigate.)
What should his financial state have to do with his want to retain privacy?
The emu scene still has lots of drama, but it's different and I won't get into why on Hackernews.
EDIT: In fact Damaged Cybernetics, which was indeed the group to go to for emulation news and information back in the day, was disbanded because of the backlash against its leader, who had the friendly nick "MindRape". MindRape stole and released the source code to... NESticle, leading to Sardu's withdrawal from the scene and the lack of a SNESticle we can all enjoy.
It was Genecyst that had the bloody menus.
Back in the day, we didn't really worry about software like this being malicious just because of the author's gruesome sense of humor. It was all part of the fun. Back in the 90s, people were edgy like that. It's not like today where you're suspected of cryptofascism for not properly reciting the right nostrums. If it were malicious, someone would've found out, word would have spread around the scene, and the author would be branded the worst of lamers. People had reputations to uphold and good will to farm out of the community, even when running quasi-legal programs to play pirated ROMs.
There's a certain irony in the fact this is exactly how it works today.
I guess the difference is back then you were in on "the right nostrums", some people likely weren't and felt just as alienated by that scene as you do by today's...
There was a lot less incentive to be malicious. No crypto-mining on compromised devices, no ransomware, and limited Internet banking
Source: I made a lot of money between the ages of 12-15 running HijackThis and Spybot Search and Destroy on neighbors' machines.
Other source: circumvented my school's firewall with "anonymous proxies" on lists of what, in hindsight, were absolutely compromised machines.
https://omar-s.bandcamp.com/album/omar-s-the-best
The Android PS2 emulation drama is hilarious (and sad). For the most part a lot of the modern drama is around money, it seems?
"Sardu was running Windows 95 at the time. He made the mistake of leaving drive sharing on (which should not have been on by default, but for some reason, it was on). MindRape was then able to mount Sardu's hard drive (since drive sharing was enabled) with Samba. Pretty clever, right? Regardless, he did this and not only was he able to retrieve the NESticle source code, he was able to look through all of his drives. His Zip drive. His hard drive. His CD-ROM drive. Whatever he wanted. Such an invasion of privacy is ridiculous, but this is what transpired."
https://github.com/iaddis/SNESticle
I guess that's his response to the liberation project :)
Like, at what point did the industry graduate to, I dunno, C?
Example: https://github.com/mirror/x264/blob/master/common/x86/dct-64...
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.
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).
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.)
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.
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.
(I do understand the temptation of nostalgia.)
> 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.
Eg bottles are more convenient when hiking. (Though there's no reason why you couldn't just put tap water in a bottle.)
This lament draws a straight line back to concerns over books hurting memory and a culture of oral and visual teaching and storytelling. Books probably did have that effect, but the gain was worth it. There would have been no books to hold on to the progress of the ancients through the various rough patches Europe went through without books. "How much progress was lost because it wasn't written down?" and "how much progress was lost because the tools were inaccessible to the person with the right idea?" are the same question.
Assembly is fairly easy to learn (going by my few attempts) in the same way picking up the syntax for most languages is easy, but doing anything non-trivial is at least as involved as any other way of communicating with thinking sand.
Btw, compiler writing has also improved a lot. Thanks to projects like LLVM, you don't need to know assembly to write a compiler for your new language.
Also: there's plenty of people with interest in obscure technologies and languages. Have a look at the demo scene where people still write new material for the Commodore 64. Or the trend of making new games for NES and the original Gameboy. There are plenty of people who work close to the bare metal, because it's fun.
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.
It's free but Windows-only so I can't check it out. Looks pretty crazy.
https://store.steampowered.com/app/378300/The_Knobbly_Crook/
is "liberating" another emulator going to get anyone anything new?
For them, I imagine it's less about how good it is, and more about simply having access to it now.
Either way, bsnes meets all of my needs. I have no nostalgia towards an emulator that I have never used previously, and I can count SNESticle among the emulators that I have never used.
This is the second article on SNESticle to reach the front page within the last few weeks and neither talks about whether the emulator is actually any good, only that it’s legendary.
https://github.com/iaddis/SNESticle
It was actually Genecyst that lead me to Windows software development (before then I was mainly focused on older micro computers, DOS and a little bit of web development if I was bored). But I wanted a way to hide my gaming activities on college machines so wrote some Windows software to hide Genecyst from the task bare, "boss screens" and such like. This lead me onto Win32 APIs and a whole other rabbit hole of fun and nefarious projects that would have likely lead to a criminal record if it happened today. But it was a great learning experience and lead to the reputable career I have today.