Recently, Gravis made one hell of a dive into the horrible abuse of the BIOS to make a bootleg hypervisor, and then went even deeper to find truly cursed usage of forbidden processor features. User DecayWTF had a few things to add to this, and I wanted to add on further, but... well, I didn't want to hijack the thread. I've been putting this off for far too long, and now I'm going to finally get around to doing something I said I was going to do a few months ago.
Welcome to the first installment of my article series called "Education Yourself". This series aims to highlight the weird, failed, obscure, and interesting aspects of computing and technology history, usually in an entertaining tone with a short-ish length. I might go kind of fast, but I do hope that you get a kick out of this, and learn something new along the way. So sit back, relax, and prepare to be horrified when I tell you that your modern Intel or AMD x86-64 CPU... is not x86-64.
EDUCATION
YOURSELF
Am I perfect? No I'm just a wolf. I'm also not one that has looked at leaked internal docs or broken blood-oath NDAs either, so I wasn't 100% sure about some details. I'm going to use this to highlight some new information that has come to light, and add in one more thing that I forgot to add into the original piece, but looking back... where would I add it? Eh. Click the Read More to begin.
Correction 1: AMD's Legacy
Okay so I thought that the Am29000 was the core used for all the successor x86 CPUs AMD made. But apparently, it was considered a "dead end" after the K5. To solve this, AMD bought out another semiconductor company, called NexGen, back in 1995, and had them handle the microarchitecture (or internal core as I called it) for their CPUs. NexGen, when they were indepenent, were in fact making microcoded x86 implementations like I had described. When AMD bought up NexGen, they halted development of their own in-house K5 successor and instead made NexGen's in-development designs take up the mantle.So... I was kind of right, but instead of being based on a known architecture, it's actually another mystery RISC design.
Correction 2: What ME/PSP Run On
Running Management Engine/Platform Security Processor on a completely independent CPU core embedded within the CPU itself sounds absolutely wasteful and bonkers, yet a bunch of people have said that this is, in fact, the case? Intel's ME is apparently running on a tiny 32-bit Pentium-based core, and AMD is using... an ARM core?! [Considering how batshit insane Arm currently is](https://www.theregister.com/2023/03/25/arm_ipo_license/) this seems like a Very Bad Idea. Who will be responsible for footing the bill of using ARM cores inside AMD CPUs? If it's the people using the AMD CPUs, then *HOOOO* this is going to be ugly. OEMs are going to run from Zen... oh crap and both the current Xbox and Playstation systems use modern AMD CPUs! Microsoft and Sony will not like that one bit.Addenum: MIPS' Party Trick
The Nintendo 64 used a MIPS processor, a NEC derivative of the R4300i. It is microcoded, but you can *replace the microcode.* The code can go up to the CPU as it is waking up, pull out a knife and *lobotomize the CPU* to replace it with its own set of custom instructions, then let the CPU execute very non-standard code. That seems like something nobody in their right mind would actually do... but I don't think that's a category where Factor 5 falls into.One of my favorite N64 games of all time is Star Wars: Rogue Squadron. Think of it like Star Fox 64, except the maps are larger with more detail, and you're always in All Range Mode. It's really good! And I'd love to be able to play it again! My N64 is buried in my basement and I don't have a TV that can support it. So, why not emulation? N64 emulation has gotten pretty damn far. Except... yeah you know where this is going.
N64 emulation is generally done in the form of "High-Level Emulation", or HLE. That is, the instructions for the MIPS processor are directly mapped to instructions on the host CPU. This is less of an emulation and more of a translation layer, and is locked to the default instruction set of the processor being emulated. For the large majority of N64 games, this is perfectly fine! It's why you can play Super Mario 64 and Mario Party and Super Smash Bros. just fine with emulators. But make it run Rogue Squadron? This is where it all falls apart. The code to replace the microcode just won't work! And then the HLE tries to map out incorrect instructions and everything just errors and/or crashes. To get this game to work, you need to use "Low-Level Emulation", or LLE, to simulate the entire R4300i CPU. This requires significantly more processing power and resources to accomplish the same goal, and well... it will work, but I don't think single-digit frames per second would be considered playable.
