Ryan Finnie

So you want a Stratum 1 NTP server...

(Standard warning: I’d consider myself an informed amateur in this field, so don’t take anything I say as gospel.)

MECCA GPS time receiver

The Global Positioning System is an amazing piece of technology. In very simple terms, GPS is a constellation of moving satellites which simply broadcast when they are, and rely on you to know where they can be in the sky. Picking up one satellite by itself is useless. Two let you determine your position to somewhere in a radial line around the Earth. Three pinpoint you to a specific latitude and longitude (2D fix). And four or more let you pinpoint elevation (3D fix).

To do this with any sort of accuracy, the clocks onboard the satellites must be extremely accurate. GPS atomic clocks use cesium (or more recently, rubidium) as an oscillator, and are theoretically accurate to within 14 nanoseconds. So great, you have a free source of high-precision timekeeping! Just hook up a consumer GPS receiver to your computer and you have a Stratum 1 device, right?

There’s a small problem, in that there’s a lot of uncertainty in getting from the receiver to your computer. The receiver may say “the current time is 01:23:45.000 UTC”, but there’s a (relatively) massive amount of time between “the” and “UTC”. When was it 01:23:45.000 UTC?

The solution is PPS, or 1PPS. It’s simply a high precision pulse, once per second, at the same time (or as close as can be) every second. Usually the PPS pulse is at the top of the second, and then the receiver has the rest of the second to send its data to the computer.

Many modern GPS receiver chipsets support PPS, but almost no consumer devices support exporting it. Take apart nearly 100% of the “mouse” style u-blox USB receivers, and you will often see a PPS solder pad, but nothing to attach to it. The embedded USB TTL chipset just doesn’t support it.

USB GPS PPS receiver (breadboard)But you can build your own. The FT232R USB chipset has support for emulating all RS-232-style serial control signals, including Data Carrier Detect. DCD’s classic meaning in serial communication is basically “I’m ready to begin sending you something”, so the logic maps well to the PPS concept. This post by Larry Cochrane explains how to pair a $15 GPS receiver module with a $10 FT232R-based USB TTL adapter to get a USB GPS receiver with PPS support. This was the first design I built.

This is fine for a home NTP receiver, but there is a problem. USB is laggy, in the realm of local high-precision timekeeping. (Still better than you could do from an Internet NTP source.) Worse still, it’s unpredictably laggy, i.e. jitter. USB 1 and 2 are packet-based, and it’s not guaranteed packets will arrive over the bus in the exact same amount of time. The average latency from the receiver to the software may be 200 microseconds, but the jitter may be ± 300 microseconds.

If we want to get serious, we need to go old school. RS-232 serial is interrupt-based. An electrical signal comes in, the CPU pauses whatever it’s doing to read it. (In a tiny amount of time; the amount of time lost processing the interrupt is insignificant for modern computers.) And amazingly, the beast of a home server I built late last year — a Ryzen 7 2700X with 64GB memory and 9 hard drives — still has a motherboard with an RS-232 header on it.

Let’s take a moment to discuss RS-232 and TTL. TTL is the language of nearly all modern serial components (such as the GPIO pins on your Raspberry Pi). A one is 3.3V (high), a zero is 0V (low). Fine for high-ish-speed, physically short runs of a few inches. But RS-232 is what home computers used to use for serial communication to devices such as modems. With RS-232, high is anywhere between 3V and 25V, and low is -3V to -25V. Signals between -3V and 3V are discarded as garbage. This was useful for reliable longer-length cable runs.

So we can’t just solder our GPS receiver (TTL) to a DB9 port and plug it into a computer. We need something to actively translate between TTL and RS-232 voltages. There are plenty of TTL to RS-232 DB9 adapters on Amazon and eBay. The problem is they’re almost all based on the MAX232 chipset or similar, which only supports two drivers (transmit from the TTL device to the PC) and two receivers (receive from the PC to the TTL device). 75% of these adapters will implement TX and RX only, and the other 25% will also support CTS and RTS, but no DCD.

The MAX3238 chipset supports five drivers and three receivers, and is designed specifically for full RS-232 translation. As far as I’ve been able to find, there is exactly one manufacturer currently making breakout boards based on the MAX3238: the Pololu 23201a for about $10.

So now, let me present to you MECCA: Measuring Expensive Cesium Clocks in the Air.

MECCA GPS time receiver (open case)

The RS-232 board is the Pololu 23201a. The USB board is a random cheap micro USB header to supply 5V to the GPS receiver, which is an Adafruit Ultimate GPS Breakout. The Adafruit receiver is quite expensive, about $40, but I chose it because it has an automatic external antenna header, something I didn’t find on any of the $15 eBay modules. But if you’re in a relatively open area, the $15 modules with their built-in antennas should be fine.

The receiver has a 3.3V regulator which drives the TTL logic, but also powers the RS-232 board. It’s a pretty simple schematic; the hardest part was soldering the various VCC bridges (needed to keep DSR, CTS and RI high) on the breadboard connecting the RS-232 and USB boards to fit in the project box. (I left the GPS receiver modular since it’s the most expensive component of the setup.)

MECCA 1.0 schematic

One thing to note if you go for the $15 bare module: The “enable” pin must also be tied to VCC to enable it. On the Adafruit module, “enable” is pulled high by default and can be tied to ground to disable it.

If you wanted to go more versatile, you could build something which supports USB or RS-232:

MECCA 2.0 schematic

FT232R-based USB converters support “PWREN”, which is high when the converter has power, but goes low when the converter actually has USB communication with a host. This can switch a P-channel MOSFET to VCC on the RS-232 converter, so it’s only active when there’s simple USB power. The only reason I didn’t build this is because fitting it all in a small project box would be tight (and I didn’t happen to have a suitable MOSFET at the time).

Now that you have a PPS-capable receiver, you’ll need gpsd which will interface with ntpd. This gpsd page goes into excruciating detail about the theory and the operation, so I won’t go into the details here. My final ntpd configuration is the standard ntp.org pool config (ntpd works best with other peers to act as sanity checks), plus the following:

# GPS Serial data reference (NTP0)
server 127.127.28.0 minpoll 0 maxpoll 0 noselect
fudge 127.127.28.0 time1 0.521643 refid GPS

# GPS PPS reference (NTP1)
server 127.127.28.1 minpoll 0 maxpoll 0 prefer
fudge 127.127.28.1 refid PPS

I wouldn’t worry too much about fine-tuning the GPS reference. My offset (“time1”) is 521.643ms, but the jitter can be up to 60ms, so I’ve explicitly told ntpd to track it but not to consider it (“noselect”). Even if I didn’t explicitly specify “noselect”, it would eventually work out that the jitter is garbage and ignore it (with an “x” in “ntpq -p”). The kernel PPS feed is the high-precision component, and has an average jitter of about 7 microseconds.

Weighted file cleanup

I’ve got four security cameras streaming to my home server, and save the most recent 3 TiB of raw recordings locally. I won’t go too much into the details (because they’re out to get me, of course), but cam2 and cam4 are the main ones, and I would like to save them locally the longest. However, cam4’s file sizes are larger than cam2’s. cam1 is in an unimportant area so I don’t want to save as much, and cam3 is only used on demand, so it has an even lower priority.

I struggled with a system for deleting old recordings, but recently came up with what I believe is a decent system. I assign file globs into per-camera collections, and then assign a weight to each collection. cam2 and cam4 each get a weight of 1.0, cam1 gets 0.2 and cam3 gets 0.1.

It then goes through what can be multiple rounds, determining if each collection is over or under its weighted share of the total target. If a collection is under target, it is eliminated from the round, but importantly its usage is removed from the considered total target for the next round. Rounds continue until all collections in the round are over target.

cam1: 3809 files, 364.82 GiB, 0.20 weight
cam2: 8226 files, 809.57 GiB, 1.00 weight
cam3: 529 files, 83.86 GiB, 0.10 weight
cam4: 7514 files, 1817.40 GiB, 1.00 weight
Grand total: 3075.66 GiB used, 3072.00 GiB target, 3.66 GiB above target
Round 1: cam1: 364.82 GiB used, 267.13 GiB target, 8.70% round weight of 3072.00 GiB, 97.69 GiB above target
Round 1: cam2: 809.57 GiB used, 1335.65 GiB target, 43.48% round weight of 3072.00 GiB, -526.08 GiB above target (disqualifying)
Round 1: cam3: 83.86 GiB used, 133.57 GiB target, 4.35% round weight of 3072.00 GiB, -49.70 GiB above target (disqualifying)
Round 1: cam4: 1817.40 GiB used, 1335.65 GiB target, 43.48% round weight of 3072.00 GiB, 481.75 GiB above target
Round 2: cam1: 364.82 GiB used, 363.09 GiB target, 16.67% round weight of 2178.57 GiB, 1.73 GiB above target
Round 2: cam4: 1817.40 GiB used, 1815.47 GiB target, 83.33% round weight of 2178.57 GiB, 1.93 GiB above target
cam1: Freeing 1.73 GiB
Deleting /media/camera/streams/cam1/cam1_XXX.mp4 (175.85 MiB)
Deleting /media/camera/streams/cam1/cam1_XXX.mp4 (102.45 MiB)
Deleting /media/camera/streams/cam1/cam1_XXX.mp4 (103.56 MiB)
[...]
cam4: Freeing 1.93 GiB
Deleting /media/camera/streams/cam4/cam4_XXX.mp4 (844.88 MiB)
Deleting /media/camera/streams/cam4/cam4_XXX.mp4 (839.17 MiB)
Deleting /media/camera/streams/cam4/cam4_XXX.mp4 (797.06 MiB)

In this example, in round 1, both cam1 and cam4 are over their weighted share of the total 3072 GiB target. cam2 and cam3 are under so they are removed, and the total target of the next round’s considered collections is reduced to 2178.57 GiB. In round 2, cam1 and cam4 are re-evaluated according to this target, using their own weights compared to each other (not all collections). It’s actually possible a collection can be over target in one round but under the next, triggering a round 3 (cam1 used to do this until a few days ago). With the final weights determined, files from each collection are deleted until they come in under their collection target.

Right now, the initial round is massively skewed since the this system is new, with cam4 largely above target and cam2 is largely below target. But over time, this will even out to their respective weights. The nice part of this system is it’s not wasteful if a collection is below target; as I mentioned, cam3 is only used on-demand and will likely always be below its target of 133.57 GiB. But because of that, it’ll always go on to a new round which will utilize the extra space, and the global target will always be 3072 GiB utilization.

The full Python code is available here. I’m pretty sure I’ve got all the corner cases worked out, but obviously please use caution if you use this. (I’ve commented out the line used to actually do the delete.)

CMYK printer line test sheet

CMYK printer line test screenshot This week I bought a new color laser printer, a Brother HL-3170CDW. It’s replacing my old laser printer (Brother HL-2270DW) and inkjet (Canon MX922), the latter I got sick of being, well, an inkjet printer.

I use to have a weekly test print sent to the Canon, to prevent the nozzles from seizing and to notice when the ink cartridges were empty. This was a cropped test print I found online, and mostly did the job. But with the new printer, I decided to design my own test page. It’s not comprehensive; there are better tests out there for when you suspect something is wrong, for example it doesn’t test gradients. The one I designed is specifically for a weekly test, and will point out ink/toner problems while not using much ink/toner.

For each tested color (cyan, magenta, yellow, black, magenta/yellow, cyan/yellow and cyan/magenta), it shows a series of 15mm lines at 2.0, 1.0, 0.75, 0.5 and 0.25 points. The lines are shown horizontal, vertical and at 45 degree angles. Each tested color’s total surface area is 285.84mm² (which would be about a 16.9mm square, so roughly equal to one of the colors’ individual squares). All ancillary text is grey to make the pure tested black stand out.

Download:

I have my Ubuntu laptop run the following every Sunday morning:

lpr -P brotherc /path/to/CMYK_Line_Test_US_Letter.pdf

(Replace “brotherc” with your printer identifier.)

Building a RetroPie game console

RetroPie system with monitor and controllers Early in 2017, I did a three part series, “Re-Buying My Childhood”, where I tracked down and re-purchased the various Nintendo consoles and games I owned as a kid. It was a fun process, but since then, all the consoles (except the Game Boy Color) and games have sat in a box.

See, the problem with collecting a set of 30+ year old hardware is at the end of the day, you’re left with 30+ year old hardware. The NES and SNES don’t even work with my living room’s 65” 4K LCD TV. (My working theory is the TV expects a proper 480i composite signal, while Nintendo consoles of the time would output a slightly standard-breaking 240p which is to be interpreted as 480i.)

Even if they did work, I don’t really have room in my living room’s entertainment center. And I don’t have a “man cave” where I can set up a proper CRT TV to play them on. And let’s face it, I (and the world) have gotten lazy over the last 30 years or so. Get up from the couch and physically switch out a bulky cartridge to play a single game?

So this year, I decided to build an emulation box for the living room. As an aside, I like to take things apart, figure out how they work, break them, re-implement them, make them do new things, etc. This plays into the story of my last emulation box: years ago, I built an i3 system into a small Shuttle case. I installed Ubuntu, got emulation software working, and wrote my own custom front-end launcher system.

I ended up rarely using it. The problem was there was always something wrong or quirky with it. It wouldn’t be on when I wanted to play and would require a full boot and log-in cycle (digging out a USB keyboard to attach). The wired USB control pad wouldn’t be attached and might be in a drawer somewhere. The front-end software I wrote might not work right.

No, if I wanted to do a new emulation box, I would need to suppress my desire to tinker with every internal aspect of the box and build something which is self-contained and just works. A simple RetroPie setup. Well, that was the theory, anyway. Ironically, this post has been delayed by months because I’ve been continually switching out and modifying things, but the important difference is that at any point during the last few months, the system has always been in a “just works” state. I could pick up the controller and be within 30 seconds of gameplay.

The hardware

I didn’t want to build a mini x86 system, and RetroPie is primarily targeted at the Raspberry Pi. When I first built the system, it was a Raspberry Pi 3, but shortly after, the 3 B+ (slightly better CPU and Wifi) was released and I switched to that. Either would be fine, but while technically RetroPie is supported all the way down to the original Raspberry Pi models, I wouldn’t recommend anything older than a 3 due to the emulation’s CPU demands.

Good power is an absolute requirement. When I originally built the system, I used the first random micro-USB cable I found lying around, plugged into a shared USB power supply. But when playing games, I would get slowdowns combined with a yellow lightning bolt in the corner of the screen. This meant the Raspberry Pi was not able to get a continual clean 5v supply, and was throttling itself as a result. I replaced the USB cable with a better quality one, and while it helped a bit, the slowdowns were still present. I finally swapped it out for a dedicated 2.5A micro-USB power supply from CanaKit, and the problems went away completely. In fact, if you’re starting from scratch, I’d recommend buying a complete kit from CanaKit which includes a Raspberry Pi, good power supply, case and a few other accessories.

A decent heatsink is also needed. The standard square ones found everywhere will minimally do the job, but I recommend a full-coverage heatsink as large as possible. I’ve currently got a very nice heatsink from Kintaro which covers almost the entire board. The problem is, as of this writing, the model I have (for the 3 B+) doesn’t appear to be for sale, just the 2 / 3 B model.

A fan may also be nice to have, but I’ve found if the heatsink is good enough, it’s not strictly needed.

Kintaro Super Kuma, Retroflag SUPERPi, SNES Classic Mini (EU version), original SNES

From left: Kintaro Super Kuma (RPi), Retroflag SUPERPi (RPi), SNES Classic Mini (EU version), original SNES

The case

Technically, any case will do – or even no case; just chuck the board next to the TV. But let’s be honest, I wanted something nice and retro-looking for the living room. I got the Kintaro Super Kuma, an SNES lookalike Raspberry Pi case. This thing was tiny (and therefore adorable), taking up little more than the footprint of the Raspberry Pi itself and about half the size of even the SNES Classic Edition, while still looking like an authentic SNES. There were a few small cosmetic issues, such as the top buttons were decorative only and the plastic colors were a bit lighter than authentic, but I was fine with that until something better came along…

… Which it did, a few months later with the release of the Retroflag SUPERPi case. The SUPERPi is larger than the Kintaro case, is dimensionally identical to the SNES Classic Edition, and the colors are spot on. There’s also a Super Famicom-styled case if you prefer that instead, but I find the SNES styling to be great.

The power and reset buttons are functional, attaching to GPIO pins on the Raspberry Pi. Even the eject button is functional, popping up the cartridge slot to reveal a small space which can be used to store MicroSD cards. Finally, the front controller port area features two USB ports for attaching wired controllers, while leaving the other two Raspberry Pi USB ports accessible on the side of the case. The case even comes with an SNES-style USB controller, which is great quality as far as SNES controller clones go.

I wanted to retain the excellent Kintaro full-spread heatsink, but there were some compatibility issues with its size which required a bit of light surgery. Ultimately I removed the cartridge slot storage and forced close the slot cover, making the eject button nonfunctional, but I’m fine with that as a trade-off for a better heatsink.

The controller

I actually wrote an entire post just on controllers; please take a look if you want all the details. But in general, you can use nearly any controller with RetroPie, wired or wireless, if you have enough time and/or money for the more esoteric combinations. But nearly any wired USB controller should work out of the box with RetroPie.

My current favorite is the 8Bitdo SN30 Pro, a Bluetooth controller which feels nearly identical to the original SNES controller, but has the addition of dual analog sticks and extra trigger buttons. It’s a little uncomfortable for longer play sessions (as was the original SNES controller), so I am looking forward to the SN30 Pro+ later in 2018, which is functionally identical to the SN30 Pro but has ergonomic wing grips.

The software

This is the part I’ve fiddled the least with, intentionally. I just want it to work reasonably well. I downloaded RetroPie, wrote it to a MicroSD card, and ran it. The only reason confusion came from the initial startup: it booted up to a RetroPie configuration menu, and that was it. I sort of expected a list of emulators, or some sample open source games, or similar. Turns out the emulated systems will automatically appear once you upload ROMs to it, something easily done with scp.

Obviously I’m not going to get into the legal or moral aspects of ROMs, but I will say I’ve got ROMs of the cartridges I’ve purchased, as detailed in a previous post. I even headed to a local retro game shop one weekend (yes, we have a local retro game shop), picked up a few PS1 games and ripped them.

(Is it a problem that I’ve ripped CDs for a system I’ve never owned? Technically yes, since the PS1 emulator requires a BIOS ripped from original hardware. But hey, Sony sued Lik-Sang out of existence, so screw them. Yes, I’m still bitter.)

Overall, emulator performance and compatibility is excellent with nearly any system of PS1 era or older, with one exception. NES, SNES, Game Boy and PS1 games all seem to work great. The one major exception is the Nintendo 64. In general, don’t bother on the Raspberry Pi, or use a modern desktop PC if N64 emulation is desired. RetroPie has an entire page of half-baked tips and tricks to get acceptable N64 speed on a case-by-case basis, but even its own docs discourage you from trying. The Raspberry Pi just isn’t powerful enough for the N64’s quirky architecture.

In general, I’ve mostly left the RetroPie software itself alone, but there are a few tweaks I’ve made. I’ve forced the resolution to 1280x720 (on my massive 4K TV) and enabled integer scaling for better performance, with the idea that the emulator should spend as little effort as possible on actually outputting the graphs, and let the TV handle the rest. I also needed to install handler software for the case’s power/reset GPIO buttons, even though I don’t ever turn off the system itself.

The blockiness of the graphics on a 65” TV are noticeable, so I spent a day playing with various graphics shaders, but eventually settled on the simple built-in bilinear filter. It softens things but doesn’t do anything else. People will argue endlessly about scanlines, but my rose-tinted glasses don’t remember scanlines being part of the authentic CRT experience growing up, so they don’t look “right” to me.

Overall, I think I’ve accomplished my goal. A simple retro system which is fun and easy to pick up and play.

Retro controllers for the RetroPie

RetroPie computer with 8Bitdo SN30 Pro

This post was originally part of a longer article about building a RetroPie game system.

Also, let me stress that controller design is a very personal preference, and has been known to cause intense discussions and the occasional bar fight. The following are my own opinions. Put down your pitchforks.

My favorite controller is the Xbox 360 controller. I consider its feel to be perfect, with one notable exception which I’ll get into soon. The analog sticks feel great, and are in the perfect locations. The face buttons have just the right amount of travel. The shoulder buttons are just long enough for my personal play style (using just the index finger to control both the trigger and shoulder buttons, with the finger pad controlling the trigger and the fleshy part near the finger base to bump the edge of the shoulder).

Many people prefer the Xbox One controller, but I think it’s slightly inferior in many ways: the trigger and face buttons are a tiny bit too stiff, the length of the shoulder buttons are slightly shorter, and the analog sticks have a slight texture I don’t prefer. Don’t get me wrong, overall I still rate the One controller as a very close #2, but still prefer the 360 controller.

Note that I’ve been avoiding talking about the D-pad, which was the exception I mentioned previously: the 360’s D-pad is terrible. I’m lucky if the direction I want is the direction I get. The One’s D-pad is light years better. But it was rarely an issue in the 360 generation since the D-pad was often relegated to option selection (for example, cycling through weapons).

So why not simply use an Xbox controller on the RetroPie? The Xbox controllers are what I call “analog-first”; that is to say, they work best when playing games designed for analog movement (so, modern). In my hands, the most comfortable position is for the thumbs to be resting close to the rest of the hand. On Xbox controllers, this means left thumb rests on the left analog stick, right thumb rests between the face buttons and the right analog stick. Perfect for modern games.

But the RetroPie isn’t a system for modern games. In retro games, the D-pad is the main attraction. I need a “digital-first” controller. So what options are available for a RetroPie system?

8Bitdo SN30 Pro / SF30 Pro

8Bitdo SN30 Pro The SN30 Pro (or SF30 Pro; the only difference is Super Famicom-style cosmetics) is essentially a Bluetooth SNES controller, with the addition of dual analog sticks and trigger buttons. Besides those additions, 8Bitdo has nailed it emulating the feel of the buttons compared to an authentic SNES controller. If you grew up with the SNES, the SN30 Pro will feel exactly the same.

In my opinion, the Nintendo cross-style D-pad is the best for digital movement, so there are no compromises here. And since the D-pad is the leftmost part of the SN30 Pro, it fits the “digital-first” desire. But since it does include dual analog sticks and trigger buttons, it can be used for PS1 games or similar.

RetroPie bluetooth setup is relatively easy, once you put the SN30 Pro in Switch compatibility mode (hold Start+Y before pairing). Input lag is present (as will be with any Bluetooth controller) but is negligible.

There are only a few downsides, one of which is the shoulder buttons are hard to locate while gaming. See, the SN30 Pro is slightly thicker than an SNES controller, but is still rather thin. Fitting both sets of shoulder and trigger buttons means the shoulder buttons are thinner than normal SNES shoulder buttons, and are harder to hit. I’ve solved this by going into the libretro setup for each core which utilizes shoulder buttons only (SNES, GBA) and told it to treat the trigger button the same as the shoulder button. Once I did that, I found myself subconsciously using the trigger buttons when needed, which work fine.

(For this reason, I would recommend against the SN30 Pro for modern gaming, especially with games like Mirror’s Edge, which requires you quickly and accurately move between shoulder and trigger buttons.)

Another downside I’ve found is while the controller is supposed to sleep after 15 minutes of input inactivity, it doesn’t appear to do so. I’m guessing something with the RetroPie menu system is continually polling the controller and keeping it awake. The solution is to remember to manually turn off the controller when you’re done (hold Start for about 5 seconds until the status light turns off).

And finally, the exterior closely matches an original SNES controller, for good and for bad. That is, it’s a little small for adult hands, and ergonomics have progressed since the 90s, mainly wing grips for better holding. Playing for hours on end can cramp my hands a bit.

The 8BitDo SN30 Pro+ is due to be released during the 2018 holidays, and looks to solve the shoulder/trigger issues and adds wing grips while otherwise seemingly keeping all the other functional elements identical. However, it strays just a tiny a bit from the SNES clone aesthetic versus the original SN30 / SN30 Pro. I have high hopes, and will be buying one when it’s released.

Original SNES / SFC controller

The original SNES controller is widely considered to be the best controller of its day. Ergonomic (for the period), responsive, well built, and well laid out. The issue is it’s digital-only, so you’re limited in game choice for emulated systems like the PS1.

You will need a USB adapter for the SNES controller, but those are readily available online. I’ve got a pair of 15 year old Lik-Sang (rest in peace) adapters, which oddly aren’t recognized by EmulationStation, despite appearing as standard USB gamepads on everything else I’ve used them on over the years. I haven’t actually looked into why they’re not being recognized yet, but these specific adapters haven’t been made in literally decades and plenty of other modern equivalent models exist.

Edit: Turns out the Lik-Sang Super SmartJoy consumes too much current for the Raspberry Pi. Daisy chaining it through a powered USB hub works fine.

Playstation DualShock 4

Red DualShock 4 Later I ordered a Mayflash Magic-NS and a DualShock 4 controller. The Magic-NS is a USB adapter which accepts nearly any mainstream wired or wireless controller (DualShock 3/4, Switch Pro, Xbox 360/One) and allows for play on the Switch or PC (using Dinput or Xinput). Pairing and usage works fine, and I didn’t perceive any additional input lag.

I’m not sure about the DualShock 4. It fits my “digital-first” layout since the D-pad is on the top left. I think the Nintendo-style D-pad is much better, but the Sony-style D-pad isn’t bad. It’s more comfortable for long play than the SN30 Pro due to the modern wing grips. And it works well for nearly all retro games, with one major exception: Super Metroid.

First, the option buttons (share/options) are flush/recessed with the controller, making them harder to press unless you really mean it. This is great for most games since their retro equivalents (select/start) are rarely used during gameplay. But by default, Super Metroid uses the select button heavily for weapon switching. (Yes, I know you can remap buttons within the game, but I’ve got over 20 years of muscle memory built up.)

Also – and this is something I didn’t even notice until trying to play Super Metroid on the DualShock 4 – the SNES’s (and SN30 Pro’s) face buttons are not equidistant. The space between the top and bottom buttons are less than the space between the left and right buttons. The result of this is it’s much easier to quickly switch between the top, bottom and right buttons. Super Metroid takes advantage of this, with the bottom being run, right being jump and top being fire. (The game designers were likely well aware of this since they relegated weapon cancel to the left button, which is harder to hit if you’re centering your thumb around the other three.)

I busted out the digital calipers and measured the distances between horizontal and vertical face buttons on a number of controllers:

  • SNES / SN30: 17mm horizontal, 11mm vertical
  • Switch Pro: 13mm horizontal, 11mm vertical
  • Xbox One: 11mm horizontal / vertical
  • Xbox 360 / DualShock 4: 13mm horizontal / vertical
  • DualShock 3: 15mm horizontal, 13mm vertical

This explains why I was having a harder time with Super Metroid on the DualShock 4: it’s harder to quickly move between three face buttons due to the equidistant layout and longer space between buttons. Comfortable for two buttons at a time, but not three.

Super Metroid is a relative outlier here, since so many games only tend to rely on two face buttons at once, but considering it’s one of my top five games of all time, it’s a definite concern.

Other controllers

As mentioned, the Magic-NS can adapt nearly any first-party controller, so there are no limits to personal preference. If you prefer the D-pad to be on the bottom-left even for retro games, you could use an Xbox 360, Xbox One or Switch Pro controller. I’ve got a DualShock 3, which has easier to press control buttons than the DualShock 4, but I don’t like the feel of the wing grips on older DualShocks. (Also, I’m pretty sure it’s a counterfeit, but it’s hard to tell since apparently Sony really lowered the design quality on the later-model DualShock 3s.)

And of course nearly any third-party wired controller should work fine. I’ve got a horribly cheap feeling Logitech F310 controller. I don’t even remember buying it, but it somehow showed up in my box of USB accessories. I would never consider using it for actual gameplay, but RetroPie supports it fine.

« All posts