Posted in Memorable Quote by Thomas Themel on October 30, 2005.
Thomas Sowell in a Washington Times article commemorating Rosa Parks, via Cafe Hayek:
People who decry the fact that businesses are in business “just to make money” seldom understand the implications of what they are saying. You make money by doing what other people want, not what you want.
It’s a brilliant condensation of something that a lot of people don’t seem to get. I understood the principle, but my explanation usually ended up being a bit more long-winded and complicated.
Posted in Personal by Thomas Themel on October 29, 2005.
Civilization IV is out. I bought it, but of course it’s not working in Cedega yet – I get to the “Loading…” screen, but it seems that the stupid SafeDisc copy prevention mechanism then enters an infinite loop. NoCD cracks don’t seem to exist yet, at least not in places where someone with very limited warez-fu can find them. Even after bypassing SafeDisc it will probably not run, since it relies on a DirectX 9 DLL that’s not provided by Cedega, at least not until the 5.0 release that’s due in about two weeks. Great, that means that I can work on my understanding of vector analysis and special relativity instead of building hypothetical empires during the five lecture-free days ahead.
Btw: Ask MetaFilter sometimes scares me.
Posted in Personal by Thomas Themel on October 13, 2005.
When I returned to Vienna after the summer break, one of my resolutions was to blog a bit more regularly. It appears that I underestimated the effort involved in studying physics. A lot. Instead of a gentle student routine with enough time to work on my general education (ie reading blogs and Wikipedia :)), I am currently experiencing something more akin to a meat grinder. It’s not as if there were terrible obstacles, it’s just that there’s a lot of tiny ones, and they all take time and practice to overcome.
I tried taking two evenings off for fun this week and immediately found that I felt like I was falling behind. Not good. It’s practice problems again for the rest of the week. Blogging will probably remain spurious until I finish catching up with all the stuff that I already forgot from school or never heard of before, but should have.
Despite the stupendous amount of work I have to do (and the envy I feel when people ask me questions like “Oh, so you have courses on Fridays, too?”), it’s great, great fun. Digging around formally near the foundations of mathematics is fun, and the physics problems are interesting reminders that somebody actually does something useful with all that complexity.
Blogging time is over. Back to mathematics…
Posted in Technology by Thomas Themel on October 3, 2005.
This summer, I had the pleasure of living in a place that had a large-screen television and a mod-chipped Xbox attached to it. While it was initially only used to play Dead or Alive Ultimate, I soon used my unbeatable Internet-fu to obtain all kinds of emulators on it so that we could enjoy nostalgic reminders of our misspent childhood, or enjoy the inexplicable greatness of Mario Party with four players.
After moving back to my TV-less and Xbox-less apartment in Vienna, I decided that I had to have game pads for my PC to continue basking in emulated fun. I spent about two weeks skimming various computer shops and web sites for cheap gamepads, but couldn’t find anything that was a) cheap and b) powerful enough to emulate a Nintendo64 controller.
Since my Xbox software research had let me to the depths of the Xbox Linux Project’s web site, I already knew that Xbox controllers were basically USB gamepads with non-standard connectors. I also knew there was a Linux driver available for them (those hours spent browsing make menuconfig pay off after all!), so I resolved to try and attach one of them to my PC. I ordered a pair each of Logitech Xbox controllers (EUR 9.95 each) and extension cables (EUR 3.95 each) from Amazon and waited.
When they arrived on September 30, the soldering fun began. Following this guide, I cut the extension cables to keep the possibility of reselling the controllers, and I also cut two unused USB extension cables I found in my cable ball to get the needed USB A plugs. Stripping the isolation of the controller extension cable’s end, I encountered the first road block: While the guide claimed that the wires should be in USB-standard black, green, white, red, my extension cable contained blue, brown, red, white and yellow wires. I consulted this handy document from xbox-linux.org to find out which wires belong to which contacts and my trusty multimete to quickly establish that the blue wire was supposed to be green and the brown wire was supposed to be black. Feeling safe, I soldered all the wires together with their USB counterparts and plugged the resulting construction into my USB hub.
I got a two-second flash of the activity LED and some errors in the kernel log:
usb 1-3.2: new full speed USB device using ehci_hcd and address 11
usb 1-3.2: device descriptor read/64, error -32
usb 1-3.2: device descriptor read/64, error -32
My first idea was to blame my extremely ugly soldering, so I cut the whole mess and re-did the soldering much more diligently. However, this didn’t change anything about the results. After trying on a different USB hub, I went back to measuring the different wires’ connections and discovered that I had been overly optimistic in only measuring the contacts for the wires with unknown colors. This is the complete color mapping table:
| Extension cable wire color |
Original Xbox color |
Function |
| brown |
black |
GND |
| blue |
green |
Data+ |
| yellow |
white |
Data- |
| red |
red |
+5V |
| white |
yellow |
Microsoft proprietary |
After fixing the connection, I actually got good news in my dmesg:
drivers/usb/input/xpad.c: X-Box pad driver:v0.0.5
input: X-Box pad on usb-0000:00:05.2-3.3.1
Hooray! Btw, it seems that I grilled the hub port that I used for testing the broken soldering, so be careful if you try this at home, kids – your Chinese EUR 5 hub might not be designed for this kind of usage. After loading the joydev module, I even got /dev/input/js0 device that I could then calibrate with jscalibrator. The device was exported by the driver as having 8 axes and 10 buttons, assigned like this:
| Buttons |
Axes |
| Button 0
|
A
|
| Button 1
|
B
|
| Button 2
|
Black
|
| Button 3
|
X
|
| Button 4
|
Y
|
| Button 5
|
White
|
| Button 6
|
Start
|
| Button 7
|
Left Analog Push
|
| Button 8
|
Right Analog Push
|
| Button 9
|
Back
|
|
| Axis 0
|
Left Analog, horizontal
|
| Axis 1
|
Left Analog, vertical
|
| Axis 2
|
Left Trigger
|
| Axis 3
|
Right Analog, horizontal
|
| Axis 4
|
Right Analog, vertical
|
| Axis 5
|
Right Trigger
|
| Axis 6
|
D-Pad, horizontal
|
| Axis 7
|
D-Pad, vertical
|
|
The triggers and the digipad ("cursor pad") are both reported as axes instead of buttons, which makes sense at first glance because the triggers are really analog (0..255) and the digipad is most often used to represent movement. The digipad’s movement range, though, is only (-1..1) compared to the (-32767..32767) of the analog sticks, and that seems to confuse some applications. Snes9x, refuses to accept input from the digipad axes while it works nicely with arbitrary axes from the analog sticks.Also, I found that the left analog stick’s vertical axis was inverted on my controllers. Some research led me to the (*shudder*) Gentoo forums, where I found this post offering a patched version of the driver that allows inverting axes and mapping triggers and the digipad as buttons at load-time. This version is labelled as 0.0.7. With that, I could at least get decent results for Nintendo64 emulation using Mupen64, but I still had to steer Mario using the analog stick in Snes9x, which was rather unsatisfactory. I resolved this by simply changing the axis range to be the same as those of the other axes:
--- xpad.c.0.0.7 2005-10-01 20:35:19.000000000 +0200
+++ xpad.c 2005-10-01 20:35:58.000000000 +0200
@@ -189,8 +189,8 @@
input_report_key(dev, BTN_2, (data[2] & 0x01)); // up
input_report_key(dev, BTN_3, (data[2] & 0x02) >> 1); // down
} else {
- input_report_abs(dev, ABS_HAT0X, !!(data[2] & 0x08) - !!(data[2] & 0x04));
- input_report_abs(dev, ABS_HAT0Y, !!(data[2] & 0x02) - !!(data[2] & 0x01));
+ input_report_abs(dev, ABS_HAT0X, (!!(data[2] & 0x08) - !!(data[2] & 0x04)) * 32767);
+ input_report_abs(dev, ABS_HAT0Y, (!!(data[2] & 0x02) - !!(data[2] & 0x01)) * 32767);
}
/* start/back buttons and stick press left/right */
input_report_key(dev, BTN_START, (data[2] & 0x10) >> 4);
Now, I’ve got unmitigated SNES fun!
To make matters even more interesting, there is another version of xpad.c in the xbox-linux.org CVS that seems to have some of the changes (triggers as buttons, automatic inversion of Y axis when required) from the 0.0.7 version hardwired into it. Perhaps I’ll find the motivation to try and find out who’s responsible and what they think of merging the changes.
For now: I need two more controllers, and then it’s Mario Party every night!
Posted in Personal by Thomas Themel on October 1, 2005.
The current issue of the RISKS digest has an interesting item about a whistleblower alerting aviation authorities to potentially disastrous flaws in the A380′s cabin pressure system. Quote of local interest from the linked LA Times article:
Mangan was chief engineer for TTTech Computertechnik, a Viennese company that supplies the computer chips and software to control the cabin-pressurization system for the A380, which is being assembled at the Airbus plant in France.
In October, TTTech fired Mangan and filed civil and criminal charges against him for revealing company documents. The company said the information was proprietary and he had no right to disclose it to anyone.
Mangan countersued, saying he had been wrongly terminated for raising legitimate safety concerns.
Unlike U.S. laws that shield whistle-blowers from corporate retaliation, Austrian laws offer no such protection. Last year an Austrian judge imposed an unusual gag order on Mangan, seeking to stop him from talking about the case.
Since this story is happening just around the corner from here (I walk past
href="http://www.tttech.com/">TTTech‘s offices every day, it seems),
the story is of special interest to me. The company claims that he’s just a
disgruntled ex-employee seeking to hurt the company after they let him go for
lacking performance – see
href="http://www.wirtschaftsblatt.at/cgi-bin/page.pl?id=401128">this article
[DE]. It seems the story is getting some circulation, there’s
href="http://webreprints.djreprints.com/1223170776962.html">an older WSJ
article,
href="http://www.spiegel.de/wirtschaft/0,1518,377101,00.html">Der Spiegel
[DE] has picked it up.
Unfortunately, being news articles for a non-technical audience, all of them
are a bit rare on the details of the story. The LA Time talks about Mangan
posting company documents on his "weblog". Googling for a Mangan blog didn’t help me find a weblog, but I found eaawatch.net. It’s registered through Domains By Proxy, so the whois information is worthless, but it looks a lot like the kind of site that can get you sued, and it has Mangan’s name and a lot of TTTech e-mails and documents on the subpages, so I assume this is what they’re talking about.
The style of the page (too many adjectives, colors and "quotes" around terms) makes it look a lot like the typical conspiracy nut page, but there’s actually quite a bit of actual information there.
I liked the DEADLY DESIGN AND QUALITY DEFECTS page a lot. It documents a number of rather specific technical grievances with the product, and management behaviour that appears all too plausible to me (emphasis altered):
TTTech TTPOS Defect, #11415 results in unpredicatable execution of outflow valve control software
Detected over a month after the “flightworthy candidate” release had been sent
to Nord Micro, and was discovered accidentally by an engineer having developed
a sales demonstration for a potential customer, discovered that all of the
nodes of the network were failing. This defect resulted from the fact that the
TTPOS was not developed from the beginning in compliance with requirements and
designs, as the macro responsible for performing the setting of memory would
not have been allowed by the coding standards and policies of safe software
development established for use in the development of safety critical systems.
This defect results in the incorrect execution of code, having been triggered
by the detection of an error, as the code branches to the address found in the
interrupt vector table which was not cleared to an initial safe setting, and
will start executing code at whatever address happens to be stored at this
position in the vector table, thereby resulting in entirely unpredictable and
therefore dangerous behavior. TTTech’s manager of aerospace sales Andreas
Eckel, directed that no persons from TTTech were to contact Nord Micro, Airbus,
or EASA to notify them of the existence of defect #11415, due to the fact of
its accidental detection, having resulted from non compliance with coding
standards, existed after the performance of several code inspections had failed
to detect it, and requirements based testing failed to detect it. Fear of the
performance of a “conformity inspection” by EASA, caused TTTech to hide the
defect as an conformity inspection would likely result in the discovery that
the Manager of European Sales had violated the official release process, and
forced “open activities” such as outstanding process conformity issues such as
peer reviews and code reviews to be falsified as having been performed and
closed out, the discovery of forged approval signatures on process approval
documents, that the certification evidence was in fact reverse engineered from
non conforming software rather than developed in compliance with safety
critical software development processes. A “flight worthy release candidate”
forced to be released in violation of TTTech aerospace release processes
containing falsified process evidence and forged approval signatures, was sent
on August 24th 2004 to Nord Micro, Airbus, and EASA in advance of the
performance of the EASA audit performed onsite at TTTech on September 21-22
2004.
This and the other paragraph about the way the task scheduling code was
allegedly created by trial and error and never formally specified make it
rather obvious to me how someone with experience in critical systems design
could be alarmed at what he saw going on. The details on the site look rather
too realistic to me to be made up out of thin air, so I guess that at least
this part of the story is true. It definitely reminds me of stuff I’ve seen
when doing software development work, and I consider it rather plausible that
TTTech was simply in over their heads with this project and struggling to not
admit that to a customer.
Of course, up to now we don’t have an aviation safety scandal, only some
evidence of a badly-run development process. However, considering the immense
pressure on all the involved companies (and probably even EASA) to avoid any
further delays in the A-380 project, I don’t think it’s above them to actually
ignore something that might appear as a petty safety concern.
Of course, there’s still the option that Mangan is misguided or malicious
and that the involved companies are only legitimately keeping him from drumming up
a scare, but I’m not convinced – their heavy-handed tactics are rather unfit for
dealing with someone who’s spreading misinformation.
I’ll follow this story with some interest…