Hacker News Reader

Comment by dtech | Hacker News Reader

Also historically emulation only gets into a state usable for pirates after the end of the console's lifetime, or at the least near the tail end.

So right at the time emulators are good enough to enable piracy the impact is significantly less because you can't buy the original console and games anymore.

View on HN

> Also historically emulation only gets into a state usable for pirates after the end of the console's lifetime, or at the least near the tail end.

The Nintendo 64 was an exception since Ultra64 was released quite early and worked impressively well on PCs of that time (as long as you had a 3Dfx card).

I suspect you mean UltraHLE (Ultra 64 was the original name of the Nintendo 64) - https://en.wikipedia.org/wiki/UltraHLE

Another oddity is the GBA - an emulator for the machine existed before it was even released (GBAemu - I believe it was capable of at least running Nintendo's tech demos), and BoycottAdvance was, IIRC, at least somewhat viable around the time of the US launch of the console.

Nintendo DS and 3DS emulation both were attained pretty early in the lifetime of the consoles.

ARM-based machines are kinda a gimme though. The ARM is remarkably well documented, very straightforward to decode (both THUMB and ARM modes) and every ISA level is a superset of the previous.

You could write the entire opcode table for an ARMv7 chip and run ARMv3, ARMv4, etc code on it. Assuming there aren't any illegal instructions and that you've got the timing right, it should run just fine. So, essentially, you've got 1/3 the hard part done.

The GPU for the GBA was basically a chimera of the GB engine and the SNES's. Even had similar modes built into the BIOS. The Switch has a Maxwell based GPU. One very similar to that in the Tegra X1, which is very well documented (If you're willing to dig through their massive Technical Reference Manual (https://developer.nvidia.com/embedded/downloads) and the nouveau source.

That just leaves audio, the bus, game formats, etc to be "discovered" or reverse engineered.

IIRC the official GBA SDK was leaked online pretty early, and that was really useful to the emulator developers. I've tried searching to verify it's as I remember, but looks like the dev forums are long vanished. (Used to follow the scene pretty closely and still have my flash cartridge for loading homebrew stuff somewhere around, even if I didn't actually do anything with it.)

The dev forums are dead-ish†, but the docs are still around; I was just trying to pick it up the other day and I found everything I needed (including modern things like a Rust libgba: https://github.com/tbelaire/rusty-TONC).

I decided against pursuing GBA homebrew in particular, though, because Nintendo DS homebrew is slightly more fun while not being particularly higher-level than the GBA. You've still got sprites and backgrounds and scale/rot/shear effects; but now you've got two GPUs (where either GPU can address either screen), and a 3D layer sandwiched in amongst the background layers and sprite layers.

† Though, I mean, that's a matter of interpretation; all the modern 3DS and Wii U homebrew is still released/discussed/developed on the GBATemp forums, which—obviously—had its roots in the GBA homebrew scene.)

Almost 20 years later, I'm still following and intrigued by the homebrew scene and I take my hat off in particular to emulator developers... but I get to do embedded/microcontroller development in my day job, and that's enough difficulty for me. ;)

I'm myself wondering how much use Nouveau will be here. I imagine the approach that Yuzu will take is actually to HLE the entire operating system and implement things on the service level. During the Switch hacking talk at 34c3, they mentioned that there was a service containing the GPU driver. So basically, the idea would be to reverse engineer how the API works and try to implement the GPU on top of it.

At least, this seems like a sane approach to me. It benefits from less of the existing reverse engineering work on NVidia chipsets, BUT it's higher level, which probably means it will be easier to understand and yield better performance in practice, especially since it is going to have to be implemented on top of higher level GPU APIs anyways.

Of course, emulating a portable gaming system on the PC is only half as damaging, since it is not portable.

I'm enjoying some of the Switch games, and might want to relive the experience one day, but for now an emulator cannot easily duplicate the portability of the Switch. I would still be happy to know there's a good emulator out there though.

The dev's of GBAemu had access to a full devkit and documentation from nintendo, which is pretty rare for emulator developers these days. They usually have to wait for them to trickle out on the secondary market.

At the time, you could also use a wrapper for the 3Dfx card that would work with directx, but the frame rate was much lower (probably around 7 fps with the ATI card I was using at the time).

Also Bleem! and Virtual Game Station for the PSX, right?

https://en.wikipedia.org/wiki/Bleem! https://en.wikipedia.org/wiki/Connectix_Virtual_Game_Station

The PSX was one of the first consoles where emulation didn't typically imply piracy. Because the PSX used the same CD-ROMs as computers, you could stick your game CD in your computer and play it in an emulator.

In college, I had a lot of fun bringing my laptop to class with my legal copy of FF Tactics in the drive so I could play it during boring lectures. It was the perfect game for that, since it was turn-based, so if I ever needed to stop playing and pay attention, I could.

Yup. The PS1 also had a major advantage in the size of its games. During that day and age, reliably downloading a 700 MB file was a luxury few could afford, and dial-up connections were still especially popular. These days you can just pop on over to your friendly torrent hosting site and pull down any PS1 ISO within minutes, but the technology back then was far less mature, and potential nasty-grams from AOL for downloading torrents put many people off the idea.

I fondly remember Bleem, and played my real PS1 disks through ePSXe for years, because it turned my laptop into a portable Playstation. That was a neat trick. I still have my original PS1 and it's in good condition, but I'm glad I don't have to actually rely on the aging hardware to continue to enjoy my collection of games.

It "worked" but as someone with a 3Dfx at the time I'm not sure I would call it performant. I'm not sure N64 emulators were close to performant until I had a Geforce 3 Ti or so...

Also the PS1, with Bleem.

That generation of consoles seems to have been the only one where current consoles could be emulated on a low-spec PC with good compatibility. I'm not sure why. Perhaps that PC technology was still skyrocketing in the late '90s, outstripping current consoles so rapidly that emulators didn't need to be efficient, and the console devs hadn't yet made any major attempt at DRM.

Funnily enough the PS1 and N64 are probably two of the worst mainstream consoles to emulate now. Progress on them seems to have been completely outstripped by most other consoles in the past decade.

Conversedly, there's higan[1] (formerly bsnes), a multi-system emulator focused on accuracy, even if it's at the expense of speed. A very beefy current CPU is necessary to emulate the sfc/snes.

[1] https://byuu.org/emulation/higan/

Since the Switch is similar to the 3DS and it uses a well documented chip (Nvidia Tegra) development should be faster.

Recent consoles are well abstracted from the hardware. The only case where this is usually not true is the GPU, and it's rare to have something completely custom there nowadays (the 3DS and its weird PICA chip is very much the exception). Most of the difficulty is in properly emulating the operating system, and this is not helped by having SoC datasheets.

Plus timing issues, bugs & errata, etc.

Meh. Timing issues become almost irrelevant in a world where consoles have dynamic clock scaling, deep sleep modes, etc. Games are usually not written around specific timings anymore.

Bugs and errata can be a concern (I think I remember some issues regarding PowerPC atomic instructions misbehaving on the Wii U for example) but I would expect them to be fairly minor compared to the whole work of REing a custom microkernel and its associated services.

> Most of the difficulty is in properly emulating the operating system, and this is not helped by having SoC datasheets.

That’s assuming that you reimplement/HLE parts of the operating system rather than running the whole system in the emulator, in which case you wouldn’t need to care much about how the OS works. I suppose you think HLE is nevertheless easier overall?

Hopefully it will be comparatively easy. But (presumed) similarity is not a guarantee - see the XBox emulation: http://emulation.gametechwiki.com/index.php/Xbox_emulators#E...

yuzu is a fork of the Citra 3DS [1] emulator, maintained by the same people [2].

[1] https://citra-emu.org/ [2] https://yuzu-emu.org/

Reply on news.ycombinator.com