But wait, there’s more! If you don’t have the hardware and don’t want to build it, or you want to try out OpenLase, or you want to be able to mess around with it on the go, you can now do that. There’s a new OpenGL-based simulator in the OpenLase tree. It works off of the JACK data (so you still need JACK) and it tries to simulate the dynamics of my laser scanner, including brightness effects and some of the physical limitations of the galvos. Here’s a comparison of the simulator vs. the real thing:

I’m aware that documentation on the software is still sorely lacking. Please bear with me while I get my act together and write that up

First of all, as I’m sure everyone knows by now, I’ve been working on hacking the Kinect and writing open drivers for it. There’s a website for the community and a Git repo with the code, and it’s working fairly nicely by now.

With that out of the way, here’s a project that I’ve been working on on-and-off for the past year or so. I’ve been interested in laser scanning and DIY laser projectors, but I couldn’t find any good open source software to drive them. Specifically, I was interested in the realtime aspect: rendering and showing dynamically generated images and responding to events, not just making and preprocessing laser shows. So I set out to write my own set of software to do real-time rendering. This was the result:

DIY laser projectors commonly use sound cards as DACs. This shifts most of the processing over to the PC, but also lets us get very fine control over the realtime aspects of projection, which is what I want. Thus, my laser projector is based on a bog-standard USB soundcard, modified to pass DC. I’ll probably write a detailed article on the hardware later, but suffice it to say that it’s a galvo kit, a hacked chinese laser pointer, my own laser driver and monitoring circuitry, and some other minor parts. Total cost is about €200, if you play your cards right.

Since we’re converting laser images to audio data, why not just treat the laser data as audio in the first place? After all, laser samples are audio-rate data, and 16-bit multichannel 48kHz fits the requirements for laser projection very well. So that is what I did. OpenLase isn’t really a monolithic framework. Instead, it’s a series of stand-alone applications and chunks built on the excellent JACK audio connection kit, which serves to pipe realtime laser data around the different bits.

On a typical setup, you’d have two processes running on top of JACK. On one hand, there’s the output processor, which is responsible for formatting the idealized laser data to suit the peculiarities of the hardware. This includes things like brightness scaling, the obvious X/Y inversion settings, the final output perspective transform (to fit the screen), and minor filters to try to compensate for hardware imperfections. It also generates a 1kHz square wave on one channel – this is a peculiar safety feature of my laser hardware. I have a microcontroller monitoring this signal, such that if the software hangs or crashes for some reason, the laser shuts down immediately (to avoid having a static dot which would be a serious eye hazard). The OpenLase output processor has a simple Qt GUI that lets you tweak these settings on the fly.

On the other hand, you have whatever picture source you want to use. You can have bare JACK applications, such as two examples: ‘circlescope‘, a circular oscilloscope that takes realtime audio data from a media player, and ‘playilda‘, a bare-bones ILDA file player (ILDA / .ild is the standard file format for laser graphics). The circlescope is particularly good for showing off the real-time aspect (note that the input can come from the laser DAC’s line-in with only the small JACK buffering delay):

However, the other big part of OpenLase is libol, a realtime rendering library loosely modeled on OpenGL which lets you produce 2D and 3D graphics on the fly. This is what I used for the LASE demo above. The demo itself isn’t currently open source (and the code is utterly horrid – I wrote half of it at Euskal Encounter and finished it mere minutes before the deadline), but if there’s demand I might open source it too, just please don’t expect pretty code! However, keep in mind that most features used by the demo (text rendering, 3D, “shaders”, ILDA file loading, etc.) were implemented as part of libol, so you aren’t missing out on much. There are two libol-based examples: some rotating cubes, and Pong.

There’s one part of the demo made it into the OpenLase distribution as a separate example: tools/trace.c. This used to be some tracing code that I used for the metaballs and fire effects (I kind of cheated there, as those are rendered as bitmaps and then traced in realtime into laser vectors). It’s a terribly naive algorithm (check the source out for details), but it worked surprisingly well for certain kinds of video, so I hacked it and tacked on more heuristics in order to attempt to make it work better. It now lives next to tools/playvid.c, which is a simple video player using libavcodec. Here’s what it looks like (improved version (mkv), original YouTube video). More complex videos are hit and miss, but some things turn out surprisingly well for such a silly algorithm.

You can also add filters between the output and the image generator. This is what I did for my Kinect + OpenCV + OpenLase demo, which projects anything projectable by OpenLase onto a moving screen, with a dynamic perspective transform (in this case the perspective transform happens in the filter, not in the output processor). That code currently doesn’t even build with current libfreenect, but again, if someone is interested, drop me a line and I’ll make it work again and publish it.

OpenLase doesn’t have any facilities to patch together these JACK apps. Instead, you should just use existing JACK tools, such as QJackCtl, to connect all the input and output ports together. QJackCtl has a patchbay feature that automagically connects the ports when applications start up, so it’s quite seamless.

Right now there is pretty much no documentation, but I’d like to know if people are interested. If you have (or want to build) this kind of DIY hardware, you run Linux or some other UNIX that can run JACK, and you’re interested in hacking on the code or using it for something, please let me know! Here’s the git repo.

Update: Three more videos, musically themed. A laser visualization of MIDI data (MIDI to laser):

And the other way around, a laser harp (laser to MIDI):

Obligatory demo video:


AsbestOS (a mineral, and meaning “inextinguishable” in Greek) is a bootloader to run PS3 Linux without OtherOS. It runs using the USB GameOS exploit (on PS3 version 3.41) from any compatible device, and any reprogrammable devices currently running the PS3 exploit can be used as long as they have enough free internal or external storage (40kB or so) to hold the loader. It is general enough that it should be useful to boot Linux given any other GameOS exploit in the future. It has been tested to work on the PS3 Slim too.

Currently, it only supports netbooting a kernel and no initrd (mostly due to bootmem limitations). This is enough to run a Linux system booting from an NFS share or from USB storage media. Almost everything that works under OtherOS is working. As additional perks of running as GameOS, you also get access to a seventh SPE (needs a kernel patch to enable) and there is clearly full access to the RSX including 3D support, although we still need to learn a few details about how that works to be able to use it.

AsbestOS is a fully independent open source payload and does not contain any code from the original PSJailbreak payload or derivatives. It is licensed under the GPLv2. Compiling it does not require any SDK tools, and it includes a script to build a fully vanilla GNU toolchain for the PS3.

If you’re interested, check out the git repository. The README file contains information on how to run AsbestOS and how to set up kernels. Currently, ports exist for software USB AVRs (Arduino etc.), iPods, and the reference implementation for devices with a TI OMAP3, but anything currently running PSGroove or similar can be adapted with only a few lines of new code.

For the impatient or lazy folks, here’s a kernel that you can use Update: and a stage1 binary and a stage2 binary. You’ll probably want to change the kernel commandline options to set up your NFS root partition. This will eventually be handled by AsbestOS, but for now, open it up in a hex editor, search for HEXEDIT_THIS, and change the commandline to suit your needs (without changing the total length, of course). Do note that this kernel does not have built-in USB support, so it can only be used for NFS booting (the USB stuff is built as a module).

You can use this filesystem as a starting point. It’s a Gentoo stage3 updated to date and with PS3-specific tools installed. Keep in mind that there’s no Portage tree included, so be sure to either emerge --sync or NFS mount your server’s Portage tree (which is what I do). At the very minimum, you’ll want to edit the following files to configure your NFS and networking settings (or to specify USB device partitions, if you want to go that route – but you need to compile your own kernel then): /etc/fstab, /etc/hosts, /etc/resolv.conf, and quite likely a few others. This filesystem includes kernel modules for the above kernel. The root password is ‘ps3′.

I certainly wanted to use a feature that I paid for, so I started investigating the BIOS and here’s what I found out.

Update: There’s a 1.21 BIOS floating around that seems to have VT enabled natively. See below.

Under the hood

The InsydeH2O BIOS is no ordinary old-style BIOS. Instead, it’s based around the UEFI platform. This goes way beyond the old BIOS paradigm and turns system firmware into practically its own separate OS, that even runs in full 64-bit mode on 64-bit machines. Unfortunately, they make no effort to expose any of this to the user. The firmware has support for booting EFI executables, there’s an EFI shell, there’s an EFI boot manager… but I haven’t been able to figure out how to access any of this.

If you want to reverse engineer EFI stuff, downloading TianoCore’s EDK2 is a must. It contains source code for a lot of Intel’s framework, which is what most vendors use as a base for their EFI support. A lot of the code is exactly the same as what’s in the Insyde BIOS (read the spec here).

As for the Setup tool, it does indeed have a huge Advanced menu with even more options than your average desktop. There’s also a hidden Power menu. EFI defines a “form browser” protocol and formats for user input, which is what Insyde uses for their setup utility (spec here). I found these tables when disassembling the Setup binary and wrote a little dump utility to turn them into text. The result is a complete dump of the Setup hierarchy, including the Advanced menu, which also includes the offsets in the non-volatile storage corresponding to each setting. Insyde stores this configuration blob into an EFI variable named Setup. Here’s my dump: the first part is the hierarchy, while at the end I added a rough auto-calculated mapping from configuration offsets to setting names (grep for [0xOFFSET in the top section for better context - the format is [0xOFFSET<FIELD_WIDTH>] for all references to the storage blob). You’ll find the tools I used here, if you’re interested, but they’re rough and need quite a bit of manual help too.

I wasn’t able to find out how to enable the hidden menus, other than that their form Subclass is 5 instead of 0 (but I haven’t found what, if anything, checks for this and whether its behavior can be altered). However, manually enabling VT support in the Setup variable is easy enough, now that we have the offset of the VT Enable byte.

Enabling Intel VT

The easiest way to enable the setting as far as I can see is to dump out the entire BIOS, patch the setting into the Setup variable (which is part of the data storage section – we aren’t modifying any actual BIOS code, as this is the equivalent of changing a CMOS setting on other BIOSes), and then flash the resulting image. These laptops use a weird flash-behind-EC hardware solution for which there is no open flasher, so instead we can just use the normal BIOS flashing tool. In short, we’ll flash the existing BIOS back on, but in the process also modify a Setup setting.

FAIR WARNING: This might apply to other similar laptops, or it might not. It might work, it might do nothing, or it might brick your expensive laptop. Even if you own an Aspire 8930G, I take no responsiblity if your laptop dies, turns into an expensive brick, melts into a pool of slag, blows up, flicks you off, develops self-awareness, or becomes Skynet. You have been warned. I have only tested this on an Aspire 8930G with BIOS Version 1.10. If you want to try this on another system or BIOS you should make sure you understand EXACTLY what is going on and are prepared to spot any problems or fix things yourself.

First, dump the exiting BIOS out. It resides at the top of the 32-bit address space, and is 2MB in size. You can use dd to dump it out of /dev/mem:

$ dd if=/dev/mem of=original_bios.fd bs=1024 count=2048 skip=4192256

It is a very good idea to back up this BIOS somewhere safe outside the laptop. Note that it not only contains your existing BIOS code, but also all your settings and manufacturer data (serial number, software license if you run an OEM version of Vista, etc).

Next, run vtenable.py. This will attempt to locate the Setup EFI variable on the non-volatile storage section and patch the VT byte to one.

$ python vtenable.py original_bios.fd vt_bios.fd

You can edit the source code to make other changes to the variable, but make sure you know what you’re doing. It’s worth reiterating that this does not patch your BIOS code. It only makes a setting change, just as if you’d turned on the VT option in the BIOS had it been there. In fact, there are two variables: Setup and Custom, and Setup is the one that changes are committed to when you use the setup utility. Restoring defaults should turn VT back off (untested). It also appears that Custom is probably what the setup defaults are, so changing that should semi-permanently enable VT.

I highly recommend performing a sanity diff between the original and modified images using vbindiff:

$ vbindiff original_bios.fd vt_bios.fd

Only two or three bytes should change: one or two adjacent bytes for the checksum (they should be decremented by one when you look at them as a 16-bit unsigned integer), and the VT enable byte should change from 00 to 01. Right after the checksum bytes you should be able to see the Setup name in UTF-16 (something like S.e.t.u.p.).

Finally, flash vt_bios.fd using the vendor-supplied flash utility. I use the DOS version (FLASHIT.EXE) with FreeDOS and a grub menu option so I don’t need to mess around with external media. Grab a base image here, then you can use mtools to copy the bios into it:

$ bunzip2 freedos_flashit.img.bz2
$ mcopy -i freedos_flashit.img vt_bios.fd ::/vt_bios.fd

To boot it using GRUB, get MEMDISK, part of SYSLINUX, and put something like this in your grub.conf:

title=BIOS Update
root (hd0,0)
kernel (hd0,0)/boot/memdisk
initrd (hd0,0)/boot/freedos_flashit.img

Of course, copy memdisk and the boot image to your boot partition, and change (hd0,0) to your boot (or root) partition everywhere and remove the /boot part if you have a dedicated boot partition.

Once you’re in FreeDOS, just type FLASHIT vt<tab> and be happy that FreeDOS supports tab-completion

Caveat: by doing this, you’re flashing the entire BIOS image. The flash tool makes no attempt to flash only the parts that changed, and the “flash only variables” commandline option seems to have no effect. You’re effectively reflashing your entire BIOS back on, so the usual BIOS flashing caveats apply: don’t turn the power off, etc. This could be accomplished a lot more cleanly if we had drivers for the flash chip / EC, since then we could use the normal EFI variable store procedure to atomically update the variable, which is completely safe.

You can use the MSR Magic tool to check whether VT is indeed enabled on your CPU.

Update: Several people are working on improved, more general tools to perform this hack across a broader range of InsydeH2O-based BIOSes. Read the comments and check them out, they’ve done some very good work.
Update 2: There’s a 8930G 1.21 BIOS version floating around (not on Acer’s site yet) with build date 3/3/2011. This version seems to have VT enabled without any hacking required (I’ve checked the contents and everything seems to be kosher and a real update, not some hack). I haven’t come across an official update file, but I did find a dump made by someone. I’ve manually cleaned it up to remove the variables and serial numbers so it should be identical to an official 1.21 update file (it will keep your current config and serials). You can find it here.

The chip has hardware line styling (stippling), and you can see 4 different settings (solid, “10″ dashed, “100″ dashed, “1000″ dashed) in sequence. At the higher setting it starts to look more like a point cloud with many more points than it has real vertices.

Also of note: I’m working inside a framework that drives operation of the SPMP from the PC. While the entire bunny transformation and rendering is happening inside the SPMP, the PC sends it the rotation matrix and tells it to go each frame (and also when to switch stippling and whatnot). So it’s slower than it would be in pure standalone hardware, because there’s still at least two serial port ping-pong commands each frame (one memory download for the matrix and one command to tell it to render the bunny with it).

You can grab the (ugly as hell) code in the Git repo.

Fun stuff: the projection is orthographic, so there’s no depth information rendered. This makes the rotation ambiguous. Do you see it rotating clockwise or anticlockwise (looking at it from above)? Can you make your brain switch between them?

If you’re interested and you have one of these or don’t mind spending $33 to get an interesting ARM machine, check out the wiki, Google Code project for the Prex port and other stuff, and my Git repository with a port of MINI and a bunch of client utilities for reverse engineering and testing the hardware stuff. Most importantly, however, come visit us at #spmpdev on the EFNet network! Most of the work and chitchat happens in the IRC channel.

I had previously patched the check out in the MusicLibrary binary, and forgot to write it up. However, I just looked at it again, and it turns out that you can get it to work just by changing a simple XML file. I guess they didn’t really care if jailbroken iPhone users used third-party software.

Here’s how: Edit /System/Library/Lockdown/Checkpoint.xml, find the DBVersion key, and change its value from 4 to 2. Save and reboot. Voila! I haven’t tested this extensively, but it seems to work at least on 2.1 and 2.2. You can then use Amarok or any other libgpod app to transfer data to the device (using the usual sshfs mount trick which is documented elsewhere for 1.x iPhones)

Update: abu from ml_ipod pointed out that DBVersion 3 also works. This version includes the old hash which was already present in older versions. I have tested this to work on version 2.1 of the iPhone software.
Update 2: DBVersion 3 works only on some devices, better stick with DBVersion 2.

MobileMusicPlayer synced via Amarok