Difference between revisions of "Nintendo 64 emulators"
m (rementioned 1964 gepd)
(Updated information on texture filtering issues)
|(2 intermediate revisions by the same user not shown)|
|Line 547:||Line 547:|
The Nintendo 64 was the first consumer device to be able to filter textures when rendering 3D objects. However, unlike every console and PC graphics card made after the N64, its implementation of bilinear was primitive in that, in order to reduce strain on the system, it only used three samples as opposed to four, resulting in slightly jagged textures. Instead of faithfully applying this "imperfect" version of bilinear filtering, HLE plugins instead
The Nintendo 64 was the first consumer device to be able to filter textures when rendering 3D objects. However, unlike every console and PC graphics card made after the N64, its implementation of bilinear was primitive in that, in order to reduce strain on the system, it only used three samples as opposed to four, resulting in slightly jaggedtextures. Instead of faithfully applying this "imperfect" version of bilinear filtering, HLE plugins instead conventional filtering, interpolating straight from the source texture up to the output resolution the same way a PC game would. While that method is technically superior, it can result in textures that look even blurrier than on real hardware.
Another issue lies with the appliance of texture filtering per quad on static images, text, and sprites. Because each quad is filtered separately, this can cause some visual inconsistencies. Text and UI elements often look as though their edges cut off abruptly, and static images, such as pre-rendered backgrounds or menu screens, may look as though they are separated into squares. Some plugins allow the user to turn off texture filtering to remedy this, but, unfortunately, this also applies to textures in the game world, exposing their oftentimes low resolutions.
Another issue lies with the appliance of texture filtering per quad on static images, text, and sprites. Because each quad is filtered separately, this can cause some visual inconsistencies. Text and UI elements often look as though their edges cut off abruptly, and static images, such as pre-rendered backgrounds or menu screens, may look as though they are separated into squares . Some plugins allow the user to turn off texture filtering to remedy this, but, unfortunately, this also applies to textures in the game world, exposing their oftentimes low resolutions.
taken some steps which help remedy these problems. N64-style three-point texture filtering, which results in a more faithful look. It is also capable of rendering at 320x240, which sidesteps the issues with filtered text, UI elements, and menu screens, while still retaining texture filtering. Pixel-accurate plugins do not have these problems at all.
<gallery widths="300" mode="packed">
<gallery widths="300" mode="packed">
Project64_2013-06-26_17-44-58-31.png|Conker's Bad Fur Day copyright screen, displaying issues with filtered text.
Project64_2013-06-26_17-44-58-31.png|Conker's Bad Fur Day copyright screen, displaying issues with filtered text.
Mupen64plus_2013-08-18_20-35-50-08.png|Ocarina of Time's menu subscreen, displaying issues with filtering.</gallery>
Mupen64plus_2013-08-18_20-35-50-08.png|Ocarina of Time's menu subscreen, displaying issues with filtering.</gallery>
Revision as of 20:14, 21 June 2022
|Type||Home video game console|
The Nintendo 64 is a 64-bit fifth-generation console released by Nintendo on September 29, 1996 for $199.99.
Nintendo was the second company approached by Silicon Graphics Inc. (SGI), who wanted to roll out their previously enterprise-only technology in the consumer space. They originally pitched their idea to Sega, but it's assumed that Nintendo's offer was more appealing. With the NEC VR4300 CPU clocked at 93.75 MHz, 4MB of RAM,[N 1] and an SGI RCP GPU, Nintendo had finalized much of the hardware at least a year before launch, preventing video games from needing drastic rewrites as a result of architectural changes. The development workstations were often Unix-based, something that would later help reverse engineers in some projects.
- 1 Emulators
- 2 Emulation issues
- 3 Peripherals
- 4 Hardware variants
- 5 Virtual Console games in Dolphin
- 6 Notes
- 7 References
|Name||Platform(s)||Latest version||Plugins||Controller Pak||Rumble Pak||Transfer Pak||64DD||Depth
|PC / x86|
|m64p (Final GLideN64)||Final GLideN64||✓||✓||✓||✓||✓||✓||✗||✓||✓||✓||✗||✓|
1.2 r146 (Unofficial SVN)
|Mobile / ARM|
|Mupen64Plus FZ||3.0.322 (beta)||✓||✓||✓||✓||✓||✗||~¹||✓||✗||✓||✓||✓|
|Surreal64 CE||Beta 6.0||?||✓||✓||✗||✗||?||?||?||✗||✓||✗||~|
- * Available exclusively as a libretro core
- ¹ Only supports texture packs, and not filtering or upscaling
- ² Requires replacing the input plugin to one with netplay support
- ³ If not using Netplay, use RMG
- ⁴ Highly recommended to use 1964 GEPD for Goldeneye 007 or Perfect Dark
Although many Nintendo 64 emulators have been made and many games can be run between them, until recently complete compatibility and/or accuracy left a bit to be desired. For half a decade, Mupen64Plus and Project64 have vied for the most playable emulator, and which was more compatible often depended on when and in what configuration each emulator has been tested. As of August 2017, both emulators have roughly equal compatibility and accuracy when running with the same recommended N64 plugins setup, though both default to Glide64, a now relatively lackluster plugin.
- A multi-platform emulator based on Hacktarux's Mupen64. It's about as accurate as Project64, when both emulators are run with GLideN64. However, Mupen64Plus lacks a native GUI, instead being launched either from the command line or by dragging and dropping ROMs onto the executable and editing the config with a text editor. BizHawk and OpenEmu use forks of Mupen64Plus and its plugins for their N64 emulation, but they seem to be shallow. As of 2022 Project64-style overclocking for faster frame rates has been added under the option 'CountPerOpDenomPot'.
- Mupen64Plus-Next and ParaLLEl-N64
- Both are heavily-modified forks developed as libretro cores. They introduce many features and optimizations not present in mainline alongside RetroArch's general features, including 3-point texture filtering for Glide64, superior A/V sync and latency, and even an initially exclusive LLE Vulkan renderer based on Angrylion's pixel-perfect RDP plugin now known as ParaLLEl-RDP, making it a better alternative to the standalone version in some cases. ParaLLEl-RDP has a special "Super VI Mode" option which, if used, can make the visuals of N64 games look less blurry with fairly mitigated jaggies even at their native resolutions. Although, it may need a powerful GPU. It also offers native high-resolution rendering, only available in integer scales of the original N64 resolution.
- As for the difference between the two cores, ParaLLEl-N64 is actually the older of the two, as it is based off of the old Mupen64Plus-libretro core, having been renamed to ParaLLEl-N64 upon its initial integration of the ParaLLEl-RDP and RSP plugins. In addition to the ParaLLEl plugins, it also retains the older HLE plugins (glN64, Rice, and Glide64), as well as Angrylion Plus. Meanwhile, Mupen64Plus-Next is a new rebase off of bleeding-edge mainline, and as such is the more compatible of the two. It does away with the legacy plugins and replaces them with GLideN64 as a better HLE solution (though of course, the ParaLLEl plugins and Angrylion Plus stay), it considerably cleans up the Core Options menu for easier configuration, and it adds Transfer Pack support. Add to this the fact that going forward, all further improvements and new features will be to the Mupen64Plus-Next core, and Mupen64Plus-Next is now the more recommended of the two, thus ParaLLEl-N64 should now only be considered for performance reasons or perhaps for older ROM hacks that don't play well with the newer, more accurate plugins.
- Probably the easiest "out of the box" solution for Nintendo 64 emulation. In keeping with its theme of simplicity for the end user, it uses ParaLLEl-RDP and ParaLLEl-RSP for its video and RSP plugins, as well as its own custom GUI and input plugin, and unlike other emulators, it does not allow you to use anything else. If GLideN64 is desired instead, there is an older build that retains it - unfortunately lacking the texture enhancement suite required for use of texture packs and upscaling.
- Wii64 and Not64
- Both are based on Mupen64, with Not64 being a fork of Wii64. Not64 claims to be better optimized as well as having higher compatibility and more frequent updates. N64 emulation on Wii is not very good, and it is recommended to stick with the Virtual Console releases whenever possible.
- An open-source emulator for Windows, as well as one of the oldest. Its official release builds are more up-to-date than Mupen64Plus', and the current version, 3.0.1, is roughly as accurate as the development versions of Mupen64Plus when both are played with recommended plugins. It has a more user-friendly interface than the Mupen64Plus attempts and supports more features such as Transfer Pak emulation. It does come with GLideN64 out-of-the-box, but the default audio plugin isn't even the best in the box. For the most part, it works well in Wine, but, if you're on a different platform, use Mupen64Plus instead.
- An open-source multi-system emulator and successor to Near's higan project, with a mostly original N64 core. Unlike other N64 emulators, it aims for high accuracy and does not employ HLE RSP or RDP emulation of any kind, not does it use game-specific hacks. It uses Themaister's ParaLLEl-RDP Vulkan renderer (with Angrylion's MAME renderer as a software-based fallback) for pixel-perfect LLE graphics. While it is currently less compatible than Mupen64Plus or Project64, it is quickly catching up to them (only a handful of games are currently listed as partially or not working), and it currently passes several stringent accuracy tests the other emulators do not. However, it remains to be seen how accurate its developers are willing to make it without compromising speed and playability on current machines.
- Aims for cycle accuracy while at the same time aiming to eventually be usable on modern PC hardware. It lacks many features and has spotty compatibility, but it can already emulate some well-known edge cases such as picture recognition in Pokemon Snap. Unfortunately, its creator appears to have abandoned the project citing lack of satisfaction with his stated goal of fast cycle-accurate emulation, and development has all but stopped.
- Along with its various versions and forks, it was once a decent, speedy open-source alternative to Project64 and Mupen64, though it usually lagged behind the two compatibility-wise. Nowadays it has completely fallen off the radar as development has halted, and there is no longer a central code repo to speak of. There is little reason to use it nowadays outside of historical purposes, very specific edge cases, or if your device is too slow to run Mupen64Plus or Project64.
- Is a Nintendo 64 emulator for PC which was ported to the PSP under the name of DaedalusX64. The PSP version later became the main version and got ported to platforms such as the Dreamcast, the PS2, the PS Vita, and the 3DS. On PSP, several games are able to reach full speed and most of them work with few emulation issues.
- Is macOS-only, closed-source, and asks you to pay for full access to its features. It was once one of the only choices for Mac users, particularly those with older Macs since it's the only emulator with a PPC dynarec), but, with the switch to x86 and Mupen64Plus being ported to macOS, it has now become less relevant. However, development is still ongoing and is currently in its third rewrite to support the upcoming Apple Silicon.
- Marked a milestone in Nintendo 64 emulation, in that it was the first to play some popular N64 titles at full speed on hardware made at the time of its release through high-level emulation; it isn't without its drawbacks though - pressure from users, combined with legal threats from Nintendo, forced them to discontinue development. Besides being for historical value, there's not much to expect from this emulator anyway due to compatibility issues.
- Is a Nintendo 64 emulator made in C#. The 'Ryu' word is named after the "RyuJIT" used in both Visual Basic & C#. But it might have been inspired by the lead author's sole (so far) commit at Switch emulator, Ryujinx's Git repository, and his depreciated Ryujinx Auto Updater tool. "86RYU", an x86 JIT compiler, is being developed alongside this emulator too.
- An Android exclusive Nintendo 64 emulator. It is similar to Project 64 1.6 in terms of compatibility, although it is unknown who authored it, as the APK for n64oid circulates on many legally questionable APK sites. n64oid has the infamous problem in Mario Kart 64 of the screen in Wario Stadium not displaying properly, as it displays nothing but black. It upscales all games to widescreen, which works well most of time, but on many phones it will have performance issues. The emulator is relatively poor, but it is much easier to set up than other options. The emulator features a menu with many similarities to the mobile edition of Snes9x EX+, and the My Boy! family of Android emulators for Game Boy systems.
- Main article: Recommended N64 plugins
Nintendo 64 emulation is now decent. A lot of the major problems that N64 emulation had in the past, have been fixed for quite some time now. The only catch is that the accurate emulators have higher system requirements. The main remaining problem is the lack of accurate cycle counting.
High-level vs. low-level graphics
One of the biggest hurdles to emulating the Nintendo 64 was the Reality Display Processor (RDP), which used a custom design that had to be fine-tuned to get more performance out of the system using microcode. To emulate the RDP accurately, one would have to execute said microcode the way the RDP did, which differed from PC graphics cards of the day. To complicate matters further, API standards that were available on PCs two decades ago were nowhere near as flexible as they are today. If you wanted to make an accurate GPU-accelerated RDP plugin in 2003, you simply couldn't with the APIs of the time (OpenGL 1.x and Direct3D 9). For the average user, hardware-accurate GPU acceleration would be out of reach for a long time.
UltraHLE offered a compromise. In contrast to earlier consoles, whose video chips in hindsight had been easy to render to the host CPU's framebuffer, performant RDP emulation had to take shortcuts, including programming around specific games' microcode to cleanly translate their graphics commands into API calls using Direct3D, OpenGL, and even Glide. With this, the theoretical system requirements plummeted, and the host graphics card could reproduce a functional equivalent rather than the exact method. This also gave way to prettier, higher resolution graphics, though whether or not this is an improvement is subjective and a common point of discussion. Unfortunately it proved to be hit and miss, owing to the nature of per-game microcode detection and having to tweak settings to prevent some games from running into graphical glitches.
Low-level RDP emulation was continually improved in that time, most notably by MESS up until its merger with MAME, where its RDP code was turned into a plugin by Angrylion. Compatibility-wise, Angrylion's RDP was considered flawless by the community, though reception wasn't as warm overall, since it ran only on the CPU and was thus painfully slow on mid-grade machines. A dozen forks attempted to bring the system requirements down and the current incarnation that does so is Angrylion RDP Plus, using multithreading. Accurate low-level emulation would only come to the GPU in 2020, when a new version of the Mupen64Plus-based ParaLLEl libretro core was released containing a rewritten RDP plugin using compute shaders in Vulkan. Though it isn't a direct fork of Angrylion, Themaister says the Angrylion code was the central point of reference for developing the plugin, meaning ParaLLEl uses the same strategies that Angrylion does to emulate the RDP while running on the host GPU (as long as said GPU supports Vulkan).
On the high-level side, gonetz and one or two assistants spent a large portion of development improving GlideN64's microcode handling throughout 2016-2018. This means that Factor 5's games are now working in the high-level graphics mode. Other games may still have issues with RDP quirks like frame buffer/depth buffer access (including issues with how the framebuffer is used as well as performance issues), VI emulation, and how combine/blending modes are emulated (such as noise issues and combiner accuracy).
The Nintendo 64 was the first consumer device to be able to filter textures when rendering 3D objects. However, unlike every console and PC graphics card made after the N64, its implementation of bilinear was primitive in that, in order to reduce strain on the system, it only used three samples as opposed to four, resulting in slightly jagged, asymmetrically-filtered textures. Instead of faithfully applying this "imperfect" version of bilinear filtering, HLE plugins instead applied conventional bilinear filtering, interpolating straight from the source texture up to the output resolution the same way a PC game would. While that method is technically superior, it can result in textures that look even blurrier than on real hardware.
Another issue lies with the appliance of texture filtering per quad on static images, text, and sprites. Because each quad is filtered separately, this can cause some visual inconsistencies. Text and UI elements often look as though their edges cut off abruptly, and static images, such as pre-rendered backgrounds or menu screens, may look as though they are separated into squares (see images below; note how OoT's Quest Status screen appears to be divided into a grid). Some plugins allow the user to turn off texture filtering to remedy this, but, unfortunately, this also applies to textures in the game world, exposing their oftentimes low resolutions.
Modern emulators and plugins have taken some steps which help remedy these problems. For instance, GLideN64 now supports N64-style three-point texture filtering, which results in a more faithful look. It is also capable of rendering at 320x240, which sidesteps the issues with filtered text, UI elements, and menu screens, while still retaining texture filtering. Pixel-accurate plugins such as Angrylion and ParaLLEl-RDP do not have these problems at all.
One of the biggest remaining problems in N64 emulation is lack of accurate core timings, which in practice means games do not always run at the speed they would on real hardware. While this technically affects all games, the majority are only affected to a negligible degree, and in some instances (particularly in Rare games) this can actually result in less framerate drops and lag, which can be seen as beneficial. However, some game engines actually depend on accurate timings for proper game behavior, and not properly emulating them can result in considerable to major issues. Some notable examples include the following:
- Intros and cutscenes playing too fast and not properly syncing up with musical cues. Seen in Goldeneye's intro and Body Harvest's beginning cutscene.
- Gameplay demos running at hyper speed. Earthworm Jim 3D is most notorious for this, though the main game itself is largely unaffected.
- Game physics not working properly due to being tied to framerate. A good example is Donkey Kong 64, which is programmed to boost the character's speed and momentum proportional to in-game lag (most likely to make up for the game's frequent framerate drops), which can be exploited for certain glitches and sequence breaks on real hardware. Emulators currently run the game too well and with too little lag, making most of these tricks impossible to pull off.
- Possibly the most affected game is Knife's Edge, which runs like it's on permanent fast-forward, making it all but unplayable. Messing with timing-related settings such as CounterFactor can mitigate this somewhat, but nowhere near enough to fix the issue.
Voice Recognition Unit emulation
The Voice Recognition Unit (VRU) is an accessory used primarily by Hey You, Pikachu. No emulator or input plugin supports this, although there is an on-going effort to get it working.
Densha De Go! Controller
Also available for the PlayStation, Densha De Go! 64 is a Japan-only train simulator released by Taito that is compatible with an optional special controller that plugs into the player 3 port. No emulator supports it.
Pokémon Snap Station
There was a special kiosk designed to promote Pokémon Snap called the Pokémon Snap Station, which is also compatible with the North American Pokémon Stadium with its gallery mode. It is just a Nintendo 64 with special hardware designed for the station. Although the special cartridge boots in emulators compatible with the regular version, the printing functions are inaccessible due to no emulation of the printer for the player 4 slot, credit system, or the special board to switch between the regular and special cartridges.
Transfer Pak emulation
A few games use the Transfer Pak such as Mario Golf, Mario Tennis, Mario Artist: Paint Studio, and the Pokémon Stadium games. Mostly, this can be done with NRage's input plugin, but a couple of things aren't emulated:
- Taking pictures with the Japanese Game Boy Camera (called Pocket Camera) while in Transfer Pak mode playing Mario Artist: Paint Studio displays static.
The 64DD (an abbreviation for "64 Disk Drive") was a peripheral which allowed a proprietary disk format to be used with the N64. These disks had more space at a cheaper manufacturing cost. The peripheral was a commercial failure and was never released outside of Japan. Internal evidence suggests that, much like the GBA e-Reader, it wasn't even intended for a European release.
Expansion disks are region-coded to either Japan or the US (obviously unused) and won't work with N64 games from the wrong region. Only F-Zero X has full support for this feature, but dummied-out expansion data in Ocarina of Time and Mario Party 2 (JP/PAL) exist as well.
The special AV-In cartridge (NUS-028) that Mario Artist: Talent Studio can use doesn't work because it requires an RCA cable signal.
Recently, there has been an effort to emulate the 64DD, and now Project64 and MAME can run several commercial 64DD games as part of its N64 emulator. This is being ported to CEN64 with the help of LuigiBlood. The latest newcomer is Mupen64Plus which is the base of other emulators such as m64p and RMG.
|Name||Platform(s)||Latest Version||N64 Mouse||64DD Emulation||Active||Recommended|
|PC / x86|
- Project64's latest versions emulate the N64 mouse and can load Zoinkity's hacked 64DD cartridge conversions at playable speeds. You'll need to set every game to have 8MB of Memory by default manually. Games do not save, some need "32-bit engine" to be unchecked (like Talent Studio), and some (like Polygon Studio to fix models and Paint Studio to fix stamps) need the Angrylion GFX plugin rather than GlideN64, which does the job for the rest.
- The 64DD hardware started to be emulated around 2.3's release with the help of LuigiBlood. Saving works but in the form of NDR files. NDR files are copied versions of NDD images with save data included as to not write to the clean unaltered images. In order to play 64DD games in their original forms, 8MB of memory is still needed because the real hardware needed the Expansion Pak upgrade. The IPL is also needed.
- MAME includes early basic 64DD emulation as well but is much slower. Disk images need to be in head/track format. See here for more information. It does not currently support disk swapping or saving disk to files. Writes only update the copy in memory, and, once the MAME process ends, the changes are lost. Current usage:
mame n64dd -quickload disk -cart cart -nodrc(both disk and cart are optional)
- CEN64, like Project64, had 64DD emulation ported to it from MAME. However, it focuses on accuracy and plays much slower than other emulators, aside from the 64DD emulation itself is imperfect.
iQue Player emulation
Before the GBA, DS, and 3DS, Nintendo released a modified version of their Nintendo 64 system for the Chinese market, which was called the iQue Player, through their not-quite-subsidiary iQue. Fourteen games were translated into Simplified Chinese, including Sin and Punishment, Ocarina of Time (the Majora's Mask port was canceled), Super Mario 64, and others.
Unlike the Chinese releases of their more recent systems and their games, iQue Player releases are regular N64 roms wrapped with several layers of encryption, as well as a ticket and signature system like that on Wii, DSi, 3DS, Wii U, and Switch. The Chinese ROM-hacking scene is very active though and has translated the Japanese regular N64 releases for many of these to their language already, which explains some of the Chinese ROMs floating for those. However, recently, almost all pieces of iQue Player software were decrypted to regular .z64 ROM format.
Several of the Chinese game localizations already run on N64 emulators, but as some hardware features of the iQue Player are not yet supported, some games, as well as the system menu and features in games such as saving, do not work yet.
Aleck 64 arcade emulation
Nintendo collaborated with SETA to release an arcade system based on their Nintendo 64 system (kind of like their PlayChoice-10 for the NES, Super System arcade hardware for SNES, and later Triforce for GCN). The Nintendo 64-variant with more RAM, the Aleck 64, failed to catch on and bombed. It was never released outside Japan, even though one N64 port made it.
The Aleck 64 ROMs were dumped, and Zoinkity is working on converting them to regular N64 ROMs (with controls remapped to N64 controller buttons). They generally require an 8MB Expansion Pak to run at all and 4K EEPROM to save settings and scores. The ones covered by these patches are:
- Donchan Puzzle Hanabi de Doon!
- Eleven Beat: World Tournament
- Hi Pai Paradise
- Hi Pai Paradise 2
- Kuru Kuru Fever
- Magical Tetris Challenge
- Mayjinsen 3 / Meijin-Sen
- Star Soldier: Vanishing Earth (also ported to N64)
- Super Real Mahjong VS
- Tower & Shaft
- Vivid Dolls (official eroge game on a Nintendo console)
The already available patches to convert arcade ROM dumps to regular N64 ROM format can be found here. While Mupen64Plus-based emulators can't run these conversions out of the box, Project64 does just fine.
The remaining ones from the system's library not yet covered are:
- Rev Limit
- Variant Schwanzer
Virtual Console games in Dolphin
A number of N64 games were released for the Wii's Virtual Console service throughout its lifespan. While the emulators at the heart of each Virtual Console title were of average accuracy (rather than using one generic emulator used for every game, each title had an emulator specifically tailored to that game), they were good enough to render the games in full playable capacity with few to no glaring errors. Many of these titles are emulated well through Dolphin, and for a good while, due to persistent long-standing inaccuracies in N64 emulators and plugins, this was the best way to emulate certain N64 games, particularly Pokemon Snap and Mario Tennis. The system requirements are much higher than running them on regular N64 emulators, but it's doable for many games. Today, regular N64 emulators and plugins have advanced to the degree that this has become unnecessary, relegating this method of N64 game emulation to little more than a curiosity, at least on PC.
The following games are on the N64 Virtual Console for Wii:
- Though a separate add-on was later released called the "Expansion Pak" that added an additional 4MB of RAM, totaling 8MB.
- loganmc10. Ignore TLB write if TLB entry is unmapping itself. "By the way, once this, along with the other PR's I have waiting are merged, we are at "compatibility parity" with Project64 as far as I can tell. I don't know of any game that doesn't boot with mupen64plus that works in PJ64."
- README for parallel-rdp repository on GitHub. § Disclaimer. "While paraLLEl-RDP uses Angrylion-Plus as an implementation reference, it is not a port, and not a derived codebase of said project. It is written from scratch by studying Angrylion-Plus and trying to understand what is going on. The test suite uses Angrylion-Plus as a reference to validate implementation and cross-checking behavior."
- Public Release 3.0. Blogspot (2017-12-29)
- Initial implementation of BOSS ZSort ucode (WDC, Stunt Racer). GitHub (2018-02-10)
- "Indiana J. & Infernal Machine" HLE. Indiegogo (2018-05-17)
- HLE implementation of microcodes for "Indiana Jones" and "Battle for Naboo" completed.. Blogspot (2018-05-26)
- Hey You! Pikachu - Possible HLE Implementation. emutalk (2014-10-27, Last edit: 2016-04-04)
- Densha De Go! Nintendo 64 Controller!. YouTube (2017-01-20)
- The Pokemon Snap Station. YouTube (2016-05-21)
- VIDEO GAME KIOSKS - Extreme Game Collecting!. YouTube (2016-05-25)