In May 2008, I moved back to Strasbourg, and started to work for Creative Patterns, a video game development studio.

Last week, we released our first self-financed video game, for the iPhone and iPod touch: TURN.

TURN is a puzzle game in which the player guides his character through a maze of levels especially with his special power to turn the rooms.

The original gameplay mixes reflection and intuition. Your main ability is to rotate rooms at 90°. You must play with gravity to progress through rooms while avoiding traps like enemies or dangerous falls of objects. During the journey, the levels get harder and harder, and you must “think TURN” if you want to achieve the ultimate challenges.

You play as Kurt or Camila, two explorers who seek a strange artifact. Their quest will lead them in a trip of adventure and mystery. They will travel through industrial docks, damp jungles, even in cold ice, in a world inspired by novels from the first part of the 20th century.

In “TURN Episode 1: The Lost Artefact” you will share Kurt and Camila’s adventures through 3 worlds each with 9 levels of about 10 rooms. That’s more than 20 hours of brain teaser on your iPhone or iPod Touch.

You can try TURN Lite for free, and if you like it, you can buy Turn Episode 1 :) .

This solution is so simple it will blow your mind away. Twice.

I have tested it on my 2006 Mac Pro, using a Sapphire 4870 with 512MB VRAM (early model, based on ATI's reference design). The machine is running Snow Leopard 10.6.1.

The test might be a little biased, as I originally installed Snow Leopard using the 4870 card. I only reflashed it with its original non-EFI BIOS for the purpose of this test.

You'll need the iMac Graphics Update 1.0.2 and Pacifist.

First, mount the graphics update image and use Pacifist to open it. You'll need to extract two files from here, using administrator privileges: ATIROMFlasher.kext and ATIFacelessFlash.app.

After extracting them, we'll first need to make sure the kext is able to load. Open a Terminal, and run "sudo kextutil -nt ATIROMFlasher.kext" to check whatever problems it might have.

On my system, it complained about authentication failures, and also showed a few warnings. The warnings can be ignored, but the auth issues have to be fixed, using those two commands: "sudo chown -R root:wheel ATIROMFlasher.kext" and "sudo chmod -R 644 ATIROMFlasher.kext".

Then, we'll remove the iMac firmwares from the archive: "sudo rm ATIFacelessFlash.app/Contents/Resources/*IMG" and add the correct firmware to the flash utility: "sudo cp 4870.ROM ATIFacelessFlash.app/Contents/Resources/".

Note: removing the other firmwares is only important if you have other ATI cards in your mac. When ran, the ATIFacelessFlash application looks for all files in the Resources directory, tries to find a match in your PCI devices, and when one is found, initiates the flashing. So it could "harm" one of your other ATI cards. And I don't know how it behaves with a 4870X2 card, *IF* it is seen by the system as two cards with the same ID, *BUT* each need a different firmware for the card to work fine. From a quick disassembly, I'd say that only the first one would be flashed.

Now, time to plug the PC 4870 card in your machine. I had it in the 1st PCI Excodess slot, with no display connected, and the 7300 GT that originally came with my Mac in the 3rd PCI Excodess slot, driving my display. I don't know if MacOS X can boot without any graphics card, but if it does, you could also use ssh instead of a second card, if you have a second machine available.

Restart your mac, and flash the card: "sudo kextload ATIROMFlasher.kext" (loads the interface to the card), "sudo open ATIFacelessFlash.app" (flashes the card. The app should appear in your Dock, wait for it to complete), "sudo kextunload ATIROMFlasher.kext" (unloads the interface).

Then reboot once more, and voilà, your 4870 is now a Mac card. No need to boot a FreeDOS CD, no need to create a FAT partition on your disks.

The company I'm currently working for is regularly growing, and it happens more often than before that you go to the bathroom, only to find it already occupied by someone else.

Someone in the company pointed us to a post on meebo's blog where they described having the same issue, and the way they fixed it, but without any technical details. We of course agreed that it would be nice to have something like this, and I started to think about it.

Since I had an unused Linksys WRT54GL, the project should be based on it. Then, I went shoppping for a cheap motion sensor, which happened to behave as a switch : current passes when it's idle, and the circuit is broken for about one second when a motion is detected.

Since I didn't want to do massive polling, I decided to put an RS latch between the sensor and the motion detector. It ended up looking like this:



- the white part is the motion sensor,
- the green part is the RS latch and inverters I added
- the blue part is (probably) the Linksys PCB : GPIOs and hardwired component,
- the orange part is (probably) where the CPU is on the PCB, with its actual GPIO pins.

I "hijacked" GPIO3 (the amber light) and GPIO4 (the Cisco button) to interface the CPU and the RS latch, and this is how it works:

- when the system is idle, both R, S and Q are Low, GPIO4 and GPIO4_INT are high (just like when the Cisco button is not pressed),
- when some movement is detected, S becomes High for one second, Q becomes and stays High, and GPIO4 and GPIO4_INT become Low (just like they would when the button is pressed)
- when a GPIO3 is put to Low for a short moment, the LED blinks, R becomes High then Low again, but Q becomes and stays Low, and the system is back to idle mode (previously memorized movements are forgotten).

Basically, the goal is: once a movement is detected, it is memorized until a reset is sent.

I then did the soldering part, as can be seen on the two following pictures, and closed back the Linksys case (with a simple 3 pins connector added to its side, going to the sensor, for power supply and the switch-like output)





I finally built a simple kernel driver, compiled it using OpenWrt's build system, that creates a file in /proc. When the file is read, it returns "0" if no movement was detected since the last reset, and "1" otherwise.

Then, two simple CGI scripts were added to the mix to expose this /proc file through HTTP. As this device can act as a wireless client, talks HTTP, and does not require frequent polling, it can now be integrated with any intranet technology the company is or will be using.

A prebuilt binary package and a source package are available for the driver.

I recently received an email form Bela Lubkin, who pointed out some mistakes I made in my previous hack:

In grub-0.97_macrpro_esb2_ahci_stage1.patch, I happened to randomly notice a bug. (Ran across it while googling information to get my Dell notebook w/Ubuntu 8.10 to use ahci rather than ata_piix driver...)

The bug: you've moved the setup of the stack segment register (%ss) after the setup of the stack pointer (%sp). I don't have full context (didn't bother to find the stage1.S full file you're patching), so I don't know if it's OK that you are pushing %edx onto [%old-ss:$STAGE1_STACKSEG]. But probably not. But even worse is the "sti /* we're safe again */". Ancient 8086 mistake. You can't enable interrupts until the stack is setup correctly. Move the %ss setup code back to where it was.

I assume you moved it because you wanted to preserve the fact that %ax == 0 on exit of this bit of code. Well, I did find the grub 0.97 source to make sure: both %al and %ah are subsequently overwritten before being used. You don't have to preserve it.

You can save the whole push/pop %dx: find the comment "%dl may have been clobbered ...", move your code immediately before its `popw %dx; pushw %dx'. This does mean your hack isn't effective if grub is being booted from a floppy, but ... not a problem.

You can also save a few more code bytes. I assume this is being compiled as 16-bit (8086) code, e.g. with ".code16" GNU `as` directive. Thus, the instructions `push %edx' and `pop %edx' need a code32 prefix; replace with `push %dx; pop %dx'. Replace `mov $0xcfc,%dx' with `mov $0xfc,%dl'. Replace `xorl %eax,%eax' with `xor %ax,%ax'.

And he was even kind enough to send me a fix for these, so many thanks to him.

Here are links for the new patch he sent me, and an updated stage1 binary.

The Mac Pro is a really nice workstation, which comes with the really nice EFI instead of BIOS.

EFI needs an adaptation layer (the Compatibility Support Module, or CSM) that emulates the BIOS, to be able to boot legacy OS, like Microsoft ones, or any GNU/Linux distribution without EFI support (which is nearly all of them, afaik).

Unfortunately, the CSM provided by apple does not contain an AHCI OpRom, and has to put the disk controller into IDE mode, instead of using the (also really nice) AHCI mode (whereas the controller's default mode is AHCI, and MacOSX uses this mode).

So far, Linux driver developers put the hack in the driver: when initialized, it puts back the controller to AHCI mode. But this does not work with other OS, so I had to put it at a lower level.

As Apple's EFI part of BootCamp is quite simple (just "chainloads" to a legacy bootloader), I decided to use the GNU GRUB to load legacy OS, and modified it to put back the controller in AHCI mode before any OS tries to load a driver for it.

Here is the patch, and here is a stage1 binary built from patched Grub 0.97 sources.

Please note that this is extremely ugly! As I didn't want to spend too much time on this, I decided to go the fastest way: adding the hack as x86 assembly in stage1. But as stage1 has a really strict size constraint (must fit in the first block), I had to remove some other hacks from it, to be able to add mine in.

UPDATE: This OnMac.net forum thread contains a bit more detailled information on how to set this up.

IMPORTANT UPDATE: The patch posted here contains a few mistakes (the binary has been updated, and includes fixes). For a fixed version of the patch, please read this blog entry.