All the lulz have been had..

.. the game is now over. :)

Eating salad, reading papers

The new semester has begun and I am am going to be surprisingly busy with university stuff. I have to prepare a couple of seminar presentations on topics that I am not too acquainted with yet. The first being about a recently published paper on an algorithm for calculating Hausdorff distances between polygonal models in real time. I also eat salad.

nyu is operational again

So! Today I got home from university to find that nyu's replacement screen hinges had arrived from Hong Kong. Yay! I bought these from a chinese seller on Ebay a few weeks ago when nyu's (6 year old) hinges broke. They don't quite look the same as my old ones, but they fit and they appear unused. I don't expect them to endure another 6 years of frequent use however. Still, I'm happy.

How to duplicate lines/regions in Emacs

So, I read a blog post just now on line/region duplication over here and thought I'd give it a try as well.

Here's what I came up with:

(defun duplicate-line-or-region (arg)
  "Duplicates the current region (transient) ARG times, but at
least twice. If none is active, duplicate the current line
instead."
  (interactive "p")
  (let ((times (if (> arg 1) arg 2)))
    (save-excursion
      (if (use-region-p)
          (kill-region (mark) (point))
        (kill-region (point-at-bol) (point-at-bol 2)))
      (dotimes (i times)
        (yank)))))

Arrrrrr! Mono docs! *shakes fist*

I just ran into a Makefile that had a rule like this:

blah.tree blah.zip: Makefile
        mdassembler --ecma ./blah -o blah

Why does this suck? Because it will choke on make -jN and die horribly.

How it should have been written?

blah.zip: blah.tree
blah.tree: Makefile
        mdassembler --ecma ./blah -o blah

Introducing Spoor

Apologies

Phew, I haven't updated this blog in a long time, have I? Well, I have been in some kind of a serious slump these past few years and am working on fixing myself and picking up a couple of projects on the way. This might give me more to write about in the future. For now, let me introduce you to spoor.

Spoor

Without further ado, spoor is my new laptop. It's a Dell Inspiron 13z (or 1370) with an Intel ULV dual core processor, both cores clocked at 1.3ghz, 4gb of ram and nVidia G105M graphics. Here are some pictures:

She will replace nyu (my old laptop, a Dell Inspiron 630m) as my primary mobile computer. nyu is currently waiting for her replacement screen hinges since her old ones broke a couple of days ago:

So far, spoor's battery life running linux has me pleasantly surprised. She can hold out on a single charge for up to 7 hours with wifi enabled and normal work load. (That's without letting her hard

drive spin down.)

There have been non-trivial problems however, namely:

• no backlight control (backlight is at full display brightness always)
• distorted display after switching to console / waking up from hardware suspend with drivers older than version 195.36.08
• no fan control (fans are on always)

I have managed to find a solution for the backlight problem. A kernel module called nvidia_bl provides a /sys/class/backlight interface that works for a wide range of nvidia chips. Sadly, initial

trials suggested that mine was unsupported. "Oh well", I thought, "let's do the hackety thing", after I had noticed an unsuspicious reference to the G105M in the module's source.

Backlight fix

After adding a bit of code the module would load and using the sysctl interface it was indeed possible to change the display brightness. However, that was only within a range of *very low*

brightness levels. I figured that the problem was in the way the brightness register worked for this specific chip .. and didn't give a damn. Instead, I tweaked the module to use rather bloated values I got through trial and error for the minimum and maximum register values. It works, but if anyone out there knows of the correct way to handle this, please drop me a message.

Here is a patch:

--- nvidia_bl_orig.c 2010-02-02 22:35:41.000000000 +0100

+++ nvidia_bl.c 2010-03-08 15:20:44.793041658 +0100

@@ -44,6 +44,8 @@

#define NV5X_PDISPLAY_SOR0_BRIGHTNESS 0x0000c084

#define NV5X_PDIPSLAY_SOR0_BRIGHTNESS_CONTROL_ENABLED 0x80000000

+#define SPOOR_BACKLIGHT_LEVELS 128

+

/* Driver private data structure */

struct driver_data {

/* PCI region (BAR) the smartdimmer register is in */

@@ -73,14 +75,14 @@

if (reg_value == off)

return 0;

else

- return (reg_value - min) * (FB_BACKLIGHT_LEVELS - 1) / (max - min);

+ return (reg_value - min) * (SPOOR_BACKLIGHT_LEVELS - 1) / (max - min);

}

static inline unsigned int set_intensity(unsigned int intensity, int off, int min, int max, int forceoff) {

if (forceoff)

return off;

else

- return min + (intensity * (max - min) / (FB_BACKLIGHT_LEVELS - 1));

+ return min + (intensity * (max - min) / (SPOOR_BACKLIGHT_LEVELS - 1));

}

/*

@@ -169,8 +171,11 @@

.reg_offset = NV5X_PDISPLAY_OFFSET + NV5X_PDISPLAY_SOR0_BRIGHTNESS,

.reg_size = 4,

.off = 0,

- .min = 50,

- .max = 1024,

+

+ /* hacked for spoor */

+ .min = 6628, //50,

+ .max = 138090, //1024,

+

.backlight_ops = {

#ifdef USE_BACKLIGHT_SUSPEND

.options = BL_CORE_SUSPENDRESUME,

@@ -310,6 +315,8 @@

{ PCI_VDEVICE(NVIDIA, 0x06eb), (kernel_ulong_t)&nv5x_driver_data },

/* nVidia Geforce G105M */

{ PCI_VDEVICE(NVIDIA, 0x06ec), (kernel_ulong_t)&nv5x_driver_data },

+ /* nVidia GeForce G105M on spoor */

+ { PCI_VDEVICE(NVIDIA, 0x0a69), (kernel_ulong_t)&nv5x_driver_data },

/* nVidia QuadroFX 370M */

{ PCI_VDEVICE(NVIDIA, 0x06fb), (kernel_ulong_t)&nv5x_driver_data },

/* nVidia Geforce 9400M */

@@ -386,6 +393,15 @@

static const struct dmi_system_id /* __initdata */ nvidia_bl_dmi_table[] = {

{

.callback = &nvidia_bl_dmi_match,

+ .ident = "Inspiron 1370",

+ .matches = {

+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),

+ DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 1370"),

+ },

+ .driver_data = (void *)0x0a69, /* nVidia Geforce G105M - obtained from lspci -nn */

+ },

+ {

+ .callback = &nvidia_bl_dmi_match,

.ident = "VGN-AW11",

.matches = {

DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),

@@ -529,7 +545,7 @@

}

/* Set up backlight device */

- nvidia_bl_device->props.max_brightness = FB_BACKLIGHT_LEVELS - 1;

+ nvidia_bl_device->props.max_brightness = SPOOR_BACKLIGHT_LEVELS - 1;

nvidia_bl_device->props.brightness =

nvidia_bl_device->ops->get_brightness(nvidia_bl_device);

backlight_update_status(nvidia_bl_device);

Unsolved problems

As for the distorted/flickering display after console switch, that has started happening only after a nVidia driver downgrade by my linux distribution (Arch Linux). Apparently the newer driver stopped fans from working and thus caused hardware damage. I doubt spoor has a fan

specifically for the gpu. Anyway, I will wait for another update from nVidia, I guess, since these drivers are proprietary (or use the free nouveau driver, but that's a different story).

Last but not least, there is the lack of cpu fan control. On nyu I used to be able to load the i8k module which enabled me to control the fans. spoor will just crash loading it. What's more is that Dells apparently don't use acpi to do fan control, so hacking the DSDT is out of question. I guess I will have to live with the useless noise for the time being.

Outlook

All that being said, I am quite happy with spoor and am sure linux support will become better rather than worse. ;)

There are some software projects I intend to do and blog about soon. Let's see how that goes.

outgoing message

a long time has passed since we first met, first knew each other;
since I loved you. in a way, i still do. you have prolonged my life
back in 2001, given me strength to prove to myself what i can be worth
and what i carry within. i can not take this lightly and for all i
have become, all i could have become, you have my eternal thanks.
i would have liked to talk to you again, about our respective directions
in life, about the past, about the things that have happened to us
since our sad parting. my story would surely have fallen short.
i trust that you still carry yourself with the grace that i fell in
love with, so vividly remember, and that you are slowly but steadily
fulfilling your dreams. it is my wish that you do.

love, andreas

the current state of things

A long time has passed since I have posted to this blog, which is rather sad. I have had lots to do and in between exams, illness and SoC hacking there was not much time left to dedicate to keeping the blog up to date, even my training suffered.
Anyway, Dirty D is "prototype done", which means support for SCUMMv5 and code structuring. Its final code formatting is buggy however, so even though the structuring is correct, this is hard to observe unless going into the source and inserting statements to print the various graphs and related meta information which are generated during code structuring. Very much in character of its name and because of lack of time I left it like that to move on to the implementation of the final decompiler in python. (This also meant skipping implementation of a second prototype devoted to the stack based bytecode variants and the question of how to generalize the disassembler portion of the decompiler, but I will come back to that.)
As for "finalD" (it does not have a name yet), it disassembles SCUMM <= 5 currently. The structuring code is next on my agenda to be translated to python, followed by the output. There are a few more days in SoC and I am positive that these things will be finished .. soon :)
There's some beef though and it is related to the stackbased SCUMM variants >= 6. I hope to be able to wrap up the structuring and outputting code fast enough to have time left to devote to these, but the outlook is grim at least for the SoC deadline. Correctly handling these stack based bytecode variants might just require some limited form of data flow analysis, which I have tried to avoid in general. Apart from this, the sheer amount of tedious work involved in writing handlers for opcodes has me cringing in terror by now, at least when deadlines are involved and the optimum outcome until the end of SoC I can envision involves me not sleeping for five days straight.

CRUNCH or How to drain yourself of energy..

These past few days I have worked frantically through the nights to complete Dirty D's opcode repertoir for v5 of SCUMM. I finished up a couple of minutes ago. Nothing beats tediously adding dozens (~107 I believe) of opcode handlers one after another. I will have to think of a way to minimize the pain next time this kind of work comes knocking on my door, which is soon.

Anyway, according to my schedule I was supposed to finish this first prototype, well, yesterday. I currently have an intermediary representation of the raw "disassembled" data. so control flow structure rec. and pseudo code formatting are still missing. The formatting code itself will take about one day, maybe less, and should cover most of the requirements for another bytecode variants as well. (intermediary rep -> pseudo code). The control flow structure rec is what I will write next. I hope to finish all of the remaining work for Dirty D until next Monday so as to not waste much more time before deciding on the nature of the second prototype. Opcode specification probably will be key then, there has to be a less painful way... *rubs his eyes*

good night, for now..

Hacking through the night (Status Update)

It's 5:30 over here. I am somewhat tired after having spent the night hacking on the first decompiler prototype for SCUMM v5 (antipasto "Dirty D") and figured I might just as well whip up a quick status update on my blog. These past few weeks I have been quite busy with university work and personal issues and hence, even though I started writing Dirty D earlier than planned, I find myself barely within schedule now. There are ~10 days until the first prototype "milestone" and my slacker sense alarms me of more sleepless nights ahead. I still have to do the first svk push to my tools branch in the ScummVM repository, but that will happen later today once I am on campus (unless I am run over by a bus or abducted by aliens). Anyway, not too long ago I talked to my mentor about the general design of antipasto. Let me give a quick summary:


The decompiler is planned to roughly consist of two parts.

The first encompasses general utilities to be used to extract/process bytecode from game scripts and bytecode dependent backends making use of these utilities to produce a uniform temporary opcode listing format independent of bytecode variant in structure. All control flow manipulating opcodes of a bytecode variant will have to be replaced by semantically identical counterparts of the temporary format during processing.

The second part holds the control flow analysis functionality of the decompiler. It is responsible for transforming a partial decompilation in temporary format as produced by one of the bytecode variant backends into a semantically identical "program" with low level control flow statements such as gotos resolved into higher level looping/branching constructs where possible.

Rationale:

By disconnecting the control flow analysis part of the decompiler from bytecode dependent decompilation code, we'd go a long way of making the decompiler simpler to extend with support for new bytecode formats. Apart from that, the introduction of a temporary decompilation format might also help make more general ways of specifying bytecode formats in part one of antipasto apparent. Every bit of functionality for initial bytecode processing that can be ripped out of a bytecode variant backend and pressed deep into the guts of Dirty D eases future adding of support for new bytecode variants.

And that's what I'd like.

Report #1 -- Noodles and Double D

Week #1

I have spent most of my first week rereading descumm's source code and prodding my mentor to write up a little document describing SCUMM v5 bytecode format. He delivered it on sunday and it proved to be quite useful for getting a better grasp on descumm's inner workings by just having it side by side with a hex view of one of the Monkey Island 1 game scripts Andreas Muegge was kind enough to send me and descumm's decompilation of said script.

I also started thinking about recognizing control structures within bytecode (from conditional gotos/jumps ..), but as there is more drudgery to do until this becomes relevant I have not yet written up a concise representation of my ideas.

Week #2

I have actually started programming a decompiler for version 5 of SCUMM in Scheme on Tuesday. According to my original project schedule, this wasn't planned to happen for another two weaks while I sketch out an initial design. For this first prototype however, I will heavily lean on descumm's opcode handling code to be able to work on certain improvements earlier.

The prototype is named antipasto and the series of versions I plan to implement will henceforth be referred to as the family of antipasti. The first of these bears the code name "Dirty D" and will essentially be a decompiler for SCUMM v5 with improved control structure recognition in place.

Soon, the work begins..

I have not had much time up unti now to work on my project, much less to blog about it. So: "Hey there, fellow Coders of Summer!" and of course to whoever else is reading this: "Welcome. Wait, what are you doing here?!".

First a small introduction for the folks over at Planet SoC:
My name is Andreas Scholta and this summer I will be working on an improved game script bytecode decompiler for ScummVM. And if that wasn't exciting enough, I will be using Scheme as my language of choice, at least for prototyping that is. Because this is my first time applying for/participating in SoC I do feel lucky and elated for me to have made it this far. Naturally, the blunt of work is still ahead and I hope I am able to successfully complete my project by the end of this summer.

Work is officially supposed to begin tomorrow and hence I have finally taken the time to talk to my mentor about basic project infrastructure things. As a result a SVN branch has been set up and a wiki account was created, which I will use for project internal progress reports and possibly for documentation of specific ideas.

Much thanks goes out to the people who have encouraged me (some indirectly) to take part in this beautiful endeavour and whose silent support up to and loud cheers upon my admission filled me with motivation and a subtle anxiety to finally be able to get to work. You know who you are.

For now, what else is there to say but..
Happy Hacking!

Google Summer of Code

"Dear Applicant,

Congratulations! This email is being sent to inform you that your
application was accepted to take part in the Summer of Code. [..]"

... when that mail appeared in my inbox an hour ago, I screamed for excitement. Accepted! Woooooo! This summer I will be working for ScummVM, writing a new bytecode decompiler for scumm scripts. It will be an interesting experience to say the least :)

Aaaaaaaaaah, this is going to be a beautiful summer!

...

What can I write? I feel speechless and somewhat drained of emotion. It's as if I've spent most of it on the second half of that anime I have been watching the past couple of days: Kanon, the 2006 remake by Kyoto Animation to be exact.

And it seemed like an innocent harem anime in the beginning too... except there was no slapstick humour and its male lead was not a klutz. He was just asshole enough for his harem to react in interesting and entertaining ways. I am no anime blogger and I won't spoil this for you. But heed this warning and don't take it too lightly. If you decide to watch this show, enjoy the first half of laughter and general lightness, but don't let it fool you: soon a series of character centric story arcs will emerge, each sadder than the previous one, gradually working towards a final, devastating attack on your male (if you are male, that is) ego with the obvious goal of making you empty your lacrimal sac under the pressure of overwhelming sadness.

I am spent. I am glad I watched this and I am starting to realize how much I regret having seen it all already. What a ride.. :) Oh! Maybe I should not mention it, but yes, it has a happy end.

Emacs Theme

I wasted today, tweaking David O'Toole's color-theme-cl-frame.el to be more clowney ("colorful"). I will not upload the tweaked theme ever. Ha ha ha.

[update: fugly color-theme-brx.el]

Switching to Google Reader

So, a friend has given me a heads up on some Google Reader developments today: it has improved. Never having tried any previous version, I opened the page, imported my feeds and.. decided to stay.

For now I will keep my Bloglines account, but I can already imagine me trashing it. Bloglines is great, don't get me wrong, but Google Reader has a few obvious things going for it (see Kiko vs Google Calendar).