Category Archives: Hardware

Posts concerning specific hardware issues, products, and tech stuff of a physical nature.

I asked Virgin Mobile USA today if, assuming I bought one from the Google Play Store, I could activate the new Nexus 5, and this is the response I received on Thu, Oct 31, 2013 at 9:44 PM:

Thanks for contacting Virgin Mobile Customer Care.

We want to let you know that is not possible to activate a non-Virgin Mobile phone like an unlocked one because our system only recognizes the unique serial numbers that our phones have. You will need to purchase a Virgin Mobile phone.

You can check our great phones and prices by clicking the link below:

If you need additional assistance, feel free to let us know how we can assist further or contact us at 1-888-322-1122 (or *VM from your handset). You can reach us from Monday to Friday 6am -10pm and Weekends 6am -9pm. As a reminder, please include your Virgin Mobile phone number and PIN on all replies.

This is interesting, because as far as I know, Virgin Mobile actually uses the Sprint network, and Sprint is one of the carriers that will support the Nexus 5.

That’s right, the Nexus 5 will be sold through Sprint and T-Mobile, with only Verizon Wireless opting out of carrying the device. Updated at 3:26 p.m. PT: Google came back and confirmed that AT&T won’t be selling the Nexus 5, but it will be able to run on its network.

So, it looks like I’ll be jumping ship to T-Mobile after nearly two-and-a-half years as a satisfied customer of Virgin Mobile.

This post was originally written in October, 2012, and has been updated twice – first in January, 2013, while using “2012-12-16-wheezy-raspbian” and then again in February, 2014, while using “2014-01-07-wheezy-raspbian” – in all cases using the latest Raspbian release at the time and the latest versions of Emulation Station, RetroArch, and other software mentioned below. So, if you encounter instructions that don’t exactly jive with what you’re seeing, it’s probably because the software continues to change and my instructions have fallen out-of-date. If you get confused, please leave me a comment and I’ll try to help.

After playing around aimlessly a bit with my Raspberry Pi in 2012 (most recently, an install of the very nice RaspBMC), I thought of a useful purpose for it while showing my kids Super Mario Bros. and The Legend of Zelda running on the VirtualNES emulator on my Windows laptop. Before they get too spoiled on the Xbox 360’s graphics and sound, I want to get them some exposure to a few of the simple but influential 8-bit games from my childhood. At the same time, I don’t want my laptop to become the family’s gaming machine. We have a pretty massive TV and plenty of Xbox 360 controllers, so I figured I could throw the Raspberry Pi into the mix and come out with a neat retro gaming console.

Metroid running on my Raspberry Pi

Metroid running on my Raspberry Pi

As with all things Linux, the devil is in the details. Like, can you get the application to work with both video and sound, and are all of the peripherals fully functional? Add to that the uncertainty of the performance of Linux applications on the particular hardware limitations of the Raspberry Pi, and any simple-seeming project quickly develops into a series of hair-pulling and-now-this-doesn’t-work type obstacles. Case in point, a Google search as I began the project in October, 2012, turned up a number of people who had already thought of turning their Raspberry Pi’s into 80’s game console emulators, and it quickly became obvious that this wasn’t going to be a completely painless process.

This post on the Raspberry Pi forum from a few months earlier basically summed it up.

I have a NES emulator working without sound, using the Debian image, will only work running through console no LXDE

sudo apt-get install fceu
cd /usr/games
./fceu -input1 gamepad -inputcfg gamepad1 /home/pi/

Command above will map gamepad buttons to your keyboard, and load game image path you specify. Appears to work fine apart from no sound, I’ve had a few levels on Mario Bros.

Not tried with a joypad, I have a wireless xbox360 joypad that is discovered as a usb device, but have not had chance to try to get it working yet. It doesn’t work by default

Yikes! Emulation with no sound and keyboard-only input is considered a success! And then a reply to that already discouraging post makes the landscape seem even more bleak.

Oh yeah, that’s the one! I tried to use mednafen, but even disabling openGL so it would use SDL for graphics would only give me a blank screen. I’ve tried to find some console emulators that use openGLES but every time I find one, it turns out that it’s only available as a pre-assembled package for platform x.

Well, posts like those from people who certainly seem pretty well informed about console emulation would certainly dissuade most human beings from settling on this as a weekend project. But thankfully for us, plenty of people far smarter than I have been diligently working at converting their Raspberry Pi’s into something resembling a game console, and you and I can now directly benefit from their labor. I’m happy to report that I am getting decently playable NES emulation with sound (and slightly-less-satisfactory SNES emulation) from my Raspberry Pi after a few hours of struggle. And what with how quickly I’m willing to reformat the SD card with a different image (what? an update to RaspBMC?), I thought I should document my steps for posterity.

One of the most frustrating things about doing anything in Linux after living in Windows is that it rarely works as smoothly as you would expect and it takes some patience to get past the hurdles. On top of that, when you turn to Google for help, forum threads typically assume the readers will have more than a passing familiarity with the Linux file structure, command line input, Make files, and the like. Once I eventually track down something that looks like a possible fix, I often find myself searching for help on just exactly how to implement the fix, which advice frequently turns out to be out-of-date and no longer applicable.

So, for those of us who are not going to know how to chmod +x a shell script without some hand-holding, here are the steps I’ve followed so far, that are hopefully detailed enough that you end up with a working RPi game console instead of a smashed bit of PCB and some seething frustration. At times, I assume that you’re still using the ‘pi’ user account, but if you’re not, you’ll probably be able to recognize where you need to substitute your new account. If you can see where I’m definitely doing stuff horribly wrong, please leave a comment and I’ll try to make it better.

Learning a few new tricks here

Learning a few new tricks here

Steps to set up the SD card and configure Raspbian with the necessary software

1. On your main computer (I’ll go out on a limb and assume you’re running Windows here), get the latest release of Rasbian from the Raspberry Pi Downloads page, extract the image file, format your (4 GB or larger) SD card using SD Formatter 4.0 and write the Raspbian disk image to your SD card using win32diskimager. I’ve used win32diskimager successfully more than once, but it will complain at me every time.

Connect the Raspberry Pi to a TV or monitor (I greatly prefer the HDMI out, but the composite output is fine if that’s all you have), connect a USB keyboard (my superstitious nature makes me connect it to the bottom USB port), and connect an Ethernet cable to your router because 1) the Raspberry Pi will need Internet access during setup and 2) your life will be easier if the Raspberry Pi can also talk with a computer on your home network. You can also connect your wired Xbox controller or Xbox 360 Wireless Gaming Receiver dongle thingie now, if you like. Power on the Raspberry Pi and use the spacebar, tab, arrow and enter keys to navigate through the raspi-config utility (it should run automatically at the first boot) to

  1. expand the root partition to fill the SD card
  2. change the internationalization options – language, timezone, and keyboard – as appropriate (this actually is important)
  3. enable the SSH server (in Advanced Options)

Choose finish and reboot the Raspberry Pi by typing the command:

sudo shutdown -r now

And then hitting Enter. Each time I specify a line of input, like the one above, hit the Enter key at the end to execute it.

After the Raspberry Pi restarts, write down its IP address, which is reported in the lines just before the login prompt.

I typically overclock my Raspberry Pi to the Modest setting (800MHz), but I don’t know if this makes any difference, so you can play with this to meet your needs. I run the original Model B board with 256 MB memory, and while it’s sometimes recommended to bump up the memory split to allocate 192 MB to the GPU, it hasn’t been necessary in my experience. If you need to run the raspi-config utility again to change any of these settings, open a terminal (Alt+F1 through Alt+F6) and enter

sudo raspi-config

I recommend against changing the setting that causes the Raspberry Pi to boot straight into the desktop, as the Emulation Station and RetroArch stuff that comes later is best launched from the terminal immediately after logging in (and not from a window within X) and offers something of a GUI anyway.

2. Back on the Windows computer, download PuTTY, which is an application that will allow you to access the command prompt on the RPi (RPi is easier to type, so I’ll be using this shorthand frequently) from your Windows computer across your home network. Launch PuTTY, connect to the RPi using its IP address, and log in (username: pi and password: raspberry). A great thing about accessing the RPi via PuTTY is that you can send command lines to the RPi by copying them from your favorite web browser in Windows and pasting them into the PuTTY window, saving you from typing in lots of unfamiliar and sometimes lengthy Linux commands.

3. In the PuTTY window, get Raspbian up-to-date by updating the package lists from the repositories and retrieving new versions of existing packages with

sudo apt-get update && sudo apt-get upgrade -y

4. Still in the PuTTY window, install GIT, vim, xboxdrv, and other useful software with

sudo apt-get install -y git vim dialog xboxdrv

Then reboot the RPi with

sudo shutdown -r now

5. Because the next part – installing RetroArch, the console emulators, and Emulation Station – takes a long time, I recommend either a) using the USB-connected keyboard on the RPi or b) using the screen command (here’s a good introduction to screen) if you are connecting to the RPi with PuTTY. I mention this because if your PuTTY session drops, the shell in which the commands are running will terminate and interrupt any running process. If this happens, you will have to run the setup script again (but you won’t necessarily know how far along it got before it terminated).

Whichever way you choose to connect, follow the instructions at RetroPie-Setup: An initialization script for RetroArch on the Raspberry Pi to install RetroArch for the Raspberry Pi. I would recommend using the source-code based installation, as it’s unclear how often the binaries are compiled. You can leave the options for installing components at their defaults, but I generally deselect the cores (the console emulators) that I don’t want or that I expect won’t work very well on the RPi. The installation may take hours, but the fewer emulator cores you choose to install, the faster it will go. Reboot at the end of the RetroArch installation.

6. The next step is to copy your ROMs into the appropriate, console-named subdirectory under /home/pi/RetroPie/roms/ on the RPi. There are a few different ways to do this. You can put them on a FAT-32 formatted USB flash drive and then transfer them to the RPi via command line, or you can launch the desktop with startx and drag-and-drop them, but I find that it’s much easier to use WinSCP to copy files from a Windows machine to the RPi across the network. (You can also use WinSCP to copy config files between the Raspberry Pi and your Windows machine, where you can edit them in a more familiar text editor. More on this later.)

Contrary to the advice below, at least for NES ROMs, both the .nes and .NES file extensions are acceptable. But if you’re having problems with ROMs for other systems, you may consider looking at the extensions.

Make sure that the extensions of your roms are lowercase and correspond to those given in /home/pi/.emulationstation/es_systems.cfg. You can show the content of that file with “cat /home/pi/.emulationstation/es_systems.cfg”.

Note: In my experience, if you have chosen not to install most of the emulator cores, you will need to put at least one ROM in at least one console emulator’s ROMs directory in order for Emulation Station to start up successfully. I ran into a problem when I chose not to install any cores except for NES, and then tried to start Emulation Station for the first time before I copied any NES ROMs to the RPi. Instead of the Emulation Station starting up the gamepad configuration wizard, I got only a black screen with a small white dot in the center and spent hours thinking that something was wrong with Raspian/Emulation Station/Retroarch/the RPi itself, etc.

This dot is the “fake” SDL window ES uses to get input. Actual rendering is done through OpenGL ES. If all you see is this dot, then odds are something went wrong initializing the OpenGL ES surface. Are you sure you’re running at least the 192/64mb memory split?

That takes care of the basics. Now you can launch the Emulation Station, which is the front-end we’ll be interacting with, to choose between different game systems and within them, different individual games, by logging into the RPi using the USB keyboard and entering


Emulation Station does not like to be started from an SSH connection. Manually starting Emulation Station each time is optional, as it is possible to launch the Emulation Station automatically at start up, though I use the RPi for a few different things so I don’t actually want this behavior at each boot and just launch it myself if I’m there to play a game.

The first time that you launch Emulation Station, it will guide you through setting up either a keyboard or controller for navigating between the various consoles and launching games. These settings are saved to a config file named es_input.cfg and located in the hidden directory at ~/.emulationstation/es_input.cfg. (Files and directories with names that begin with a dot are hidden, so they won’t show up with a regular ls command, but they will show up if you use ls -a and they are displayed by default in WinSCP.) If you ever want to go through the wizard again to set up a keyboard or controller, delete that file and launch Emulation Station.

If you want to modify es_input.cfg by hand, it’s easy enough to transfer it to your Windows computer using WinSCP and open it in a text editor. One advantage of editing the file is that you can run through the wizard twice – configuring a keyboard the first time and a controller the second – and create two es_input.cfg files that you then splice together in a text editor to create a single file so that you can navigate through Emulation Station by either the keyboard or the controller. This is what my es_input.cfg file looks like, with mostly intuitive controls for the keyboard and an Xbox 360 controller:

<?xml version="1.0"?>
	<inputConfig type="keyboard">
		<input name="a" type="key" id="13" value="1" />
		<input name="b" type="key" id="8" value="1" />
		<input name="down" type="key" id="274" value="1" />
		<input name="left" type="key" id="276" value="1" />
		<input name="menu" type="key" id="303" value="1" />
		<input name="pagedown" type="key" id="281" value="1" />
		<input name="pageup" type="key" id="280" value="1" />
		<input name="right" type="key" id="275" value="1" />
		<input name="select" type="key" id="32" value="1" />
		<input name="up" type="key" id="273" value="1" />
	<inputConfig type="joystick" deviceName="Microsoft X-Box 360 pad">
		<input name="a" type="button" id="0" value="1" />
		<input name="b" type="button" id="1" value="1" />
		<input name="down" type="axis" id="1" value="1" />
		<input name="left" type="axis" id="0" value="-1" />
		<input name="menu" type="button" id="6" value="1" />
		<input name="pagedown" type="button" id="5" value="1" />
		<input name="pageup" type="button" id="4" value="1" />
		<input name="right" type="axis" id="0" value="1" />
		<input name="up" type="axis" id="1" value="-1" />

You can compare the contents of my file to your own in order to get an idea of what buttons are mapped to stuff I’ve never actually used in Emulation Station, like the Page Up and Page Down commands.

Ridley is easy, like this tutorial

Ridley is easy, like this tutorial

Your Raspberry Pi now has all the necessary software to emulate games and accept input from your Xbox 360 controller. It’s now time to…

Configure the controller for games

Once you have those components installed, it’s time for the next step in any Linux project: discover what’s not working. (I have a long, involved tale about the many futile hours I spent trying to map all of the buttons on my old Logitech MX510 mouse, but I digress…)

Back in 2012, a wired (and potentially wireless) Xbox 360 controller wouldn’t automatically work, and unless you were content using the keyboard in games, you wanted to get it working ASAP. You could connect the controller, and you might get the ring of lights to pulse, but you would need to crank up xboxdrv, a userspace driver for Xbox controllers, before you could do anything with it.

As of 2014, Xbox controller support is integrated into Emulation Station and RetroAarch, but if you are curious about how we did it in the good old days, I strongly recommend reading through the list of xboxdrv switches, particularly if something doesn’t work as expected or if you need to figure out why the triggers and analog sticks aren’t mapping.

Even though the controller and the RPi are talking, you need to configure RetroArch to work with it. It is certainly possible to do all the text file editing and copying by using the included Leafpad editor in LXDE, which is the graphical interface on the Raspbian distribution, or in your editor of choice on your Windows computer while transferring the files back and forth with WinSCP, as I normally do, but this is a rather geeky project so I feel that I should at least mention the text-only vim editor that you can run within a terminal, and so I’m going to use it briefly in this case. In the PuTTY window, enter the following code to create a back up copy of the default RetroArch configuration file that is used by all of the console emulators:

cp ~/RetroPie/configs/all/retroarch.cfg ~/RetroPie/configs/all/retroarch.cfg.bak

Then open the live file for editing in vim with:

vim ~/RetroPie/configs/all/retroarch.cfg

I think it’s good to get some idea of the many options within RetroArch, so I really recommend looking through this file, as you may need to come back later and tweak it to resolve problems with sound in games. When you’re done looking around, exit vim without saving the file by typing


Then hit Enter. See, nothing to it.

Back on the USB keyboard attached to the RPi, log in and enter

cd ~/RetroPie/emulators/RetroArch/tools

This puts you in the directory containing the retroarch-joyconfig utility that you’ll use to set up the controller. (If you’re getting an error message about files or directories not being found, you may be using a US keyboard but the RPi is still set to a UK keyboard layout. This would cause the tilde key “~” on the keyboard to enter a logical negation symbol “¬” instead. The tilde in a path in Linux is expanded to be the current user’s home directory, and the logical negation symbol is not. Re-read step 1 for instructions on how to launch the raspi-config utility to change the keyboard layout.)

Launch the retroarch-joyconfig utility with the line:

./retroarch-joyconfig -o p1.cfg -p 1 -j 0

Follow the instructions to push the buttons and move the sticks/triggers/dpad. (The -o switch causes the output to be sent to a file, p1.cfg, otherwise, the output is just echo’d to the screen, which is interesting but doesn’t help us set up RetroArch.) If you mess up, just keep pressing buttons until the utility exits and then start all over again by relaunching the utility with the same command line.

Xbox 360 controller

Xbox 360 controller (click to enlarge)

When you’re satisfied that you have pushed all the right buttons, you should have a p1.cfg file located at ~/RetroPie/emulators/RetroArch/tools. The contents of this file is what will eventually tell RetroArch and each of the various system emulators how to interpret the commands coming from the primary, first controller, but it needs to be appended to the end of that retroarch.cfg file first. To do this, enter:

sudo cat p*.cfg >> ~/RetroPie/configs/all/retroarch.cfg

The end of my retroarch.cfg file looks like this, after I appended the p1.cfg file to it and then further edited it by hand to add some extra commands for exiting the emulator and saving and loading gamestates (one of the best things about playing games on an emulator is that you can save the current state of the game at anytime, and later resume from that point in time, so you don’t need to rely on in-game saves).

input_player1_joypad_index = "0"
input_player1_b_btn = "1"
input_player1_y_btn = "3"
input_player1_select_btn = "6"
input_player1_start_btn = "7"
input_player1_up_axis = "-7"
input_player1_down_axis = "+7"
input_player1_left_axis = "-6"
input_player1_right_axis = "+6"
input_player1_a_btn = "0"
input_player1_x_btn = "2"
input_player1_l_btn = "4"
input_player1_r_btn = "5"
input_player1_l2_axis = "+2"
input_player1_r2_axis = "+5"
input_player1_l3_btn = "9"
input_player1_r3_btn = "10"
input_player1_l_x_plus_axis = "+0"
input_player1_l_x_minus_axis = "-0"
input_player1_l_y_plus_axis = "+1"
input_player1_l_y_minus_axis = "-1"
input_player1_r_x_plus_axis = "+3"
input_player1_r_x_minus_axis = "-3"
input_player1_r_y_plus_axis = "+4"
input_player1_r_y_minus_axis = "-4"

# Hold the back or select button (6) while pressing another button for 
# special actions, like...
input_enable_hotkey_btn = 6

# ...the Xbox Guide button (8) to exit the emulator
input_exit_emulator_btn = 8

# ...the left bumper (4) to save the game state to the current slot
input_save_state_btn = "4"

# ...the right bumper (5) to load the game state from the current slot
input_load_state_btn = "5"

Note to self: I need to update this tutorial with instructions on how to configure multiple controllers.

Each console emulator can have its own retroarch.cfg file that overrides the settings in the default file at ~/RetroPie/configs/all/retroarch.cfg. For the NES emulator, the retroarch.cfg file lives at ~/RetroPie/configs/nes/retroarch.cfg (in a /nes/ directory under /configs/, at the same level as /all/). If you are using an Xbox 360 controller and don’t configure the NES retroarch.cfg file specifically, the B and A buttons will be reversed from the original controller layout, and you’ll have to use the D-pad (which is not great) instead of the left analog stick.

In case you don’t remember the button layout of the NES controller…

NES controller

NES controller (click to enlarge)

So, I would strongly recommend dropping the following file into ~/RetroPie/configs/nes/retroarch.cfg for a better experience.

# All settings made here will override the global settings for the current emulator core

# The original Nintendo controller has the B button on the left and the A button on the right
# which is reverse of the Xbox 360 button layout.  Your ten-year-old self wants you to fix this
input_player1_b_btn = "0"
input_player1_a_btn = "1"

# It would be nice to be able to use the left joystick as well as the D-pad in Nintendo games
# but it seems to be an either-or situation, because only the _axis buttons are honored
input_player1_up_axis = "-1"
input_player1_down_axis = "+1"
input_player1_left_axis = "-0"
input_player1_right_axis = "+0"

Now you should be all set to play NES games using the Xbox 360 controller with pretty intuitive controls. The Xbox 360 controller-to-Nintendo controller mappings are as follows: the left analog stick replaces the D-pad, the A and B buttons are the B and A buttons, the Back button is the Select button, and the Start button is the Start button.

In a hurry to see Mother Brain again

In a hurry to see Mother Brain again

The Super Nintendo controller has four buttons, like the Xbox 360 controller, but the X/Y and A/B buttons are reversed. If you’re going to be emulating SNES, you’ll most likely want to make an SNES-specific retroarch.cfg file for that game system, too.

This is my best-guess for a Super Nintendo retroarch.cfg, without actually having tested it yet.

# All settings made here will override the global settings for the current emulator core

rewind_enable = false

# The Super Nintendo controller's button layouts are the reverse of the Xbox 360 controller
input_player1_b_btn = "0"
input_player1_y_btn = "2"
input_player1_a_btn = "1"
input_player1_x_btn = "3"

# It would be nice to be able to use the left joystick as well as the d-pad in Super Nintendo games
# but it seems to be an either-or situation, because only the _axis buttons are honored
input_player1_up_axis = "-1"
input_player1_down_axis = "+1"
input_player1_left_axis = "-0"
input_player1_right_axis = "+0"

OK. The controllers should now work as expected in games. So…

Get impatient and try playing a game

Assuming you haven’t had any insurmountable problems with the directions above, you should be able to get into a game in a few simple steps:

1. plug everything into the RPi (USB keyboard, HDMI output to TV/monitor, and a wired Xbox 360 controller or Xbox 360 wireless gaming receiver dongle)
2. turn on the Xbox controller (if you need to link the controller with the dongle, you may have to reboot once this has been done before the RPi will see it)
3. power on the RPi (or reboot with sudo shutdown -r now from a terminal) and log in as the ‘pi’ user
4. at the prompt, type emulationstation to launch the Emulation Station front-end
5. use the arrow keys on the keyboard or the left analog stick on the Xbox 360 controller to browse the game systems and ROMs and the Enter key or A button to launch a game system or game.

And you should definitely pat yourself on the back for getting this far.

But your game probably won’t have sound.

Wrestle with the sound

I’m using a pair of headphones plugged into the analog jack, and while many people report that the game’s audio when output through HDMI is generally fine, the audio out through the analog jack was decidedly not fine with the default settings back in October, 2012. The sound would start off fine, but within 20-30 seconds it started becoming increasingly choppy and a few moments later I was ripping off the headphones. I Googled this a ton, and eventually used the options recommended at by uncommenting and/or editing these lines in the retroarch.cfg file. Depending on your experience, you can do so using vim or your text editor via WinSCP:

audio_enable = true
audio_out_rate = 44100
audio_driver = sdl

I had read a bit about ALSA and very little about SDL, but from what I could tell, it boiled down to ALSA (which was in alpha on the Raspberry Pi in late 2012) should be faster than SDL once ALSA is working completely. If ALSA is not working completely or if the RPi is under considerable load, we are better off using something else, and that something else seems to be SDL.

When I rebuilt the RPi in 2014, I still had to modify the audio settings in retroarch.cfg, but I found that ALSA worked fine. The settings I’m currently using are:

# Enable audio.
audio_enable = true

# Audio output samplerate.
audio_out_rate = 44100

# Audio driver backend. Depending on configuration possible candidates are: alsa, pulse, oss, jack, rsound, roar, openal, sdl, xaudio.
audio_driver = alsa

Using these settings also avoids the warning message visible in the console when RetroArch exits while the sound is misconfigured:
RetroArch [WARN] :: Audio rate control was desired, but driver does not support needed features.

If the volume in games is too low, and you are using ALSA, you can increase it at the terminal prompt with the command:

amixer sset PCM,0 90%

I have both an Xbox 360 and my Raspberry Pi hooked up to the same TV via HDMI, and 90% volume on the Raspberry Pi seems to match the volume of the Xbox pretty closely, so that I don’t need to turn the TV up or down when I switch consoles.

So that’s it, you should be able to play those old NES games now, with the glorious, mesmerizing 8-bit sound, but with the far more comfortable Xbox 360 controller.

The Esc key on the keyboard will exit the game and return to the Emulation Station GUI, by default, and if you’ve used my retroarch.cfg file above, you can do this with the controller by holding the Back button and pressing the silver Xbox Guide button.

Great !!

Great !!

What else?

The keyboard is still convenient for saving and loading game states, and I don’t know if all of the functions can be mapped to buttons on the controller (it sounds like it’s not possible), so it stays within reach for now. To enable keyboard shortcuts to save and load save states, uncomment the following lines in retroarch.cfg.

# Saves state.
input_save_state = f2
# Loads state.
input_load_state = f4

# State slots. With slot set to 0, save state name is *.state (or whatever defined on commandline).
# When slot is != 0, path will be $path%d, where %d is slot number.
input_state_slot_increase = f7
input_state_slot_decrease = f6

While playing a game:
F2 – save state to current slot (defaults to slot 0)
F4 – load state from current slot (defaults to slot 0)
F6 – decrease the save slot (defaults to slot 0)
F7 – increase the save slot (defaults to slot 1)

Other useful features can be enabled in retroarch.cfg by uncommenting the lines:

# Mute/unmute audio
input_audio_mute = f9

# Take screenshot
input_screenshot = f8

While playing a game:
F8 – take a screenshot (saved to the ROM’s directory by default, but this is configurable)
F9 – mute audio

The rewind feature in RetroArch is also awesome, and allows to you literally rewind the game – going back in time a few seconds so that you can replay it differently. This comes at a CPU and storage cost, so you may or may not see a performance hit when rewind is enabled. To enable rewind, uncomment the line:

# Enable rewinding. This will take a performance hit when playing, so it is disabled by default.
rewind_enable = true

While in the Emulation Station GUI (such as it is):
Arrow keys – navigate through ROMs and systems (consoles)
Enter – launch the selected ROM
F1 – adjust the settings (including the master volume), restart or shutdown the Raspberry Pi
F4 – terminate Emulation Station and return to the command prompt in the terminal

Recently, themes for each console have been developed for the Emulation Station, which I think everyone who saw it in 2012 would agree really needed a designer’s touch. I would recommend experimenting with the ES Scraper utility, which should download themes for the consoles and boxart for your games automatically.

So that’s that. I’m playing Final Fantasy and Super Mario Bros. 3 for the first time in years, and it’s pretty neat.

Outstanding problems

Some games, or maybe all games that scroll from top to bottom, but certainly Final Fantasy and Dragon Warrior, tend to artifact at the top and bottom of the screen when walking north and south on the world map. I haven’t begun to try to tinker with the video settings in order to alleviate this problem, but I imagine the fix is in there somewhere.

I seemed to be having a problem restoring from save states when I built my first RPi/RetroArch box back in early October, 2012. If I changed to a different emulator (and possibly to another game within the same emulator), I lost the ability to later load from a save state. The load would fail. I could, however, successfully save and load game states as long as I stayed within a single game. It doesn’t seem to be a very common problem, however, as I’ve only found one thread that describes exactly my initial problem, and that was for RetroArch on the PS3: In that thread, the OP pinpoints the problem to changing emulators, after which the save state files cannot be loaded. To my mind, this indicates the problem lies outside the save state files themselves. Resolving this problem was one of the reasons I rebuilt the whole thing from scratch in late January, 2013.

But sadly, my problem was not resolved with the rebuild and in some ways was actually worse after the rebuild. Not only could I neither save nor load states in games with save state files created before the rebuild, but now, instead of the save/load message that is typically output to the screen as yellow letters, I just got a black box (possibly with black letters, rendering the text impossible to read) whenever I triggered a save or load. After I renamed or deleted the old savestate files in the ROM’s directory, I was able to create a new save state without issue and load it.

This was rather disappointing for games that I had been playing for awhile and was relying on the save state, but I guess I can live with starting over.

A possible work around to this problem, for games that support saving in-game, is to use the rewind feature instead of save states to undo mistakes as soon as they happen, and then rely on the in-game saves. For games that don’t support in-game saves, I guess I’m S.O.L. until I get it figured out.

I was having a few problems with xboxdrv and wireless controllers, in the early days. When using the USB Xbox 360 Wireless Gaming Receiver for Windows through a USB hub, approximately 60 seconds after launching xboxdrv, xboxdrv will crash and I’ll get an error stating [ERROR] USBController::on_read_data(): failed to resubmit USB transfer: LIBUSB_ERROR_NO_DEVICE followed by Shutdown complete. This doesn’t happen when using a wired controller or when the USB Xbox 360 Wireless Gaming Receiver for Windows is connected directly to the USB port on the RPi, so maybe a powered USB hub would produce a better experience. I’ve also heard that the Xbox 360 Wireless Gaming Receiver for Windows draws a lot of power, so it may be a good idea to get it working through a powered hub anyway.

I remember her hair differently...

I remember her hair differently…

You can stop reading now. Everything below this point are my notes on how things used to be done.

The manual way of starting up xboxdrv for a single controller is to just run

sudo xboxdrv --trigger-as-button --silent

at the command prompt each time you turn on the RPi, but you could start this up automatically, too. If you don’t run it with sudo, you’ll get an error: USBController::USBController(): libusb_open() failed: LIBUSB_ERROR_ACCESS. The creator’s proposed workaround is to add the current user to the ‘root’ group, which I’m not terribly keen on, so I’d be content with just continuing to run it with sudo. If you want to see your joystick axis and button press information output to the console, just run sudo xboxdrv without the –silent switch, but this eats up some CPU, so use the –silent switch when you’re going to be playing games.

The automatic way of starting up xboxdrv for a single wireless controller is to add the command to /etc/rc.local, which is a file that runs (like a script) at the end of multi-user boot levels (think: before a user logs on). It makes sense to start up xboxdrv automatically, particularly because we want to pass some arguments that would be annoying to type each time. While connected via PuTTY, start by backing up /etc/rc.local with

sudo cp /etc/rc.local /etc/rc.local.bak

Open /etc/rc.local using the vim text editor with

sudo vim /etc/rc.local

Arrow down to the line immediately before exit 0, hit the Esc key, and type or copy and paste

xboxdrv --dpad-as-button --trigger-as-button --wid 0 --led 2 --deadzone 4000 --silent &

then hit Enter, and type

sleep 1

Hit Esc again, type


Then hit Enter to save the changes and exit the editor. Reboot the RPi again, and now you should see that the Xbox 360 driver is up and running even before the login prompt appears. How’s that for awesome?

(The official instructions in the Using a single controller section of the xboxdrv manual at don’t seem to apply to the RPi at this point, as the xpad driver isn’t loaded and the upinput and joydev modules are loaded during boot.)

If you want to be even more slick and automatically start up support for up to 4 controllers, check out

(I initially had some problems with analog joysticks and triggers not registering in the retroarch-joyconfig utility until I started passing the –trigger-as-button switch when launching xboxdrv. However, even when the analog sticks are mapped by retroarch-joyconfig, I don’t have the use of them in NES games like Metroid, and that’s mostly OK by me, except that the dpad on the Xbox 360 controller has always seemed horribly sloppy to me, even in Xbox games. For some reason, the analog joystick movements would be picked up by xboxdrv if I omitted the –trigger-as-button switch, but not by the retroarch-joyconfig utility. The problem with the triggers is that without the –trigger-as-button switch, each trigger pull and release counts as two analog axis movements. This is desired for games where the trigger acts as a brake or gas pedal, but NES and SNES games have little or no use for this. Analog joysticks behave the same way, throwing tons of input at the slightest movement when the NES really just needs to know when it’s been pushed and released. It’s possible to turn the analog sticks off entirely by passing xboxdrv the –dpad-only switch, but what I really want is to accurately control NES games with the far more reliable left analog stick – something I’m still working on.) Update: the workaround for this is to use a NES-specific retroarch.cfg file that maps the left analog stick to the same buttons as the dpad – leaving you without a dpad in NES but with the left-analog stick.

(If you get an error “Couldn’t open joystick #0.”, it probably means that xboxdrv needs to be restarted first.)

I wanted to find the fastest SD card for my Raspberry Pi, or at least one that wasn’t so slow that it was going to cause a bottleneck. There are a few threads on the forums about performance benchmarks. The prevailing opinion on the “SD Card Benchmarks” thread at is that the SanDisk Ultra SDHC 8 GB Class 6 cards have perhaps the best random read/write speeds, which people feel is a good, if theoretical, metric for how the Raspberry Pi will access the card. But at least one Raspberry Pi owner who had done some of the benchmarking that suggested SanDisk Ultra cards would be ideal discovered that the board would not boot from the card.

And there are enough other reports of SanDisk Ultra Class 6 cards not working to convince me to fall back to a regular SDHC Class 4 card.

With so much uncertainty around which cards will work, I’m keeping an eye on the growing list of known-good and known-bad SD cards for the Raspberry Pi at

Of the Class 4 SanDisk Ultra cards, SanDisk Ultra 4GB SDHC Class 4 Flash Memory Card SDSDH-004G-U46 is reported to work, but it requires that the power be disconnected and the card allowed to sit for a minute or two before it will reboot. That may be acceptable for a use case where the Raspberry Pi is sitting on my desk, but not one where it will be tucked behind other equipment.

I happened to be near a Walmart over the weekend, so I stopped in and picked up a SanDisk 4GB SDHC Class 4 Flash Memory Card SDSDB-4096-AW11. I benchmarked it with CrystalDiskMark, and found it to underperform my target of random write speeds of 1 MB/s.

CrystalDiskMark 3.0.1 x64 (C) 2007-2010 hiyohiyo
                           Crystal Dew World :
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

           Sequential Read :    12.281 MB/s
          Sequential Write :    11.721 MB/s
         Random Read 512KB :    12.548 MB/s
        Random Write 512KB :     2.475 MB/s
    Random Read 4KB (QD=1) :     4.713 MB/s [  1150.7 IOPS]
   Random Write 4KB (QD=1) :     0.024 MB/s [     5.9 IOPS]
   Random Read 4KB (QD=32) :     4.977 MB/s [  1215.0 IOPS]
  Random Write 4KB (QD=32) :     0.025 MB/s [     6.2 IOPS]

  Test : 50 MB [H: 0.0% (0.0/3773.5 MB)] (x5)
  Date : 2012/06/01 20:34:28
    OS : Windows 7  SP1 [6.1 Build 7601] (x64)

Assuming it boots and reboots normally, I’ll probably use it until the community settles on a real-world benchmark that run on the Raspberry Pi.

And just for posterity, the proper way to format an SD card and ensure optimal performance is to use the SD Formatter software from the SD Association.

Update 2012/06/13: My multimeter measures 5.11V across the two test points, so the HP TouchPad supply seems fine, and is not delivering too many volts.
Update 2013/01/21: I ordered two more Raspberry Pis, and then wanted to have an identical power supply for each. Because the HP TouchPad power supply is now impossible to find at a decent price, I ordered three 5V USB (1A) wall chargers, part TOL-11456 from SparkFun for $3.95 each. As the Rpi was booting, the voltage across the test points measured, on average, 4.99V for two of the units, with the third unit measuring, on average, 5.05V. So, they seem to be functional but not perfectly identical. However, the USB connection at the charger was very loose, and I tried a few different USB cables that make firm connections with lots of other power supplies and computers, so I’m confident that the problem is with the port on the charger.

My Raspberry Pi was shipped today by element14, but I started researching power supplies last week. A page on titled Raspberry Pi Power Supplies indicates that any cell phone charger capable of providing 0.7A (or 700mA) of current should suffice, but the author recommends choosing a name-brand unit, and preferably one that provides 1A (1000mA). A post on titled “The Boreatton Scouts meet a Raspberry Pi” describes a setup using an “old BlackBerry 700mA charger”, which the Raspberry Pi was fine with until a few USB peripherals were added.

I tend to over-provision, so based on the recommendation to use a 2 amp adapter in this forum thread at titled “Adequate Power Supply Critical to Pi Stability”, I picked up an HP TouchPad Power Charger for $4.99 with free shipping from the HP Home & Home Office Store. (That’s an awesome price, by the way.)

HP TouchPad Power Charger

The HP TouchPad Power Charger

It’s reportedly the same charger that originally shipped with the TouchPad, and it’s a 2.0 amp charger, so it should charge just about anything with a USB port, short of a notebook PC. It comes with a one-year warranty from HP, too. A good number of the reviews on complain that the included USB cable is lousy, but I have a number of short, 24AWG USB cables with ferrite cores from laying around, so no worries there.

The specs

Specs taken from the side of the PSU:

Input: 100-240V~50-60Hz 0.4A
Output: 5.3V-2.0A

Specs taken from the page at HP:

Maximum Output Power: 10 W

My only concern is that the 5.3 Volts exceeds the 5.0 Volts that the Raspberry Pi is designed for, but I’m reasonably assured this won’t be a problem. I have a multimeter, so I’ll be testing the voltage across the test points.


There is a good list of verified peripherals, including a number of known-good power adapters, at the RPi VerifiedPeripherals page at The HP Touchpad supply is listed among the known-good adapters, but it’s referred to as a “5V 2A Charger for HP Touchpad”.

Of course, monoprice has some USB chargers, too, and I’d probably pick up a 2.1A, 4 Port USB Wall Charger as a second choice (assuming it’s not still on backorder).

I’ve been a fan of the simple and effective Windows 7 USB/DVD Download Tool for quite awhile, and have often used it to create a bootable USB flash drive for installing Windows 7.

But I recently ran into a problem with a flash drive after connecting it to my Xbox 360 and using it to move my profile. The Xbox 360 must have made some change to the MBR on the flash drive that the WUDT didn’t like, because it was unable to format the drive.

The WUDT would begin to format the drive, then report:

We were unable to copy your files. Please check your USB device and the selected ISO file and try again.

Windows 7 had no problems formatting the drive, but something was obviously missing from the process.

A quick search in Google turned up the solution. The formatting done by Windows 7 or the WUDT wasn’t cleaning the MBR and partition table.

To thoroughly format the drive so that it can be used by the WUDT, open an elevated command prompt and enter the following commands, using the drive number of the USB drive reported in list disk for the value of select disk #.

list disk
select disk #
create partition primary
select partition 1
format quick fs=fat32

For the curious, here’s a more detailed explanation of the clean command:

Removes any and all partition or volume formatting from the disk with focus. On master boot record (MBR) disks, only the MBR partitioning information and hidden sector information are overwritten. On GUID partition table (GPT) disks, the GPT partitioning information, including the Protective MBR, is overwritten; there is no hidden sector information.

I would expect that the MBR and partition table would need to be cleaned after formatting a drive for booting Mac OS X, too.


I’m in the middle of troubleshooting a printing problem that has arisen with our in-development Windows 7 image. We’re running 64-bit Windows 7 Enterprise with Office 2010 and using the HP Universal Print Driver for Windows PCL6 version 5.4.0 dated 1 Dec 2011 (the current version). The printer driver is installed on a Windows server using default settings and the printer connections on the workstations are created either as per-machine connections by running printui.exe /ga or as per-user connections by running the Find Printers wizard in an Office application. The printers themselves are HP 4250n and HP P4015 models with relatively up-to-date firmware.

The problem is that certain print jobs produce many pages of apparent gibberish instead of the intended file or email message. The gibberish pages begin like this:

                                     @PJL SET JOBATTR="JobAcct9="
                                                                 @PJL SET RET=OFF

I’ve done some research into the lines beginning @PJL, and my understanding is that PJL (Printer Job Language) commands are part of the standard job header output from the Universal Printer Driver, and that when everything is working normally, they are processed by the printer as instructions instead of printed as text.

For more reading about PJL commands, I can recommend the page at:

Almost immediately, I was able to rule out the per-machine connections as being the cause, as the problem also occurred on per-user connections. The same files that printed problematically to the networked HP printers printed normally to locally-installed printers using non-UPD PCL 6 drivers. It seemed logical to pursue this as a driver-related problem.

What is PCL 6

It’s probably worth pausing here for a bit of explanation of PCL 6.

The Enhanced PCL XL or PCL6 driver that is included with the HP LaserJet printers provides enhanced WYSIWYG and enhanced performance with application support over the Standard (PCL5e) driver. PCL XL is a new page description language by HP that is part of PCL6 and is closer to GDI, which many applications use. Less translation takes place by the driver, which means increased WYSIWYG capabilities and better performance with applications that support escapes implemented by the Enhanced driver. The output from the Enhanced (PCL XL) driver may not be the same as the output from the Standard driver. If the output is not as expected, choose the Standard (PCL5e) driver instead.
What is the Enhanced PCL XL or PCL6 Driver?

The part that catches my eye is “better performance with applications that support escapes implemented by the Enhanced driver”. Are we encountering applications that do not support escapes?

Eliminating possible causes

Possible causes of the PJL commands being output as text include the driver not prefixing the PJL statements (at the beginning of each job) with a Universal Exit Language (UEL) escape sequence. (

To rule this out, one can use the “print to file” option in the print dialog box to produce a file that contains the instructions that would be sent to the printer.

Choose File | Print in your application, then check the “Print to file” box in the print dialog box. (In Office 2010, the Print Options button under the available printers menu displays the print dialog box.) Choose a name for the .prn file and save it somewhere, then open the resultant *.prn file in something that displays escape characters, such as Notepad++ (or even Notepad). The first character should be an escape character, and the first line of text will begin something like this:


If the PJL initialization command looks correct, it’s possible that the printer is not properly configured to accept PJL commands. Older printers may not be PJL-aware, but I knew our printers to work fine with older 32-bit HP UPDs installed on our Windows XP machines. The ‘Personality’ attribute on HP printers can be checked by going to the printer’s web admin panel and browsing to Settings | Configure Device | System Setup. Setting the Personality to PS is probably going to cause problems, but either Auto or PCL should work. I confirmed that our printers were set to Auto, further ruling out the printers themselves as the cause of the problem.

I next looked at disabling the advanced features of the driver (a little skeptically, I’ll admit). This can be done by going into the printer’s properties and unchecking the “Enable advanced printing features” box on the Advanced tab. ( I was curious about how this affected the job sent to the printer – would the entire series of JPL commands be removed?

To test, I unchecked the “Enable advanced printing features” and printed an email message to a *.prn file, then checked the box and printed the same email to a second *.prn file, then compared the two files. The only difference in the PJL commands was that “@PJL SET SEPARATORPAGE=OFF” was present with advanced printing features enabled, and absent with advanced printing features disabled.

I found the separator page line to be an interesting difference, as banner pages/separator pages had been suggested as a possible cause, but our drivers were not configured to print separator pages. (

So, that’s where the issue currently stands. I’m waiting to see if turning off advanced printing features has any effect. To be thorough, I need to test whether the UPD PS driver prints without error and whether the problem continues with a printer connected via TCP/IP and with a manually installed driver. I can also bring the printers up to the latest version of the firmware, although this would be a less satisfactory resolution, as we have a variety of printer models and not all of them have firmware updates available.

Update 17 Feb. 2012

The Application event log on the print server contains a number of errors, though we’re unsure of whether there is a direct correlation between the errors and attempts by Windows 7 users to print, or jobs in the spooler being processed, or any other activity.

Faulting application name: PrintIsolationHost.exe, version: 6.1.7600.16385, time stamp: 0x4a5bd3b1
Faulting module name: hpzuiwn7.dll, version: 0.3.7071.0, time stamp: 0x4a5bdfcb
Exception code: 0xc0000005
Fault offset: 0x00000000000d6971
Faulting process id: 0x900
Faulting application start time: 0x01ccea9860e17377
Faulting application path: C:\Windows\system32\PrintIsolationHost.exe
Faulting module path: C:\Windows\system32\spool\DRIVERS\x64\3\hpzuiwn7.dll
Report Id: 3eaa21e6-568c-11e1-b7a4-005056a50027

It certainly does look like the 64-bit HP driver is at fault here. More searching has turned up a number of reports of this error with HP’s UPD PCL6 driver, going back to 2010.

Because we have a small number of Windows 7 users, we’re removing the network printers from the Windows 7 machines temporarily, to see if the server stabilizes.

Update 21 Feb. 2012

We were able to take a closer look at the print server today. We searched the registry for hpzuiwn7.dll and noted the printers that had this DLL listed among the supporting files. Many, but not all, of the printers included this DLL. We also reviewed the printers in Print Management and made an odd discovery. There seemed to be two varieties of the model-specific PCL 6 driver in use: one is named “HP LaserJet 4250 PCL 6” and the other is “HP LaserJet 4250 PCL6“. The difference in the naming is that the later driver has a space between PCL 6. While most of the printers used the UPD, a handful were using one of the model-specific drivers. When we looked at the Additional Drivers, we found that one of them had only the 64-bit version available. I expect that only 32-bit workstations are printing to those printers, so I’m not sure how they even functioned, but it would seem that the next step would be to either add the matching 32-bit drivers for that model printer or change the assigned driver to UPD PCL 6. I suspect that we were not diligent enough about exactly matching the printer driver names (let alone the version numbers) when we were installing drivers on the server.

Update 1 Mar. 2012

After installing the missing 32-bit driver that complemented the stray 64-bit driver, all of the printing problems, including the error messages in the Application log on the server, have subsided.


Network autonegotiation is easily misunderstood. Consider two 10/100Mb devices attached to one another – a PC connected to a router. For each of these devices, it’s possible to configure the connection to use either 1) a fixed speed and duplex or 2) to negotiate the optimal shared speed and duplex with whatever it is connecting to. What is not intuitive is that both devices must be configured with the same settings. The connection will suffer a performance hit, or may not work at all, if the two devices are configured differently.

A common misconception about autonegotiation is that it is possible to manually configure one link partner for 100 Mbps full-duplex and autonegotiate to full-duplex with the other link partner. In fact, an attempt to do this results in a duplex mismatch. This is a consequence of one link partner autonegotiating, not seeing any autonegotiation parameters from the other link partner, and defaulting to half-duplex.

If both devices are configured to autonegotiate speed and duplex, then each will attempt to make the best possible connection among the possibilities they have in common. However, if one of the devices is set to use a fixed speed and duplex and the other device is set to autonegotiate, the autonegotiating device can determine the speed but not the duplex of the other device and so falls back to its default duplex mode. In the case of Cisco switches, the default duplex mode is half-duplex.

…it is possible for a[n autonegotiating] link partner to detect the speed at which the other link partner operates, even though the other link partner is not configured for auto-negotiation. In order to detect the speed, the link partner senses the type of electrical signal that arrives and sees if it is 10 Mb or 100 Mb.

It is not possible to detect the correct duplex mode in the same method that the correct speed can be detected. In this case, the […] port of [the autonegotiating] switch […] is forced to select the default duplex mode. On Catalyst Ethernet ports, the default mode is auto-negotiate. If auto-negotiation fails, the default mode is half-duplex.

Half-duplex as a default duplex mode is not unique to Cisco switches. Below is a link to an article on written by Rich Hernandez, a senior engineer with the Server Networking and Communications Group at Dell, that contains a table summarizing “all possible combinations of speed and duplex settings, both on 10/100/1000-capable switch ports and on NICs.” Included are combinations that would yield no link or link fail conditions, as well as combinations that would yield a duplex mismatch.

The importance of using identical settings on both sides of a network connection is stressed in a KB article from with information on how an autonegotiating port may report that it has established a full-duplex connection with a NIC configured for 100MBs/Full, but in fact is communicating at less than expected capacity.

Only by explicitly setting both sides of the link to the same duplex mode would the link work flawlessly.

Understanding link data errors

The page at the link below contains two tables that explain the various errors and counters logged by a network switch and the possible causes.

Troubleshooting Ethernet Collisions

Collisions may appear to indicate communication problems with a network connection, but as a technote from states, collision counters alone are not indicative of network problems.

…collisions are a way to distribute the traffic load over time by arbitrating access to the shared medium. Collisions are not bad; they are essential to correct Ethernet operation.

There is no set limit for “how many collisions are bad” or a maximum collision rate.

In conclusion, the collisions counter does not provide a very useful statistic to analyze network performance or problems.

Late Collisions

When a collision is detected by a station after it has sent the 512th bit of its frame, it is counted as a late collision.

The station that reports the late collision merely indicates the problem; it is generally not the cause of the problem. Possible causes are usually incorrect cabling or a non-compliant number of hubs in the network. Bad network interface cards (NICs) can also cause late collisions.

I have a Windows XP guest running in VMWare Workstation 7 on a Windows 7 Ultimate host machine. This is working pretty well. The XP guest is nice and responsive. I have only one gripe. I’d like all of the buttons on my Logitech MX510 (the best mouse ever) to be mappable in the guest.

Starting from square one, I decided to try installing the current version of SetPoint in the guest OS. The installation went fine, but the usual functionality of the SetPoint settings utility was absent.

SetPoint Settings in an XP virtual machine

SetPoint Settings in an XP virtual machine

As shown in the screenshot, the SetPoint Settings utility displays only the Tools tab. It is missing the My Mouse tab (and if a keyboard were installed, I presume it would be missing the Keyboard tab, too).

After some Googling around, it appears to be a due to the way VMware approximates the physical mouse. VMware seems to treat USB mice connected to the host as PS/2 devices in the guest. SetPoint, then, doesn’t detect any Logitech hardware that it can configure.

The question of how to obtain SetPoint functionality in virtual machines is one that has been asked many, many times before, without a satisfactory answer. More on that in a little bit.

The best work around

Thankfully, it seems that, at least in the case of a Windows host and a Windows guest, installing SetPoint inside the virtual machine is not necessary. Installing it on the host seems to make all of the functionality available in the guest. This is the solution that I’m implementing now, and it is what I would recommend, provided you have rights to install software on the host.

Paths to follow if you want to pursue installing SetPoint inside a VMware virtual machine

I applaud your courage. There are a few settings that can be tweaked that may get you closer to a working installation.

Possible setting number one

From the post at

Add the following line to the virtual machine’s .vmx file:

mouse.vusb.enable = "TRUE"

From what I can tell, this setting allows me to use the Forward and Back buttons on the mouse, but does not make the mouse detectable by SetPoint. The remaining mouse buttons do nothing.

Possible setting number two

From the post at

The solution given (which did not work for me) is to:

First add the following line to the virtual machine’s .vmx file:

usb.generic.allowHID = "TRUE"

An explanation of what this does, by a VMware associate, can be found in the thread at

If you’re feeling really adventurous and/or desperate, you can take out the mouse.vusb.enable line and add this option instead:

usb.generic.allowHID = “TRUE”

Then, you’ll notice that your main mouse and keyboard (if they are USB) are available to pass through into the guest via the USB devices menu.

The dangerous part here is that once you pass through the mouse, it is actually disconnected from the host, so you won’t be able to ungrab from the guest just by mousing out of the Fusion window. You can still ungrab with the keyboard (ctrl-cmd I believe is the shortcut?). If you actually pass through your keyboard and your mouse, you’ll be stuck in the guest and you’ll have to shut it down (or worse, reboot your physical machine).

This sounded like a great idea, and I was willing to set up a second, PS/2 mouse to control just the host, if necessary. Without connecting a second mouse, I tried passing the Logitech mouse as a USB device to the VM, just as I would an external hard drive, but VMware prevented this, with a warning message:

[Machine Name] – VMware Workstation
Cannot connect “Logitech USB-PS/2 Optical Mouse” to this virtual machine. The host requires this device for input.

The second step would have been to go into Device Manager, click Actions, and then choose “Scan for hardware changes”.

I didn’t get to the second step, as I was too lazy to track down a PS/2 mouse to keep attached to the host, and I still wanted to find a software solution. I suspect, though, that this would be were to begin, were I to need to get SetPoint running in the guest OS.


While I wasn’t able to figure out how to install SetPoint on a guest OS, the workaround of installing SetPoint on the host OS seems to accomplish my goal.

I just picked up an old Dell Precision 690 workstation, which I intend to develop into a file server, a Windows IIS server, and an Ubuntu LAMP server. This monster was built in 2006, but it still has some neat specs and tons of capacity (7 PCI slots, 4 hard drive bays, etc…), should I want to expand further.

Dell Precision 690

Dell Precision 690 Workstation

The main specs

CPU: Dual Core Intel Xeon 5060 3.2GHz, 4M Cache, 1066 MHz FSB
RAM: 2GB DDR2 PC2-5300, CL=5, Fully Buffered, ECC, DDR2-667
HD: SAS Fujitsu MAX3073RC 73GB, 15000 RPM, 16MB Cache
Video: Nvidia Quadro NVS 285 PCI-Express, 128MB

This is not a normal tower

Right away, the size of this thing suggests it isn’t a normal tower. It’s about up to my knee and weights 70 lbs. It feels like it’s made with heavier gauge steel than the typical chassis, but that may be me projecting.

I immediately shopped around for more RAM, obviously. 2GB seems a little thin, even by 2006 standards, when considering the way everything else is high-end. The mainboard has 8 slots and supports up to 32GB, but I figure 6GB is a safe place to start.

The workstation has three enormous fans, like, big-as-your-hand big. Running it with the chassis open causes some sort of thermal protection system to kick in and it spins the fans up to the point that they were blowing stuff on the floor half-way across the room.

The CPU has a big, passive heat sink with six copper pipes and sits between two of those fans. I’m tempted to buy a second CPU, but I’ll hold off.

I’m still on the fence about the SCSI drive. It should be super fast, but I’m a little spoiled by the SSD in my machine at work, so it’s hard to get excited about a mechanical drive, even one running at 15k RPM.

The Nvidia Quadro card is also fanless, and has a bizarre DMS-59 connector. An adapter converts the DMS-59 connector into two DVI outputs.