(Update 22-09-19: An update has been released for the SNES core, bringing a few fixes and enhancement chip changes. Because the Pocket is designed differently than the DE-10 Nano board that powers the MiSTer, it’s going to take a little more time for the Pocket port of the SNES core to support all of the enhancement chips at the same time. For now, agg23 has decided to remove S-DD1 support in favour of adding DSP chip support (e.g. Pilotwings, Super Mario Kart). This does not mean that S-DD1 support will be gone forever though! It’s just a temporary change to support a broader selection of games until more chips can be added to the core.
Earlier this week, Sergey Dvodnenko‘s Super Nintendo FPGA core was ported to the Analogue Pocket by Adam Gastineau. As you might assume from its v0.1.0 designation, the port is far from being finished but is also surprisingly feature rich for such an early release. In addition to all the basic cartridge games, users can currently run titles with the following special chips:
-
- SA-1 (e.g. Super Mario RPG, or any of Vitor Vilela‘s SA-1 hacks)
- SuperFX (e.g. Star Fox 1 & 2, Doom)
S-DD1 (e.g. Star Ocean, Street Fighter Alpha 2)[Removed in v0.2.0]- CX4 (e.g. Mega Man X2 & X3)
- DSP-1 (e.g. Pilotwings, Super Mario Kart) [Added in v0.2.0]
The core also supports two-player multiplayer through the dock and four-player support is planned for future releases. Beyond the stated limitations, there have been a handful of bugs reported with popping sounds and reversed audio channels, which have been reported on the GitHub. If users are interested in reporting any issues they find, the best place to do so is on the same GitHub where you acquire the core.
It’s worth mentioning that, just like the Sega cores RetroRGB covered here a few weeks ago, geometry in the SNES core is not rendered in a standards-compliant way straight out of the box. The default setting for this core is to display games in an 8:7 aspect ratio, which has been a controversial topic in gaming for what seems like forever. Also just like those Sega cores, the only way you can change the way the core is displayed is by editing the core’s “video.json” file in your text editing program of choice. Every user has their own preferences when it comes to Pixel Aspect Ratio and Display Aspect Ratio, but I want to take a second to reiterate why I prefer a wider DAR for the SNES.
The SNES usually renders its output at 256×224 pixels. When you do the math, 256×224 is an “8:7” format because for every eight horizontal pixels there are seven vertical pixels. You might think then that scalers, emulators, or FPGA cores should reflect this then—e.g., if you have your vertical axis scaled 5x then scaling the horizontal axis by 5x should be appropriate too, because then your final video output would still be in an 8:7 aspect ratio.
The problem with this approach is that analog televisions don’t work the same way that modern digital screens do. We think of a pixel as being a perfect square because that’s what it looks like on an LCD or OLED screen, but “pixels” on a CRT aren’t displayed as perfect squares. A lot of analog formats are meant to display pixels as rectangles, and depending on the signal those rectangles can either be wider than they are tall or taller than they are wide. A great resource, which I understand comes with the caveat that it shouldn’t necessarily be used as a primary source, is this list of dot-clock rates on Pin Eight.
Looping back to the 8:7 aspect ratio, the thing that makes displaying SNES video kinda confusing is that it almost always renders its graphics at 256×224—an 8:7 resolution—but also each individual “pixel” is a rectangle that is meant to be an 8:7 shape. When you do the math, that means that the standards compliant aspect ratio of SNES video is 64:49, or roughly 1.31:1. If you’re not a huge stickler for the math, 4:3 or 1.33:1 is only a difference of 2% and is perfectly serviceable as a way to view the SNES.
The tricky part about this is that, while that is how analog video functions, the artists making these games may not have accounted for non-square pixels in their work and it therefore it looks stretched when displayed in a standards compliant way. Looking through the canon of pre-HDMI console libraries, it’s honestly kind of a crapshoot which approach the artists targeted. An ideal scenario would be per-game settings, but it’s anyone’s guess if those will be possible on PocketOS in the future.
Lastly, it should be noted that the Pocket’s interpolation settings here are producing uneven pixels on the vertical axis in 4:3 or 64:49 modes currently. This is also an issue for the Sega cores we covered earlier and is probably just a product of the fact that PocketOS is still in beta, but I do find it interesting that the Neo•Geo core doesn’t seem to have this issue despite being a 240p console. Regardless, I don’t imagine this will be an issue forever and I still plan to play games with a 64:49 DAR for now.
v0.2.0 seems to also have addressed some of the more glaring issues with vertical scaling. There are still a lot of uneven pixels in checkerboard patterns, but it’s less noticeable in this release. I’m looking forward to more robust interpolation, but in the mean time it’s not the most glaring issue on a screen this size.