Ever wanted to see a Nintendo Entertainment System released in 1986 run the .NET Framework released for Windows platforms in 2000? If you're the same kind of techno-degenerate who enjoyed .NET being backported to Windows 95, you're most likely in the right place, though of course the NES isn't going to be nearly as capable as your average Windows 95 PC.
Before proceeding, let's take a moment to put the processing power of the mighty Nintendo Entertainment System in context — since it was powerful for its day, after all. The NES boasts an 8-bit CPU running at 1.78 MHz — that's right, MHz, not kHz!— and enjoys a generous 2 Kilobytes of RAM and of VRAM allocation.
It can also handle game cartridges with up to 512 Kilobytes of storage, which our needlessly determined .NET porter (Microsoft's Jon Peppers) noted would barely be enough for modern Android/iOS app icons. The most popular iOS/Android apps also tend to run the gamut from 55-206 MB, which is orders of magnitude higher than anything an NES could ever hope to comprehend.
Latest Videos FromTom's Hardware
So, why was this done? A wide assortment of reasons are provided in the original presentation. These include learning how to convert MSIL to 6502 assembly, for API design and .NET development experience, and most importantly a simple "Nerd Flex". Although, for a "Nerd Flex", this one seems fairly limited in its uses compared to the last .NET Framework-related nerd flex that actually fundamentally improves Windows 95. Right now, .NET on NES isn't even playing any games, it's mostly just running Hello World and other simple demos.
But it's still pretty cool, especially considering the fact it works at all. Several components of .NET were cut from this implementation to make it work on the NES' limited hardware, including a lot of compatibility-related code, the debugger, and other optional components of .NET. Or, "optional" if you happen to be running it on an NES, I guess.
In the cruel absurdity of the universe at large, never forget that your old hardware can always be put to use as long as it still functions. Usually, that means something like playing old games, but sometimes it means creating entirely new games and expansions to keep old hardware alive. Other times, it's about fixing or fundamentally replacing old hardware to keep the aesthetics alive without sacrificing too much functionality.
As the author? My personal favorite has still got to be porting N64 games to PC with ray-tracing and uncapped FPS, though that's keeping software alive rather than hardware.
