Monday, April 2, 2018

Epic 4G CM10.1

I have a bucket full of old Epic 4Gs, the Sprint variant of the Samsung Galaxy S which was also the last mass-produced phone with a good physical keyboard, but it has become very difficult to find software to load on them. Newer builds of LineageOS don't support it and it's pretty much impossible to find old versions of Cyanogen Mod that will run on it. On top of that, it's just too weak of a phone for any newer OSes, though it still has plenty of potential value as an audio player / digital camera / IM machine (thanks to the physical keyboard!) / child's beater phone.

Luckily, I found a cache of old CM10.1 (Ice Cream Sandwich, IIRC) plus G-apps software on one of my old phones that I still use as a digital camera at work, so I figured I'd post it here in case anyone else wants to breathe some life into their old trash-phone. It should flash onto any Epic 4G just fine with Heimdall/Odin. Download link.

Thursday, December 14, 2017

FrankenTurntable and Speaker Upgrades

I've been helping a friend of mine with his stereo recently and it got me energized to do some work on my own. First of all, I decided to finish a long-term project of mine that's been on hold since my daughter was born: assembling a turntable out of myriad spare parts, most of which I already had lying around.
The platter and mechanism came from a frustratingly crappy direct-drive linear-tracking turntable that I rescued from the trash. I bypassed all of the control circuitry and wired the power directly to the motor, so it only turns at 33 1/3 RPMs (i.e., no 45s for me), but it seems to be pretty solid and consistent at that, at least. I'm interested in trying some different platter materials at some point, but I doubt the motor has enough torque to handle anything much heavier than the one it came with.

The tonearm comes from a Technics SL-1950. I bought this one used off of eBay for about $50. I mounted it to some spare blocks of wood I had lying around and purchased some long, skinny nuts and bolts that I used to raise it to the appropriate height for the platter and get it leveled properly. I also used the wood to sandwich some female RCA jacks that I spliced onto the tonearm's own wires so that I could hook it up to my preamp using standard RCA cables (the yellow jack is the ground line).

It sounds really good and, despite looking ghetto af, it has a nice, post-apocalyptic DIY charm that that appeals to me. More importantly, though, this raw setup provides a direct line from the tonearm to the preamp/amplifier without any of the circuitry in the way that can lead to signal degradation in many more user-friendly turntables (like my LP-120 before I modded it for a direct connection, as well).

If you'd like to hear the output, it's the turntable I used to make the recordings for my cartridge comparison post.

Next up, I've been giving my Dared VP-20 tube amp a rest lately and am instead using a Lepai LP-2020TI tripath amplifier I purchased from Parts Express. It seems Lepai is no longer producing the original model, the LP-2020A+, which is a shame since it was so well-loved among audio enthusiasts, but they are making what is essentially a clone using a more easily sourced chipset (it pumps out a few extra watts, too, which is nice). It has the same clean, low-distortion sound as the original (as long as you keep the volume dial below about 11 o'clock, just like the original...) and, as much as I like my tube amp, the Lepai provides a clear accuracy that can be a refreshing change of pace from the folksy warmth of the tubes.

Finally, I overhauled my backloaded horns--which I originally fitted with some cheap but adequate drivers from MCM Electronics--with some really nice Tang-Band full-range drivers. Since the MCM drivers are only good to about 4 kHz, I had them set up on a 3-way crossover with some Bohlender Graebener Neo8 midranges. It sounded good, but I've always heard that full-range drivers running uncrossed sound more "realistic" than 2-/3-way setups.

So, I hooked the Tang-Bands up uncrossed with the ribbon tweeters wired in parallel (the Lepai can push the combined 4-ohm load just fine), and sure enough: they sound a lot brighter and more even than the crossed 3-way setup, likely due to the Tang-Band's hump above 15 kHz combined with the natural lack of sensitivity mismatching.

The Tang-Bands are supposed to be good down to 60 Hz, but they were barely usable down to probably 80-100 Hz or so (I suspect the chambers in my horn boxes just aren't large enough for the rated performance), so I definitely need my 15" subwoofer in the mix now (my old 3-way setup benefited from it, as well, but it wasn't strictly necessary). Likewise, the ribbon tweeters are supposed to be on high-pass filters for safety, but I'm pushing such a light load through them that I'm pretty sure they'll be okay.

Phono Cartridge Comparison: At95e vs Ortofon Omega

I recently assembled a franken-turntable from bits and pieces I salvaged from other systems, but one of the pieces I needed to complete it is a new cartridge. I already had an At95e from Audio Technica, which is well known and well regarded among turntable aficionados as a solid budget cartridge, so I thought I would mix it up a bit and purchase another favorite from the budget realm, the Ortofon Omega. Both of these cartridges are available for around $35-40, so I figured it would be a good, fair fight. Reviews online tend to refer to the Omega as "warmer" than the At95e, which is known as a "sterile" but "accurate" performer.

Audio Technica's At95e
For testing, I took two short recordings with each cartridge from the 'tape monitor' output of my preamp, which sends a full-output signal (i.e., bypassing all of the volume and EQ from the preamp aside from applying the Redbook boost to the phono stage) directly into the audio input of my Lenovo Thinkpad laptop. I used Steely Dan's Showbiz Kids (track 1 from side B of the first disc of Steely Dan's Greatest Hits double LP) and Dr. Dre's Nothin But a G Thang (coincidentally also track 1 from side B of the first disc of The Chronic 180g vinyl remaster). I didn't do any EQ/processing/declicking, just removed the dead space at the beginning and normalized both tracks to -1 dB because the At95e put out a slightly louder signal and we typically think louder things sound subjectively better.

The Ortofon Omega
You can download my test recordings here. (Note: these recordings are short and only include the intros of the songs, and I believe them to be covered by Fair Use). I did my testing using the Lacinato ABX audio testing software, which is free to use, listening via Audio Technica ATH-M50 closed-back headphones.

If you wish to remain impartial, please do your listening/testing before reading any further.

Ok, so first off, the results are extremely close. I think anyone would be very happy with either of these cartridges for the prices they typically go for. In simple, unblinded A/B testing, I feel like I was able to hear a consistent difference between them, mostly in the vocal midrange. The At95e sounds a little roomier while the Omega sounds very tight. Whether one would consider either to be better than the other probably depends on the words I use to describe them (e.g., roomy vs loose/sloppy, tight vs constricted). I honestly don't think I prefer one over the other, it's just a slightly different character.

In proper blinded ABX testing, that all fell apart and I wasn't able to reliably tell them apart. I did about a half-dozen comparisons and my best accuracy rate was around 67%, but more often I hovered around 50% and my confidence was always quite low.

So, there you have it. Both are good budget cartridges with no major differences as far as I could tell. I noticed no difference between them in "warmth" or "accuracy," whatever that means. You should probably take reviews claiming otherwise (e.g., suggesting one or the other is better for this or that kind of music, etc.) with a grain of salt. Feel free to leave a comment with your own ABX results.

Monday, October 30, 2017

N64 VI Filter

The N64's RDP chip includes a Video Interface (VI) stage that prepares the video for the final output. From the N64 Programming Manual:
The video interface reads the data out of the framebuffer in main memory and generates the composite, S-video, and RGB signals. The video interface also performs the second pass of the antialias algorithm. The video interface works in either NTSC or PAL mode, and can display 15- or 24-bit color pixels, with or without filtering, at both high and low resolutions. The video interface can also scale up a smaller image to fill the screen.
These functions can make a very big impact on the final image of an N64 game, and the ParaLLEl-N64 libretro core exposes the ability to toggle the postprocessing effects of this stage on and off. Turning it off nets you a few frames per second of speed but also gives us a peek behind the VI curtain:
So, you can see that the filter just barely touches the HUD elements but it does some pretty dramatic stuff to the rest of the image. It applies strong antialiasing to the outside edges of objects, which has a big, noticeable effect (so noticeable, you can see it in the thumbnail images) on Mario's hat and the silhouette of the tree, and it does some blurring that smooths out the dithering that is very visible in the unfiltered shot. On actual hardware, the blurring can be toggled off in some games (Quake II, for example, IIRC) or using Gameshark codes. I believe consoles modded with UltraHDMI or etim's N64RGB boards can also switch it off through the boards' firmwares.

Wednesday, October 25, 2017

Using RetroArch via Snappy

I've been working with some folks on trying to get a snap package up and running for RetroArch to go with our FlatPak and AppImage universal linux packages, and it's turned out to be more complicated than I expected to navigate the particulars of the packaging format combined with the restrictions of the security sandboxing.

We announced the package a couple of weeks ago but quickly got reports that users couldn't load files, they were confused as to why the package took a long time to load (only on the first launch, but they didn't know that), and more. Since updating my laptop to Ubuntu 17.10, I decided to "dogfood" the snap package, since that would be the only way I could get in front of the reports and ensure a good experience.

Since RetroArch requires a lot of stuff to look nice and function properly, we use a wrapper script that checks for the existence of that stuff and, if it's not where we expect it, it copies the stuff into the snap's user directory. Since that copying can take a long time, I decided to use notify-send to include some admittedly uninformative notices just to let the user know that nothing is frozen/broken and that we're just copying stuff in the background. The catch here is that you can't use the system's notify-send, you have to include it in the snap as a runtime dependency, under the "stage-packages" in the snapcraft.yaml recipe, like this. I tried adding an icon to make the notifications prettier and more obviously RetroArch-related, but I could never get it to actually see the icon, no matter where I stored it, so I gave up on that.

Ok, so the notifications were a nice little improvement, but we still couldn't actually get to any files to launch them, which makes the program pretty useless. For that, we needed to add the "home" plug to the recipe, like this. This plug is supposed to be auto-connected, so you shouldn't need to do anything to make it accessible to your application once it's in the recipe. However, RetroArch's non-native file-browsing meant that it tried to start in /, which is inaccessible (and in fact, totally invisible) to the snap (and if your snap starts you in an inaccessible directory, you can't ever get out of it), so I added a line to my wrapper that pre-populates the user's retroarch.cfg config file with a line telling it to start in the home directory, where we should have access. I tried using $HOME and ~/, both of which just sent me to the snap's home directory instead of the true home directory with all the files -_-. The solution I found--which is pretty crummy but whatever--is to use a relative path that points to one level above the snap package. That is, ~/../../../

Similarly, I couldn't reach my network shares, which I mount in /media (despite adding any plug that seemed even vaguely related to such a thing to the recipe), so I had to move my mount points into my true home directory and use those same relative paths to everything, e.g. ~/../../../smbshare/Emulation/BIOS for my 'system' directory. Once the mount point is in my true home directory, I could probably put symlinks into the snap package, as well, to avoid the silly relative paths.

The last major issue I ran into was that the *.desktop launcher that shows up when you search for programs in the sidebar kept complaining about not having an "exec" line and then failing to launch because of it. This one was super-confusing because our snap has a *.desktop file (it lives in $SNAP/meta/gui), and that file definitely has an exec line. It turns out that, during installation, snapd generates the *.desktop file that the OS actually looks for and stores it in /var/lib/snapd/desktop/applications. This file is based on the *.desktop included with your program, but if the exec line isn't just like it expects, it will strip it out entirely and not give you any indication of why. Initially, our *.desktop file pointed the exec line to the retroarch.wrapper script that does so much work for us, but snapd didn't like this and rejected it until we switched it to just "Exec=retroarch", which isn't the name of the actual executable but rather the name of the snap itself. It still launched the wrapper script, since that's what our recipe points to, so we're all set.

Since we need to use our script when we launch from a command line, as well, we made sure to end it with $*, but this has a couple of problems that experienced scriptors will spot immediately. First, it's not escaped, so any spaces in file names will break it. Second, it will only accept a single argument, which isn't going to work for us. So, I changed it to "$@" and all is well.

Now, the only issues left that I know of are: 1.) the wrapper script has our nice invader icon, which shows in the sidebar while the script is running, but once it dies off, the icon goes with it and the actual program just has an ugly question-mark/no-icon-found icon in the sidebar and 2.) the snap can't load any dynamic libraries that live outside of its domain, so I can't conveniently compile a test core and then launch from command line to test it with the -L switch. #1 isn't a big deal and #2 probably isn't possible to fix, so it is what it is.

Saturday, October 21, 2017

Running Graphical Programs as Root in Wayland

Fix for Invalid MIT-MAGIC-COOKIE-1 keyCannot open display error when trying to use sudo.

I just updated to Ubuntu 17.04 (and it's a great release; I was on 16.04 LTS before and it's well-worth the update) and noticed that I kept getting the above error when I tried to elevate my privs to edit system files with a graphical text editor (typically gedit, but I've switched to pluma). That's a result of improved security measures in Wayland that we didn't have to worry about with the now-abandoned Unity desktop used in previous releases.

Most of the solutions floating around for this error refer to X sessions (usually X-forwarding over SSH) and don't actually do anything to correct the Wayland issue. However, I came across this solution, which worked a treat:

Step 1.) Create a new local directory to house a custom executable:
mkdir ~/.local/bin/
Step 2.) Next, we'll make a little script that will elevate the privileges for us when invoked (the OP called it 'wsudo', which seems like a good choice to me):
nano ~/.local/bin/wsudo
Step 3.) Paste in these contents:
#small script to enable root access to x-windows systems
xhost +SI:localuser:root
sudo $1
#disable root access after application terminates
xhost -SI:localuser:root
#print access status to allow verification that root access was removed
Step 4.) Make the script executable:
chmod +x ~/.local/bin/wsudo
Step 5.) Temporarily add our local script directory to our Path for easy access:
export PATH=$PATH:~/.local/bin
Now, you can take it for a spin and make sure it works as expected (by running, for example, wsudo gedit /testfile and making sure it saves okay). If everything is in order...

Step 6.) Permanently add our local script directory to our Path:
echo "export PATH=$PATH:~/.local/bin" >> ~/.bashrc
That's it. Now you should be able to invoke wsudo any time you need to run a GUI program with elevated privs.

Sunday, September 24, 2017

Padhacking a Terrible Genesis 6-button Controller

I recently got a model 1 Sega Genesis and an Everdrive MD and have been playing a lot of the great shmups and arcade ports. The standard 3-button pads are not great, period, but they're especially crummy for those sorts of games (Street Fighter is basically impossible), so I figured I'd seek out some 6-button pads.

Legit 6-button pads from Sega are quite nice, but they're getting more expensive these days (like everything retro, amirite?), so I decided to check out some of the cheap knockoffs. The cheapest ones I could find were going for $8 for 2 pads on eBay and, while I expected them to be shitty, they're worse than I ever imagined:
The Fighting Putt 6B packaging. Both pads I received looked as if they'd been sat upon.
The buttons are so loose I was worried they would fall right out of the cheap plastic casing. The controllers themselves weigh almost nothing and their cord is a measly 3 feet long. The funniest quirk, IMO, is that they only used 4 screws to connect the housing instead of the 5 Sega used, but they put in a fake plastic screw just to keep up appearances:
Very clever, guys. Nobody suspects a thing.
Between the laughably short cord and the awful buttons, I decided to check out the PCB to see if it might be worth putting into an arcade stick (I already have a PS360+ multi-console board, which covers every console I care about except the Genesis/MD, so this would be useful). It turns out that the PCB is actually really great for this purpose, with a common-ground design and nice, big soldering pads for each input:
Here's a shot with wires soldered onto the pads:
And here's one with the solder joints smothered in hot glue for long-term stability:
I hooked it into an existing stick I had lying around and everything works perfectly. After the price of an extension cable, I'm still looking at sub-$10, so not too bad. I wouldn't recommend the Fighting Putt 6Bs for general use, but they're great for padhacking.

Analytics Tracking Footer