Saturday, September 3, 2016

Replacing a modded Xbox with a Raspberry Pi, as a classic game emulation station

As you're likely aware, I'm a big fan of using orginal Xboxes modded to allow playing various NES and SNES (and sometimes N64) games.  Xboxes are cheap, and the software that runs on them has a pretty good UX.  That being said, they are getting pretty long in the tooth, and while the finished product is pretty slick, the process of modding them is annoying enough that I pretty much refuse to actually do it.  They are also rather huge and unwieldy in the age of tiny single board computers that are more powerful and draw far less power.

I have a few Pi 3s so I'd figured I give RetroPie a shot.  This will be less of a how to, and more of a review/comparison to modded Xboxes.


What you need

This is probably the biggest draw back of the Pi vs Xbox.  An Xbox can be had for $40 pretty reliably, or probably free from somewhere.  They generally come with everything you need to play, including at least one controller.

The Pi costs $40 by itself.  You then need a power adapter, a HDMI cable, a case, and an SD card.  Then you'll need controllers, 2 SNES knock offs will cost $30, or you can use XBOX360 ones if you want wireless and joysticks, but that'll bump the cost up $70 more.


Name Cost Link
Pi 3 $36 https://smile.amazon.com/dp/B01CD5VC92/
Power $10 https://smile.amazon.com/dp/B00MARDJZ4/
Case $8 https://smile.amazon.com/dp/B01F1PSFY6/
SD Card $10 https://smile.amazon.com/dp/B010Q57T02/
2 Controllers $25 https://smile.amazon.com/dp/B002B9XB0E/
HDMI $6 https://smile.amazon.com/dp/B014I8SSD0/



Total $95

You might have some of this stuff, but I don't think it's fair to assume you do for the price calculations.  So the cost is at least double an Xbox, probably more if you want joysticks.


Install

I won't give a full install guide here, you can follow the official guide easily enough.  However, I will say the install is far easier than an Xbox.  Download the image, write it to the SD card, pop the card in the Pi, attach controllers, and power it on.  It autodetects the controllers, and lets you configure them.  FTP in (u: pi, p: raspberry) and put roms in the ~/RetroPie/roms/* folders.  Restart and the systems where it finds roms will show up in the list.


Config

There isn't much to config, you can pretty much just play out of the box, however, there were some things I wanted to change.  For example, I found the layout of NES buttons to be annoying.  A bit of research told me that while the initial global controller set up is easy, there is no way to edit per system controls without editing the cfg files.  For NES the file is at /opt/retropie/configs/nes/retroarch.cfg

You can SSH into the Pi with ssh pi@192.168.1.125 (change the IP to yours), then cd to there, and use nano to edit that file.  Alternatively, you can FTP the file back and forth. The config is very confusing due to the fact that you have the labels on the controller and in the file which may not match.  The numbers refer to the position of the physical button on your controller.  The letters refer to what that button should do.  For the Buffalo SNES knock offs this was my config for NES:

input_player1_b_btn = 3
input_player1_a_btn = 1
input_player1_y_btn = 2
input_player1_x_btn = 0


Thoughts

I think it works pretty well.  There are some rough edges, but I guess those are mainly a concern for someone like me that wants to configure everything.  All the games I tested work well.  The one exception was N64, where they stuttered quite a bit.  The Xbox was never great at N64 either, but it feels like it did better than the Pi.  Perhaps that's just the few random games I tested, or maybe because the Pi doesn't actually have a video card.

Also there is no easy way to turn the Pi on and off, you just unplug it.  For what it's worth, I measured the Pi as using about 2 watts (compared to the Xbox at about 50 w), so leaving it turned on 24/7 isn't a bad idea.

I was kind of disappointed at how poor N64 performance was.  If that were better I'd spend the money for a set of wireless controllers and be quite happy.  Each release of the Pi see a pretty significant speed bump, but at the same time I don't know if that is going to actually help, I think it's more the software and lack of video card.

Saturday, June 18, 2016

Flash the BIOS

Prelude

Some years ago-never mind how long precisely-having little money in my purse, and nothing particular to interest me on shore, I thought I would set about to fix a friend's computer.  I can't recall what was actually wrong with it, but at some point, I figured I might try to flash the BIOS for no real reason.  The long story short is I used the wrong BIOS file and ruined the computer.

Since then "Flashing the BIOS" has become an inside joke.  That being said, I've learned a lot of lessons over the years, and would not make the same mistakes today.  As an example, let me regale you with this tale:

A New Router


I recently moved, and my best internet option here was xfinitywifi which is broadcast in the area.  However, I needed to be able to connect any device to that without going through their web portal, and be able to hook up wired devices.  Simple enough, I bought a router, and installed DD-WRT on it.  There was the potential for bricking the router, but I did my research and found a version of DD-WRT with numerous confirmed successful installs on the internet.

The install went fine, and as an added bonus, the antennas on my router picked up the xfinitywifi signal much better than my laptop.

Premonitions


All was well in the world.  But then my internet started going down.  It turns out my router would lock up and crash, and need to be restarted.  This seemed to be happening with increasing frequency.  The solution seemed obvious.  I bought a 120 V relay and wired it to a Raspberry Pi.  I then wrote some code to ping some sites to see if the internet was still up, and if not, to restart the router.  This was an iterative process, as I discovered the router would sometimes allow pings to IPs (like google's DNS 8.8.8.8), even in its frozen state.  I also noted that pings to the router would occasionally still work, even when the router refused to serve the status page.  So I changed the script to check the status page via wget.

This worked pretty well.  I set it up to run every 30 seconds, and to restart the router as soon as it couldn't get the status page.

Discontentment


Searching online though, it seemed like no one else was having this problem.  I figured this may just be because I was using the less common repeater mode, but it may have also been because I was using an older release of DD-WRT, since I wanted to find one with plenty of confirmation it wouldn't brick the router.  I found one or two people who said they were running the latest version on that router so I decided to upgrade the firmware to the newest version.

I carefully found the correct file, and plugged directly into the network so there was no chance of being disconnected during the update.  When I figured I was ready, I hit upgrade.  As soon as I clicked the button I realized my mistake.  My router was still hooked up to my crazy Raspberry Pi contraption.  Within the next 30 seconds the Pi would try to get the router status page, fail, and then cut the power to the router.

There was nothing I could do.  Pulling the plug on the Pi would cut the power to the relay and cause it to open.  My only chance was to SSH into the Pi and kill the process.  That, of course, relied on the network being up.  As soon I hit enter on the SSH command I heard the click of the relay turning off.

And with that, my router was bricked.

I tried a few recovery methods I found online, but it didn't matter.  My router had a half installed firmware, there was no way for it to boot, so it looped endlessly.

Excursion


While connecting directly to xfinitywifi gave me some internet, it was unreliable and I wanted to get this resolved.  I convinced myself just to get a new router, one that would hopefully not have the freezing problem.  Walmart was the only place that was open so I found that they carried the Netgear Nighthawk router and set off to buy it.  I arrived at 12:01 am to discover that the Walmart I was at closed at midnight.  I drove to another Walmart to discover they didn't have any in stock (despite their site claiming they did).  I bought a lesser router, figuring it might be better than nothing.

A New Hope


When I got home I thought more about what to do with the broken router.  I, of course, considered switching out the guts, but I didn't have any of the packaging, and knew I couldn't just put the old router in a new box since the serials wouldn't match.

I did more research and discovered two more advanced recovery methods.   The first involved setting up a TFTP server, and connecting directly to the router, with a static IP that it would check for a certain file and then flash itself with.  I set this all up, and as luck would have it, it got the file from my computer and started to flash itself.  Then it rebooted, and rebooted.  I guess it didn't have enough firmware written to get through the firmware update steps before it rebooted.

A New Hope, Part 2


The more involved method, as these things so often do, required opening the router and soldering some pins onto the board.  While my new apartment is pretty barren, one thing it does not have a dearth of is random electrical components.  I had pin headers, male to female jumpers, even a USB to UART breakout board.  It was about 3 am at this point, which seemed like the ideal time to begin the next phase of this project.

I opened the router, found the through-holes, broke off three headers and placed them in the correct holes.  Hooked up Rx, Tx, and Ground to my UART, plugged that into my laptop, and attempted to connect via PuTTY, and got nothing.  It was pretty odd as I was sure the connections were right.  I have done USB serial communication stuff before though, and I know it's very easy to get the connection details wrong.  That being said, usually that would result in gibberish, not nothing.  After much experimentation I noted I could sometimes get gibberish if I moved the connections around.  This led me to believe perhaps the connections actually needed to be soldered, and not just placed there.

At this point, I feel it's worth noting that while I have a nice large table in my living room, I only get internet via my laptop in my bedroom.  I did buy a large corner desk for my room, but have yet to assemble yet, despite sitting around in my apartment every day with nothing to do.  As such, all this work was being done with me in bed with the parts in bed with me.


Dawn


It was about 4am when I turned on the soldering iron (which I did do in the living room, not in bed).  I soldered the headers on, and as is tradition, discovered I soldered it wrong, so had to unsolder everything and redo it.  I hooked everything up, and still got nothing.  I suspected my router had so little firmware on it, that it couldn't even communicate over serial.  I checked and rechecked the connections, but there were only 3 wires.  Ground to ground, Rx to Rx, and Tx to Tx.  Then I realized, how could Rx connect to Rx?  Both sides can't be receiving.  Sure enough, the directions I was following clearly stated Rx to Tx.  At 4:45 am I fliped the Tx and Rx wires and immediately got communication.  As I said, I've done this USB serial communication before, and I made this same exact mistake before.

Flashing the firmware was a few simple commands, it grabbed the file from my TFTP server, via ethernet, and rebooted.  It worked fine.  I figured I might as well reflash it with the DD-WRT firmware while it was in this disassembled state.  That was done in a few minutes, and the router was reassembled (with pin header conveniently left soldered on for future endeavors) by about 5:15 am.  Just in time to watch the sun rise while browsing reddit.

Monday, May 16, 2016

Dean Karnazes: the man who can run for ever

http://www.theguardian.com/lifeandstyle/the-running-blog/2013/aug/30/dean-karnazes-man-run-forever
When running, you break down glucose for energy, producing lactate as a byproduct and an additional source of fuel that can also be converted back into energy. However, when you exceed your lactate threshold, your body is no longer able to convert the lactate as rapidly as it is being produced, leading to a buildup of acidity in the muscles. It is your body's way of telling you when to stop – but Karnazes never receives such signals.

"To be honest, what eventually happens is that I get sleepy. I've run through three nights without sleep and the third night of sleepless running was a bit psychotic. I actually experienced bouts of 'sleep running', where I was falling asleep while in motion, and I just willed myself to keep going."

Monday, April 4, 2016

Will minimum wage hikes lead to a huge boost in automation? Only if we're lucky.

http://www.vox.com/2016/4/2/11348148/minimum-wage-robots
What about the workers thrown out of jobs by the new robo-waiters? Many would get new jobs, though the way this would work is often ignored.
  • Most restaurants would keep longer hours (they're paying for the rent and the robots anyway), meaning many workers would get a raise and change shifts.
  • The advanced robo-restaurant technology would itself be a valuable American export good, and people would be employed in designing and selling it.
  • Some low-wage work would be reallocated out of the relatively low-social-value restaurant sector and into things like child care and home health assistance, for which there is ample demand.
  • Since poor people are now making more money, there will be opportunities to sell them things — things like restaurant meals! — that they couldn't previously afford, which in turn creates demand for new jobs.

Thursday, March 31, 2016