Friday, October 3, 2014

My Super Punch Out!! Arcade Cabinet

I just came into possession of an arcade cabinet. It's a genuine Nintendo Super Punch-Out!! cabinet from 1984 (i.e., almost as old as me).

Here it is, in its new (temporary) home on my covered back patio:
 The marquee is in good condition with just a few scratches and the speakers are still intact, surprisingly. The monitors look pretty terrible in that shot, but don't worry: that's not burn-in, just dirt and cigarette tar scuzz. The paint/vinyl on the sides has some cracking/chipping at the bottom and there's significant warping to the first few layers of plywood on top, but otherwise, it's pretty much intact, if dirty. Here's a shot of the inside, full of leaves:
 After applying equal parts rubbing alcohol and elbow grease, I got the dirt scum off the monitors to reveal some light-to-moderate burn-in on both monitors.
 But really, it's not so bad considering this old gal had nearly 50,000 games played on her, according to the analog counter inside (that's more than $10k in quarters; pretty good ROI!):
 The cabinet also came with a piece of smoked plexi that goes in front of the monitors (not pictured in the first image), and this plexi was covered with the same dirt/tar scum that coated the monitors, so it needed a deep-cleaning, as well. During the process, I took a before/after shot to illustrate how thick and nasty that stuff really was (ignore the basset hound on the floor fishing for belly-rubs):
Between the coating on the monitors and the coating on the plexi, I doubt anyone would have been able to tell whether it were turned on or not.

I haven't had a chance to get inside and poke around yet, but I plan to check the monitors' capacitors to see if they've leaked and/or dried out, which would necessitate recapping them, and I intend to pull the actual game boards and see if they've suffered any corrosion from on-board batteries. If all is well there, I'll try to actually plug it in--which will require attaching a new plug to the currently-bare wire-ends--and see if the transformer and power supply are still functional. I will also take apart and clean the coin doors, since they're a little janky, as well.

I'll update this post as I learn more :)

I opened it up and was pleased to find that the batteries didn't seem to be terribly corroded:
I fitted a new plug onto the end of the bare wires, threw in some fresh batteries and powered it on. Everything seems to fire up okay, though there's not a lot of action:
At this point, I'm not sure if have a dicky connection to the board, a dead board or wiped eproms (their UV windows are uncovered and it's pretty bright inside my cabinet, due to the missing control panel). I know a guy who has an identical machine--in much better condition--who has offered to test the board for me, so that will be my next step, I think. In the meantime, I'll continue sprucing things up cosmetically.

I drove my board out to test it in the aforementioned known-working cabinet and the results were less-than-great but better-than-bad:
The picture is blurry and there's a lot of glare on the plexi, but what you're looking at is some garbled graphics (no movement and no sound, unfortunately) and one perfectly-rendered '0'. This suggests to me that the board basically works--that is, it's not totally dead--but my eproms indeed need to be verified and my cabinet needs some more work to get even this far. I also need to go through and check all of my edge connectors and make sure the solder joints are secure and, if not, reflow them.

For the eproms, I'm hoping to borrow a USB programmer from a computer engineering professor at the university where I work. If that doesn't pan out, I can get one on eBay for $40.

It was looking like getting SPO!! working was going to be more involved and expensive than I was really hoping to get into, and I didn't want to risk ruining a board that could actually make a collector very happy, so I traded the boards and cabinet to a really swell collector named Marv for this dandy of a JAMMA cabinet:
This is actually much more appropriate for my uses, since I can drop JAMMA boards in with ease (I intend to purchase a SF2: Hyper Fighting CPS-1 board in the near future) and, with the help of a J-PAC board, drop a MAME PC in with little-to-no modification. I'll be posting about this process soon.

Friday, August 22, 2014

Tomee SNES Retro Controller Review

I've been re-acquiring some old gaming consoles lately and it seems official SNES controllers are getting pretty expensive these days, commanding $15-20 at the time of this writing. I already had one official controller but wanted to get a second controller on the offhand chance anyone wanted to play a 2-player game. I wasn't too keen on paying the full price for an official one, so figured I'd try out the Tomee SNES controllers, which are super-cheap and readily available (i.e., no eBay; I got a 2-pack for ~$7 on Amazon).
To be clear: at a price of $3.50 each, these controllers are totally worth the money. They're functional and have a look and feel that's reminiscent of the official SNES controllers. I plugged them up and was able to play games just fine.

However, the plastic feels a bit flimsy and the d-pad is shaped a bit differently from the official Nintendo controller's (it's significantly fatter than the Nintendo version; Nintendo on top, Tomee below):
The four face buttons are also slightly different size and sit taller, though that's a pretty minor issue, IMO (Tomee on the left, official Nintendo on the right; the pic's blurry because my camera kept focusing on my hand instead of the controllers...):
The L/R buttons are significantly sharper-edged and clickier, though they rarely get used in games anyway, so it's also not a big deal. Perhaps more important is the fact that the Tomee controllers are thicker/fatter and don't taper the way Nintendo controllers do, which messes with the overall feel and ergonomics quite a bit (official Nintendo on the left, Tomee on the right):
The start/select buttons are much mushier than the official controller's and they're extremely prone to getting wedged under the controller face, which is more annoying than detrimental. Both of my d-pads also have an odd quirk whereby pressing down-left with a bit too much force will trigger all directions simultaneously. This can have some pretty hilarious results in games that weren't programmed to expect it, lol.

Overall, I think these controllers are a great value for someone who wants to do some casual playing or, in my case, just wants a second controller on-hand for the rare occasion that a friend/guest wants to throw down on some multiplayer action. If you're serious about your gaming, though, you'll want to have an official controller, which is more reliable, more comfortable and built to last.

If you're planning to use an SNES-to-USB adapter to use a real controller with an emulator, I suggest looking instead at the Buffalo Classic USB Gamepad, the price of which varies from around $12-20. This controller feels significantly more solid than the Tomee and actually feels extremely similar to a new official Nintendo SNES controller in weight and button-feel. Here's a (shitty) picture of mine next to one of the Tomees for comparison:

Thursday, August 21, 2014

HTC One M7 Purple Camera Problem

The camera is one of the main reasons I purchased an HTC One (M7), with its awesome low-light performance, so I was really bummed when my pictures started getting a weird purple tint around the edges. The problem got progressively worse, to the point that the camera was essentially unusable:
So, I did some digging online and, while my case is abnormally serious, the purple picture problem seems to be a common issue for HTC Ones that were manufactured early on in their product run (I preordered mine and got it right at launch). No one is exactly sure what causes the problem, but people suspect it's related to heat, either in the phone itself or specifically at the "ultrapixel" camera sensor. Either way, replacing the camera module supposedly fixes it, and there have been reports of individuals sending their phones in for other warranty issues and getting them back with newer camera modules, whether they reported purple pics or not.

In my case, I went down to the local Sprint affiliate and inquired about a camera replacement. The tech started an insurance report and found that 'camera takes purple pictures' was one of the pre-defined claims, so he was able to order a refurbished phone for me on the spot at no cost (not even an insurance deductible!). A couple days later, I received my new phone and its camera works as well as I remembered. I'll update this post if it starts showing the same issues.

Friday, July 18, 2014

CRT-Royale and 3dfx Shaders

Two fairly new shaders have popped up that are worth mentioning: TroggleMonkey's CRT-Royale and leilei's 3dfx. They're both available in Cg format in libretro's common-shaders github repo, though CRT-Royale utilizes some advanced features that aren't available in RetroArch v1.0.0.2 (the most recent release at the time of this writing).

CRT-Royale is particularly exciting for me because TroggleMonkey managed to overcome some issues with shadow-mask emulation that I thought were totally intractable at current common resolutions (i.e., 1080p). The result is some really great phosphor emulation at reasonable scale factors, along with all of the bells and whistles users have come to expect from CRT shaders, including "halation"/glow, bob-deinterlacing support and curvature, along with a ton of options that are unique to this shader.

I'm not going to cover many of them here because it would take forever to get screenshots and there's not much point when TroggleMonkey has included a very informative README with the code, along with support for RetroArch's new runtime parameter support (so you can see the effect of your changes in real-time). However, I thought the shadow mask stuff was super-cool and deserved some closeups. Here's a shot of the shader with default settings (as always, click to embiggen):

First, we'll look at my favorite effect, the in-line shadow mask (called slot-mask in the code):
This is the same configuration I was shooting for with my PhosphorLUT shader, and you can see that the configuration of the phosphors has that familiar vertical, staggered orientation:
Next, we have the very similar aperture grille:
The main difference between this and the in-line slot mask is that it doesn't have the slight staggering (only really visible in the closeups and at super-huge resolutions). In closeup of the LUT, you can see that it just removes the crossbars between triads:
Last, we have the dot-triad shadow mask (called "shadow-mask-EDP" in the code), which was common on CRT computer monitors:
 As you can see, it looks very similar to the high-res shots I took of my Compaq CRT monitor (from my emulation/TV post). And here's the dot-triad blown up:

The other shader I wanted to show is leilei's 3dfx shader, which tries to mimic the effects of a 3dfx GPU, known for some distinctive dithering among other things. In addition to obvious applications like RetroArch's Quake core, Nintendo's N64 also used a GPU that was very similar to a 3dfx, which makes it appropriate for RA's Mupen64plus core. When run at low-ish internal resolutions and paired with RetroArch's per-texture 3-point filtering, you can get a pretty good approximation of what N64s looked like.

Here are some shots of the shader at 320x240 and 640x480 (i.e., native and double res, respectively):
Native res:
Double internal res:
 As you can see, the doubled res looks significantly sharper, but the scanlines are thinner and less pronounced (and twice as many of them) relative to the native res. I also like native res because it makes HUD/menu items look a little less "pasted-on":
Native res:
Doubled internal res:

Friday, June 20, 2014

True Hq2x Shader Comparison With xBR

I was shocked to learn recently that the shader I and others have long called Hq2x is/was actually a misnamed port of another shader entirely! guest.r originally put out a 2.0 scale shader with a suffix "HqFilter," which stands for a part of the color blending code. Over time, this shader was ported to a million different emulators (including the official Metal Slug PC releases) and, at some point, the name got confused with another popular emulation upscaling algorithm, Hq2x. As CPU filters have been supplanted over time with GPU shaders, no one seemed to notice that no true shader port of the classic Hqnx algorithm--in any scale--existed in any language. EDIT: looks like there was an attempt to port it back in 2005 but it never caught on because it was incomplete and had some bugs, but it's something.

Fast-forward to a few weeks ago, when a shader programmer named Armada brought this up in RetroArch's IRC channel. He shared some pics of the "Hq4x" shader in the common-shaders repo (which itself was based on the old XML shader in bsnes' gitorious repo, which in turn was based on guest.r's ePSXe shader) and an identical pic taken using a CPU-filter version of Hq4x. The differences were obvious and indisputable:
I started digging through old forum posts and it turns out that several people had noticed this over the years, but no one ever posted any comparison pics or were able to backup their suspicion in any way.

Armada and I did find that there was an old DOSBox renderer called OpenGL-Hq that was at least a step in the right direction, being a hardware-accelerated implementation of the Hqnx algorithm, and it was helpful insofar as it demonstrated how the algorithm can use an external lookup texture for the detection. However, it was not particularly applicable to modern shader language, so Armada set out to port directly from the CPU filter's C implementation.

After some intense work, which included creating a program to generate the LUTs that Hqnx bases its calculations on, Armada completed his shader port (also copied into the common-shaders repo) and it works beautifully! Incidentally, the requirement for LUTs means that a true Hqnx port wasn't even possible until fairly recently, as SSNES/RetroArch is/was the first emulator (that I know of, at least) to support LUTs in shaders.

Comparison Shots
If you've read over my previous comparison of Hyllian's xBR vs Hqnx, xBR won by a landslide in pretty much every comparison, which is no surprise because it wasn't really an apples-to-apples comparison. That in mind, here are updated pics that show a true comparison between the two algorithms (2xBR shader first, Hq2x shader right after and Hq2x CPU filter third):

The first thing you'll notice in those Super Mario World shots is that Hq2x does a great job of killing the jaggies. Much better, in fact, than ScaleHQ from the other comparison, and almost as good as xBR. There are a couple of rough edges (Yoshi's nose is a good example), but Hq2x is also *very* fast, so reasonable tradeoffs here. Hq2x does completely ignore the light texture blobs in the ground, leaving them as hard-edged rectangles, while xBR turns them into ovals. You can also see some slight lingering differences between the Hq2x CPU filter and the Hq2x shader, where the shader actually does a significantly better job of handling various detections.

On these digitized shots from Earthworm Jim 1 and 2, though, the comparison sort of falls apart. xBR is able to spot the jaggies and smooth them out while Hq2x doesn't spot any patterns at all, due to them being outside of its LUT's detection matrix.

It's also worth looking at how the algorithms differ in handling text. For this comparison, I included the two extremes of xBR's corner detection, with the 'a' variant as the most rounded and the 'c' variant as the most square:

In this comparison, Hq2x is essentially indistinguishable from xBR's 'c' variant, insofar as the text is concerned. The xBR 'a' variant is of course substantially more bubbly, which may be desirable for some games.

My previous comparison wasn't really a fair fight, and I apologize to Mr. Steppin for misrepresenting his algorithm. This is a much better comparison of the algorithms, and in ideal conditions, Hq2x is almost identical to xBR in smoothing while running much faster. However, in other cases--particularly digitized artwork--limitations in Hq2x's pattern detection can leave some images completely unsmoothed.

The speed of Hq2x makes it attractive for certain use-cases, such as mobile, where performance is still of the utmost importance and xBR either doesn't hit full speed at all or else drains your battery. xBR, on the other hand, can handle a greater variety of images and is more likely to produce a pleasing image with the digitized artwork that became more common in the PSX era.

Analytics Tracking Footer