QEMU [3] is an emulator used to run programs for one machine on another.
N64 [4] is the Nintendo 64 games console.
SGI Indy [5] was a desktop SGI workstation from 1993.
[1] https://en.wikipedia.org/wiki/IRIX
[2] https://en.wikipedia.org/wiki/Silicon_Graphics
UNIX: Actually Unix. Not an acronym. https://en.m.wikipedia.org/wiki/Unix
Sorta.
"In 1970, the group coined the name Unics for Uniplexed Information and Computing Service (pronounced "eunuchs"), as a pun on Multics, which stood for Multiplexed Information and Computer Services."
More specifically one processor architecture to another. E.g. running on your desktop (usually an x86 based architecture) a Linux Operating System designed and compiled for a Raspberry Pi (ARM based architecture) and it's incompatible architecture. In this case they're running software designed for the same processor that the Nintendo 64 was targeting which so happens to also have ran a Unix OS known as IRIX.
edit: oh, says it right there in the Wiki
Nintendo is a little mysterious when it comes to what their actual tooling was, but I remember Donkey Kong Country being the first time I read they were using SGIs (or at least the studio "Rare" was).
It's somewhat surprising they used the Indy for developing Mario 64 – I always got the sense that it was somewhat lightweight in performance compared to the Indigo, but a very cool machine either way.
The Nintendo 64 had a MIPS R4300 chip, the SGI Indigio also used the MIPS Rchip, the early one had R4000/R4400 chip, the later ones R8000+ chips. I can only speculate that by using SGI, you could run some of your non specific N64 code locally and debug faster.
Original PSX had a R3000 chip, but Sony opted for BSD, their devkit ran on FreeBSD PCs and you built the code and ran on actual PSX device. Cheaper...
BSD would've been a strange choice as the Playstation 1 debuted on December 3rd, 1994. "FreeBSD 1" came out just 13 months earlier
The Playstation 2 "TOOL" machines ran Red Hat for some of them, which was a bit more mature by 2001
The Playstation 3 and 4 though both run Net and FreeBSD under the hood internally though
Also BSD != FreeBSD, BSD 4.3 Net/1 (the first BSD released under the BSD license instead of containing AT&T code) was released in 1989.
[1]https://www.retroreversing.com/official-playStation-devkit
By the time the Indy came out, the Indigo2 had replaced the Indigo, and I suspect a midrange Indy was a good match for a midrange Indigo1 (at much lower cost). Nintendo made an N64 dev board for the Indy, essentially an N64 on a GIO board, complete with an adapter card to connect controllers.
The joke always was that the Indy was the Indigo without the go :-)
But it was a decent enough machine to develop on, you didn’t need the 3D stuff if you spent all day in Emacs or compiling. Whereas an Indigo was really targeted at say CAD users.
The Indy had XZ graphics available, which I believe were the same as the top Elan option available on the Indigo (4 GEs)
"We get the inside story on the legendary Rare with an all-star panel - David Doak (GoldenEye), Chris Marlow & Shawn Pile (Conkers Bad Fur Day, David Wise (Donkey Kong Country series) and Kevin Bayliss (Battle Toads/Killer Instinct)"
What does this mean?
I think of QEMU as emulating hardware... What exactly is being emulated here?
Do you have a link to a comprehensive guide on doing this by chance? I was thinking tomorrow I’d just launch an arm instance in AWS and figure it out but I have a dual Xeon workstation at work (windows) that I might try as well.
You can skip the first part about creating the image, since presumably you already have one. So the process for me is something like:
apt-get install qemu qemu-user-static binfmt-support
cp /usr/bin/qemu-arm-static ~/rpi_mnt/usr/bin
systemd-nspawn -D ~/rpi_mnt bin/bash
Sometimes qemu shows an error saying some operation isn't supported, but this hasn't broken anything yet for me, even after I did a whole Raspbian Stretch -> Buster upgrade this way.
Now, if your ARM binary was compiled to look for libc at /lib/libc.so, but /lib/libc.so is the host's x86 libc, then that obviously won't work; and the easiest way to get the libraries all sorted out is to use a chroot with OS install of the target architecture. If you do go the chroot route, you need to make sure that `qemu-ARCHITECTURE` is statically linked, because it won't have access to the x86 libraries it needs to run after the chroot(2) call happens (which is why most normally-dynamically-linked distros have a "qemu-user-static" package in addition to their normal "qemu-user" package).
But with a multilib scheme like Debian's, where all libraries get installed to /lib/ARCHITECTURE-TRIPLET/ instead of /lib/, then it should be possible to install all of the appropriate target libraries on the host system without a chroot! You "should" just need to configure APT to let you install packages built for that architecture. (I haven't actually tried this; I'm not a Debian user, but I am envious of their multilib).
Notable because the sgi indigo had a MIPS R3000A CPU.
Not quite. It means that they got qemu to emulate IRIX's syscall layer on linux. So you can run, lets say, a MIPS IRIX binary on x86 linux without having to emulate the entire machine.
Wine impersonates OS calls, (including syscalls) but does not perform emulation on the binary itself. Wine can only run windows applications written for x86, but not windows applications written for itanium.
This appears to be running both hardware emulation on the supplied binary, (which is what VMware/KVM/virtualbox etc do) as well as wine-like OS impersonation.
I made up the word "impersonates" for what wine does just to avoid confusion. It's not a word that's used in the literature afaik, although perhaps it (or a word like it) should be.