Upgrading your 3DS SD card, your 3DS, or both

Once more the time has come to update my seemingly rather popular guide to upgrading your Nintendo 3DS SD card (previously here). This time, I’m going to cover several scenarios – upgrading your SD (or SDHC) card to another SD (or SDHC) card, upgrading your SD/SDHC card to a 64GB or larger SDXC card, and upgrading your 3DS to a New 3DS, transferring everything to a MicroSD/SDXC. EDITED 11/02/15 to clarify some points in Section 3

Firstly, some information:

Nintendo’s published method for transferring data from SD card to SD card mostly works, but some stuff sometimes doesn’t make the transfer, or does but is inaccessible. For example, sometimes photos are missing, or you lose your play coins or streetpasses. My method (Section 1, below) transfers and retains access to the lot.

Also, Nintendo only officially support SDHC cards of up to 32GB in capacity, but in fact SDXC cards work too. The main incompatibility is not with the cards themselves, but with the partition format SDXC cards use – by default, exFAT, or sometimes NTFS. Neither of these can be read by a 3DS.

Thankfully, 64GB and 128GB SDXC cards can still be formatted to 3DS-usable FAT32 format. Unfortunately, Windows 7 (and 8) has made this difficult to do by not including the option on the standard disk formatting utility.

So, if you want to use a larger than 32GB card, then follow the steps below (in Section 2) carefully before transferring your 3DS data.

In addition, Nintendo also have a guide for migrating all your games, saves, data, software licences and NNID from one 3DS to another. This works fine, but there’s a faster way if you have a lot of data and have a New 3DS which only takes a Micro SD (or Micro SDHC, or Micro SDXC) card rather than a full size one. That’s Section 3, below.

Continue reading »

How to set up a Linux lab with no Linux machines

So when you’re told that you might have 30-odd students that need access to Linux for some course they’re doing, and you don’t have any spare machines and don’t want to dual boot with Windows on a computer suite and you don’t have time to do that anyway, what do you do?

Well, one solution is what we’ve done: A Linux virtual machine running on a Hyper-V server, with “child” virtual machines, each accessible from a Windows machine.

Specific for this purpose, Linux will not need a GUI. Everything the students need to use is via the command line, and they also don’t need networking or internet access. I also wanted everything to be as secure as possible, both on the Windows client and Hyper-V server, without giving students unnecessary elevated privileges. Continue reading »

I made a game (with no zombies in it)

SnapShot_140619_145437It’s not a very good game. In fact, the only “game” element is trying to collect all the items more quickly than before. It’s also a mutation of the example Phaser HTML5 game, although much is rewritten or modified.

It’s also not very good. I think I said that.

But! It shows how easy it is to make a HTML5 game with Phaser. Making a good game though? Bit trickier, and not really something Phaser can help with.

Anyway, you can play it here. The controls are the arrow keys, OR! If you have a Wii U, you can play it on the web browser there using the dpad! Amazing (but not very good).

I’m especially proud of the wrong way I’ve done a timer, which means that depending on your computer or browser, it runs at a different speed, making comparing times with others completely impossible. Just as well, since there’s no leaderboard either.

Switching audio output between jack and HDMI on RetroPie

RetroPie is a great multi-emulator project for the Raspberry Pi, but I noticed that its auto-detect for which audio device to use seems a bit erratic. I’ve speakers plugged into the 3.5mm jack, as the HDMI cable runs to a speaker-less monitor, and usually (but not always) RetroPie defaulted to squirting sound out the HDMI port.

There’s two ways of fixing this. Firstly, you can change the audio output for the current session (i.e. until you reboot it) by issuing this command to force the output to the 3.5mm jack:

amixer cset numid=3 1

or this command to force it down the HDMI cable:

amixer cset numid=3 2

To run this command, either switch to another terminal session (e.g. Ctrl-Alt-F2), and log in as user pi, password raspberry (defaults, unless you’ve changed them), then Ctrl-Alt-F1 to switch back to the GUI.

Alternatively, from another machine, you can SSH into your Pi and run the command in the shell there.

To make this a permanent change, you need to run RetroPie-Setup. Get into a terminal using either of the above two methods (Ctrl-Alt-F2 or SSH) and enter:

cd RetroPie-Setup
sudo ./retropie_setup.sh

This will bring up the config screen. Choose option 8, “Configure audio settings”.


Then choose either Headphones (for the 3.5mm jack) or HDMI as necessary.


Choose OK, then reboot!


Finally! The version of RSG you’ve been waiting for!

Many, many, many years ago, I wrote a terrible text based roleplaying game called RSG. I initially made a version for the Sinclair Spectrum, but lost the code soon afterwards. Then I wrote a version for the Acorn A4000 in BBC Basic instead of doing my A level computing project. Then a version for the Casio programmable calculator when I’d finished a physics exam. At some point I also made a version in AMOS on the Amiga, and eventually rewrote it for the Spectrum for the 1999 comp.sys.sinclair Crap Games Competition.

Since then, I’ve made a version (that didn’t work) in Flash, a version in Perl, and I even got part way through a port on the original Game Boy, until I ditched it and wrote Advanced Lawnmower Simulator for that instead.

But now! With the soon to be released Gamebuino, I’ve been learning Processing (again, I sort of learnt it a few years ago, but forgot it all again). And here is the fruit – a Processing written RSG. In a tiny, tiny little box. Why a tiny box? That’s the resolution of the Gamebuino!

Yes. Yes, that is it in that little box there. Click on it and begin the greatest of all diminutive adventures!

Fixing “Not enough free space” error when deploying Windows image

After creating a new install of Windows 7, with all the software on I wanted, I then tried to use our Windows Deployment Services Server to capture the image. However, it failed using both methods we’d used previously.

When booting to Windows PE over the network, choosing all our usual capture options, and then triggering the capture, an error message came up – “not enough free space”. This seemed odd, as there was a good 60GB free on the local machine, and over 1TB free on the server I was going to save the captured image on.

I tried the other capture method, which is booting the machine into Windows then triggering the capture from there. Files were copied to the local machine, and it then rebooted into WinPE and started capturing. Unfortunately, this failed too with numerous errors, the main one being 80004004, but also 80070070 and 80004005.


Here’s what was happening:

When WinPE starts a capture, it copies some files to the local machine’s main system partition (usually drive C:). However, it couldn’t do this as it said the drive was full. C: wasn’t full, though.

The fault is actually that WinPE tries to copy to the first active partition on the drive, which logic suggests would be C:. But Windows 7 creates a 100MB, usually hidden, “System Reserved” partition. 100MB isn’t enough for WinPE to do its thing, so you get the error message.

Similarly, Windows 8 and 8.1 have a (larger, but still too small) System Reserved partition, and some preinstalled Windows PCs may have other backup, boot, recovery or system partitions too. WinPE can’t cope with these if they’re marked as active.

The solution then, is to mark C: as active. You can do this by booting the install of Windows, going into Disk Management, and right-clicking C:, then choosing Mark as Active.


There’s an alternative fix which may also work. It’s listed here, but as a fix for Windows 8 when using MDT 2012. We’re using Windows 7 on an older MDT, but it still applies.

This fix involves creating a Boot folder on C:, so that the capture script uses that rather than try to create a new one on the wrong partition.

What you need to do is find the LTIApply.wsf file in the Scripts folder on your deployment server’s deployment share. About a fifth of the way down there’s this section:

' Copy bootmgr
If not oFSO.FileExists(oEnvironment.Item("DestinationLogicalDrive") & "\Bootmgr") then
oLogging.CreateEntry "Copying " & oEnvironment.Item("DeployRoot") & "\Boot\" & sArchitecture & "\bootmgr to " & oEnvironment.Item("DestinationLogicalDrive") & "\bootmgr", LogTypeInfo
oFSO.CopyFile oEnvironment.Item("DeployRoot") & "\Boot\" & sArchitecture & "\bootmgr", oEnvironment.Item("DestinationLogicalDrive") & "\", true
End if

Immediately after this, but before the “Copy the PE boot image” line, enter this code:

If not oFSO.FolderExists(sBootDrive & "\Boot") then
oFSO.CreateFolder(sBootDrive & "\Boot")
End if

Everything now works for us, so one, or both, of these fixes should be applied in the same situation.