Sunday, March 5, 2017

Raspberry Pi 240p Composite Output

Big news for emulation on Raspberry Pis of any generation: a new firmware update has enabled 240p output through the composite video-out port (a dedicated port on older models and a combo 3.5 mm jack on newer models).

From Raspbian and its derivatives, you can run from a terminal:
sudo rpi-update
and it will automatically install the new firmware. For Lakka, the updated firmware will make its way into the main release at some point, but in the meantime, you'll need to mount your SD/microSD card on another machine and then find the 'boot' directory (for Lakka, this will be located in the ~500 MB partition that holds the system files rather than the bigger partition that holds your games) and make a backup in case anything goes wrong (not likely, but better safe than sorry).

Next, you'll need to download the new firmware files from github (here's a direct link to a zipped download) and copy them into the boot directory, overwriting what's already there. I believe you only really need a subset of the files (bootcode.bin, fixup.dat, fixup_cd.dat, fixup_db.dat, fixup_x.dat, start.elf, start_cd.elf, start_db.elf and start_x.elf), so if it acts strangely, maybe try cutting down to just those files.

In your config.txt, you can use the sdtv_mode directive to change to the new modes (either NTSC or PAL):
sdtv_mode=16    # progressive NTSC
sdtv_mode=0x10  # progressive NTSC (using hex notation)
sdtv_mode=18    # progressive PAL
sdtv_mode=0x12  # progressive PAL (using hex notation)
Also, make sure your config.txt isn't forcing HDMI output via hdmi_force_hotplug=1 (comment it out, if so) and you might want to force composite output, just to be sure, by adding hdmi_ignore_hotplug=1.

Raspbian and derivatives can now also change modes at runtime using the tvservice program:
$ tvservice -c "NTSC 4:3" ; fbset -depth 8 ; fbset -depth 32; tvservice -s 
Powering on SDTV with explicit settings (mode:0 aspect1)state 0x40001 [NTSC 4:3], 720x480 @ 60.00Hz, interlaced
for interlaced mode or:
$ tvservice -c "NTSC 4:3 P" ; fbset -depth 8 ; fbset -depth 32; tvservice -s 
Powering on SDTV with explicit settings (mode: 16 aspect:1)state 0x40001 [NTSC 4:3], 720x480 $ 60.00Hz, progressive
for 240-line non-interlaced mode.

Now, you'll notice that the above line still says 720x480 and applications will still see a 480-line resolution (that is, emulators will want to run at 2x scale). That's because the firmware still acts like normal 720x480 (or 576 lines for PAL) and the composite encoder just displays only half the lines.

This is actually to our benefit because it allows us to easily go back and forth at runtime and has the potential for on-the-fly switching (though RetroArch/Lakka doesn't support that and probably never will). It also allows emulators to show interlaced content without freaking out (that is, a "true" 240p resolution would cut off half of the picture, while this setup will just blank out every other line, which is much less obtrusive).

I have some pics here but, hilariously, the one from the new firmware turned out the worst:
RPi 240p Composite

Analogue Nt - RGB-PPU YPbPr

RPi 480i Composite
If you look closely, you can see that the RPi 240p shot has gaps between each scanline (easier to see on the green waves of the hill than on Luigi), while the 480i shot does not. What the still image can't show is that the 240p image is rock-solid stable, while the 480i image flickers sickeningly. Either way, the RPi composite output obviously does proper NTSC encoding, so blending of dithering and so on happens automatically without needing a shader, which is nice. EDIT: the NTSC encoding is (obviously, in retrospect) using the RPi's full 720 horizontal res timing rather than a console's native timing, so effects that depend on NTSC artifacting may or may not look like you would expect. For example, here's what the "tvpassfail" NTSC test ROM *should* look like:
NTSC Pass/Fail test ROM with maister's NTSC 256 px shader
But this is what the RPi's composite output actually shows:
NTSC Pass/Fail test ROM via RPi composite output
There's still crosstalk, of course, but it's spread across more pixels, which breaks the test. Perhaps unsurprisingly, it looks closer to the 320 px NTSC shader output:
NTSC Pass/Fail test ROM with maister's 320 px shader
With this new firmware, the RPi3 is now arguably the best/easiest/cheapest way to do proper 240p emulation on a typical NTSC standard-def television. Previously, a softmodded Wii was the undisputed champ in this area, as it was the only way to do 240p without putting a series of adapters and converters in the mix. The Wii still has an advantage insofar as it can output a high-quality YPbPr signal (i.e., comparable to the Analogue Nt shot above) but the RPi3 has the ability to emulate more consoles, including great Playstation 1 emulation via PCSX-ReARMed and decent N64 emulation via the core formerly known as GLupeN64 (now renamed to just Mupen64Plus-libretro). The Pi2SCART add-on from ArcadeForge can get a cleaner, "pixel perfect" output from emulators on the RPi, but at ~$50, it costs significantly more than the RPi itself, costs as much as a used Wii and requires adapters to work with standard NTSC televisions. So, in my opinion, RPi is the way to go for cheap/easy "240p" emulation on a regular ol' U.S. TV, while the Wii is a step up in visual quality but more of a hassle (and fewer games/consoles available to emulate). Pi2SCART wins in both respects but also adds significant cost.

Friday, January 20, 2017

Pixel Art Upscaling Test Image

At the RetroArch/libretro forums, we get a lot of requests for shader previews because there are a lot of them and many people--particularly new users--get overwhelmed and don't know where to even start. So, we've batted around the idea for a while but there were some complications, namely that it's hard to get a good representative preview without managing giant, full-res images, and it's difficult to show of the effects of some shaders while still making the previews directly comparable to one another.

To handle these issues, I decided to make a small test image that contains many of the important features for a retro-focused upscaling algorithm to handle (this is enlarged; it's actually 64x64):
It was a fun exercise trying to pack as many tests as possible into this small canvas. There are two gradients--red-to-green and black-to-white--to test banding, several styles of text, some space invaders to test effects on isolated pixels surrounded by another color, the blended/antialiased doom-guy head, a variety of slopes that go from 1:1 up to 6 pixels of run to a single pixel of rise, the pesky circle-C copyright symbol, some parallel lines and a checkerboard to test de/dithering response/false-positives and a multicolored square that turns into a green-and-beige checkerboard in the presence of NTSC signal modeling, like this:
For the preview repo, I ran the test image through each shader preset at 8x integer scale (or slightly above that for the sharp-antialiased shaders). I don't have previews available for all of the presets yet at the time of this writing, but most of the popular ones are covered. These previews will hopefully make their way into RetroArch at some point, but in the meantime you can browse them at the repo.

Thursday, January 19, 2017

Shaders for Sharpest Pixels

As readers of my blog can probably guess, I usually favor scanline and CRT effects on my retro games but there are a lot of folks who prefer sharp-edged pixels. For many of these folks, integer scaling on the Y-axis and 1:1 pixel aspect ratio (PAR) with nearest neighbor (NN) sampling is gospel, but that can lead to weird display aspect ratios (DAR) on many systems, including S/NES, where the PAR is naturally non-square*. This issue is further exacerbated if you want to run your games at 4:3, which is the nominal aspect ratio of CRT displays and is probably most like what people saw playing retro games in their natural habitat.

If you get away from 1:1 PAR/integer with NN sampling, you end up with a lot of problems caused by uncertainty regarding where in the texel (that is, the texture's pixel) the upscaled pixel is actually coming from. This manifests as "shimmering" during what should be smooth scrolling and ugly, uneven pixel sizes on what should be smooth slopes:
The solution for this is to anti-alias the pixel edges, weighting the resulting pixels against their neighbors, and there are a handful of shaders that do precisely this. For my comparison shots, I've zoomed in much further than I usually do and I'm using an NES shot to accentuate the effects. I also limited the interpolation to the X-axis to make it easier to see the effect.


Originally written by Fes, this is the OG sharp anti-aliasing shader and has been ported everywhere. It takes four texture samples a small distance from the current pixel and averages them together.
Since the averaging is happening in gamma-adjusted colorspace, it favors dark pixels just a bit, so I added a runtime option to the slang port to do the interpolation in linear colorspace instead:
This avoids the darkening but also leads to "floating" pixels sometimes when an upscaled pixel is flanked by light pixels, as occurs behind/below Mario's ear. So, pros and cons /shrug.


jimbo1qaz took another stab at the same concept and wareya added some bits to allow for interpolating in "pseudo-perceptual" colorspace. It ends up being slightly darker than pixellate via gamma curve, surprisingly enough:


Themaister took a different approach with this one. It prescales the image to a desired integer scale (I added a default option to automatically choose the largest integer that would fit on the screen) using NN scaling and then use bilinear scaling to go the rest of the fractional scale factor. In this shader, there's no averaging of multiple samples, so the gamma status doesn't matter. It ends up landing somewhere between AANN and pixellate via gamma curve:
This shader is very lightweight because it only samples the texture once and then leverages the GPU's own scaling hardware, which works essentially for free. Note: this effect is the exact same concept as the "prescale" option that appears in a variety of emulators.

There are a few other shaders worth mentioning that I didn't include here, like Inigo Quilez' "improved texture filtering" (we just call it 'quilez' in the repos), which is significantly sharper than plain bilinear scaling while still providing evenly sized pixels, and aliaspider's scaling swiss army knife, GTU, which can produce a similar anti-aliasing effect when pushed to a very high internal resolution.

These shaders are available in Cg, GLSL/slang and quark/GLSL formats.

*This statement is hilariously contentious and causes some people to flip their shit.

Sunday, January 1, 2017

Tung-Sol KT66 Replace 6L6 for HiFi

Size comparison of Tung-Sol KT66s vs a Svetlana 6L6
I've tried a few different varieties of 6L6 power tubes in my Dared VP-20 amplifier, which has been interesting but not particularly exciting. The preamp tubes makes a bigger impact on the sound, in general, and 6L6s all have the same basic sound signature, which is warm and mild, so swapping among the different brands has been more of a null-finding (i.e., still informative, just not much to write/rave about).

I wanted to try some different families of power tubes but hifi amps tend to be less forgiving than guitar amplifiers when it comes to voltage and power-draw changes, so my options were quite limited. Some guitarists replace 6L6s with KT66s, but KT66s pull 1.3 amps of current, which is roughly half-again as much current as a 6L6. However, while researching the KT66 varieties, I found this article which mentioned that Tung-Sol's KT66 happens to pull 0.9A, just like a 6L6!

According to several places online, the Tung-Sol KT66 is so similar to a 6L6 in performance and characteristics as to be "not a real KT66" or "just a 6L6 in a different bottle." However, I found it to sound significantly different from the Svetlana 6L6s I had in my amp before. The KT66s are much brighter, with crisper highs and punchier lows, at the cost of reduced midrange response.

Once I used my preamp's EQ to crank up the mids to be more balanced, I liked the sound signature of the KT66s better than the 6L6s. Comparatively, I would say the difference is akin to toggling an amplifier's "loudness" button on/off. That is, the frequencies that are accentuated by the KT66 sound more lively and the crisp high-end really made my ears perk up. On the other hand, the sub-bass suffered to the extent that I needed to add my long-dormant subwoofer back into the mix to get audible/tactile sub-bass at reasonable volumes.

So, pros and cons, overall. I'm currently digging the change and having fun listening to my favorite albums with the KT66's different coloration but I'm definitely keeping my 6L6s close by for if/when I want to switch back to their warm, balanced tone.

Some other things to keep in mind if you want to try the Tung-Sol KT66 in the place of 6L6s:
1.) Pin 1 of these tubes is tied to the metal base, so be sure to remove any tube clamps that would come in contact with the base to avoid ruining your tubes and/or amp.

2.) These bottles are big af, and so is the base. The glass is about 2" in diameter, so make sure you have enough space between tube sockets to hold them, and if your sockets are recessed, make sure you either have enough clearance for the base or pick up some 8-pin "socket savers" (available for about $10 for 4x from Chinese sellers on eBay), which is what I did.

By the way, you may notice in my pic above that I also picked up some "tube stabilizers" (aka silicone o-rings), which, for the record, made absolutely zero difference in sound quality. They may do something at very high volumes (i.e., when the tubes are getting physically affected by vibrations), but at normal listening volumes, the rings do nothing. Don't bother.

Monday, September 12, 2016

RetroUSB AVS NES Clone First Impressions

I just received my new AVS FPGA NES clone system from RetroUSB's Bunnyboy. This system differs from NES-on-a-chip hardware clones and RetroN5-style software emulation systems in that it is an FPGA-based hardware emulator. This gives it many of the advantages of a hardware clone (e.g., low latency, direct interaction with carts instead of dumping) with some of the benefits of a software emulator (e.g., firmware updates to add new features, etc.).

I won't rehash the info that's widely available elsewhere and will instead focus on things I haven't seen anyone talking about. But, just to get it out of the way, the graphics are perfect and the sound is just as crisp.

After facing a lot of compatibility issues with my original-run Analogue Nt and my Everdrive N8, the first thing I did was fire up my AVS+N8 to try some of the problematic games, namely Super Mario Bros. 2 USA and Ninja Gaiden 3. Both played just fine and I encountered no unexpected behavior.

Since the AVS doesn't do any expansion audio of its own--it just uses an analog-to-digital converter to pipe the audio from the cart or expansion device into the AVS A/V stream--it sounds as good or as bad as the original audio source. The N8's community mappers for Akumajou Densetsu and Gimmick! sound great, while the FDS expansion audio sounds...not so great.

There is also a screechy, sibilant thing accompanying certain sounds, but I suspect this will go away when I run the day 1 update. Speaking of which, it was harder than I expected to find the stuff needed to actually run the update. I didn't see any way to get them from directly's AVS page, which is where I would expect to find this sort of thing, but this post from NintendoAge has direct links:
and you can sort through all of RetroUSB's downloads here:

To actually update the system, you have to connect the AVS to a computer and run the scoreboard application, which also includes a firmware uploading utility. Unfortunately, the scoreboard application is only available for Windows and Mac, which is a real drag for me, since I don't have either of those handy. Oh well.

Monday, June 13, 2016

Higan Special Chip Images

Higan's bsnes emulator uses low-level emulation (LLE) for the special chips found in some SNES games. Cait Sith's hardware page has dumps of these chips but it can be hard to find the split program/data versions needed for Higan, so here they are.

Saturday, May 14, 2016

Retro Receiver First Impressions

Despite the controversy, I've been very happy with my Analogue Nt and when Analogue announced that they had partnered with 8bitdo to produce the Retro Receiver, I put in an order with Play-Asia on day 1. It took a couple of weeks to arrive and I just received it yesterday, so here are my first impressions:

First off, it works as advertised! The receiver is powered by the NES' controller port, so no batteries or charging are necessary, and I was able to pair an 8bitdo Zero with it just fine (using the basic gamepad pairing mode, which you access by holding the 'start' button). I also tested pairing a Wii remote, which was a smooth, painless process, as well.

Controls are responsive, with no appreciable latency, as far as I could tell (I didn't do any scientific measurements, just operating on subjective "feel"). The automapped turbo buttons work great and are very handy.

The only complaint I had is that, on 8bitdo's pads, the NES' B and A buttons are physically swapped to match the lettering scheme used by 8bitdo (that its, Xbox 360-style, with A on the bottom and B on the right vs. SNES-style, with B on the bottom and A on the right). Correction: this is only an issue on the Zero; the other pads are fine. This is a real drag for games where you have already developed muscle memory and is terrible for Mike Tyson's Punch Out!! because it makes the left-side button do a right-arm punch and vice versa.

However, the Wii remote doesn't have this issue and the B and A buttons are mapped to the 1 and 2 buttons, respectively, as you would expect. Start and Select are mapped to minus and plus, respectively, which seemed backward to me, but that's not as big of a deal as the face buttons and is more easily ignored/adapted-to. With only two face buttons, you lose the turbo buttons, sadly. I had hoped to get around this with the Wii remote's Classic Controller attachment but it doesn't seem to work with the receiver. Update (9/22/16): it should with the latest firmware, I think. I think the Wii U Pro controller is supposed to work with it but I don't have one, so I couldn't test.

The receiver should also work with PS3 pads, but I haven't had a chance to test this yet. I'll update the post when I get around to that. Update (5/15/16): I got a chance to try it but didn't have any luck actually pairing up a DS3 with the receiver. I tried just pairing with the PS3 button, as well as plugging the controller into the receiver's micro-USB port via a USB OTG cable, neither of which worked. If anyone knows the trick, please drop me a comment! Update (9/22/16): ok, no wonder it didn't work: the pairing process is pretty involved. You have to download the pairing utility from here, plug the receiver and your DS3 into your PC or Mac (no Linux client, and it doesn't work via WINE; Note: if you're running Windows 8 or 10, you also need to either disable driver signing temporarily or install the dual shock pairing utility, which is helpfully included with the tools download), run the utility and then use it to pair the pad with the receiver. Whew!

For now, I think the sideways Wii remote provides the best experience (despite the lack of turbo buttons)--or the Wii U Pro controller if its buttons are mapped properly--unless/until 8bitdo provides a way to swap the button mapping on the other pads Zero.

All in all, I think it's a great little accessory that fills an important niche created by Kevtris' HiDefNES HDMI adapter and bunnyboy's upcoming AVS FPGA NES (scheduled for release in late June). Now that we can actually play our carts on our gigantic flat-panel TVs, this receiver lets us sit back on our couches to relax and enjoy it. Update (9/22/16): I got my AVS and the receiver works great with it!

I would also like to echo the comments I've read elsewhere asking for an SNES version. Since NES and SNES use the same controller protocol, this should be a matter of just wrapping the same guts in a different plastic shell. Fingers crossed! Update (9/22/16): My wish came true and they did release an SNES version. The initial firmware that comes with the receiver uses some pretty strange mapping for DS3 pads, so be sure to update it to the latest, which should give a more sane layout. The updated firmware also adds support for Wii Classic Controllers, which is awesome! Strangely, plugging the SNES receiver into an SNES-to-NES adapter *does not work* and jumbles up your inputs. I was hoping to use a single DS3 to control both systems, but no such luck. :(

Analytics Tracking Footer