Posts tagged "debugging"

Using your car as a giant joystick for $20

Mon 18 December 2017

A car rigged to play videogames with a projector pointed at a wall

DISCLAIMER: Cars can be dangerous. The electrical and mechanical systems of a car are not designed for this use case, and you run the risk of damaging them. This project worked fine for this particular vehicle, but could damage critical systems such as steering and braking in a different model. Do not attempt this with a vehicle that isn't yours, or a vehicle that would leave you with no contingency if it were to break. The author will not be held accountable for any damage caused from following these instructions.

This project is about how to rig the controls of nearly any recent car (in my case a 2007 edition Mazda 3) to act as a giant game controller. In a nutshell; input from the car will be scraped as CANbus messages from a cheap OBD-II adapter, then converted to standard joystick and keyboard events, which will be used to drive a video game projected onto a screen in front of the windshield. No physical modifications to the car are required; the only one I made was to pull the fuses for the headlights so as not to blind the projector screen.

The full source code used for the above demo is available at GitHub and BitBucket. With luck, anyone with entry-level Python experience should be able to adapt this for their car. I think this is a nice practical introduction to car hacking and reverse engineering, without the need to spend a lot on exotic debugging hardware.

Article continues here! KEEP READING, YOU

Show Your Working: Fixing a pile of bugs in MAME

Sun 03 December 2017

The parfait eating contest in Daisu-Kiss

Show Your Working is a brand new segment where I write up things I have attempted to fix in open source software. Sometimes it's interesting to debug a problem yourself from first principles, even if the codebase is huge and you don't know anything going in. I will try and explain my thought process as I venture out into the weeds armed only with a butter knife.

The software

If you haven't heard of it, MAME is an emulation project with the aim of supporting basically every arcade machine ever made. To do this, thousands of circuit boards and custom chips have been probed, analysed, decapped with acid, and ultimately written out as code. By adding board ROMs (whole dumps of the memory chips containing the copyrighted program data), MAME can emulate a system by connecting together drivers for all of the chipsets as per the layout of the original board. Recently, the sister project MESS has been merged back into the MAME main codebase, adding ~2200 consoles home computer systems to the lineup. It is an incredible feat of volunteer-driven engineering.

Unlike other emulators, MAME places accuracy and preservation above all else. All CPU code is interpreted (none of this JIT nonsense!) and runs time-shared in a single thread. Instead of tightly coupling hardware code with the framework for performance, MAME has an infinitely-rewirable generic module architecture to encourage reuse of chip drivers across platforms. If a slightly better dump of a ROM set is released, MAME won't hesistate in ditching compatibility with the old set. Performance hacks? Not welcome.

Also I was not exaggerating when I said every arcade machine ever made. The MAME source tree has slightly north of 6900 .cpp files, and a princely 2.9 million lines of code (4 million if you count headers!). This is a Big Codebase.

Article continues here! KEEP READING, YOU

Show Your Working: Patching a bug in a 25 year old Sierra game

Sat 23 September 2017

That bloody flamingo puzzle from the Sierra game "Island of Dr. Brain"

Show Your Working is a brand new segment where I write up things I have attempted to fix in open source software. Sometimes it's interesting to debug a problem yourself from first principles, even if the codebase is huge and you don't know anything going in. I will try and explain my thought process as I venture out into the weeds armed only with a butter knife.

The software

ScummVM is a heroic effort to make a cross-platform engine for hundreds of classic adventure games, making them natively playable on modern systems. Since 2010, ScummVM contains an interpreter originally from the FreeSCI project, and by now does a pretty good job playing games based on the Sierra Creative Interpreter. If you haven't heard of ScummVM, I can't recommend it enough.

It's gotten to the point where ScummVM provides a much better experience than emulating the games in DOS/Windows. Still, given that the engine is reverse engineered without the original code, there's all manner of edge cases and quirks that have to be emulated in order for the games to work correctly, as we'll find out!

Article continues here! KEEP READING, YOU

Show Your Working: Turning off PulseAudio "flat volumes"

Sun 23 July 2017

PulseAudio volume control application with awful "flat volumes" behavior

Show Your Working is a brand new segment where I write up things I have attempted to fix in open source software. Sometimes it's interesting to debug a problem yourself from first principles, even if the codebase is huge and you don't know anything going in. I will try and explain my thought process as I venture out into the weeds armed only with a butter knife.

The software

PulseAudio is the software audio mixer for most desktop Linux distributions. Let's not mince words; PulseAudio has an awful reputation, mostly earned from the botched rollout by Ubuntu and other distributions back in 2008. Long-time Linux users remember these as the dark years where games were unplayable, and everything was punctuated by a loud crackling from the constant buffer underruns. The most egregious problems were caused by the aforementioned shonky buffering, plus a reliance on timing-related ALSA features which had never been used/tested properly for many sound drivers. It didn't help that barely any applications had direct support for the PulseAudio API; there were compatibility shims for ALSA/OSS applications, but they were a crapshoot at best.

But that was a decade ago! We've moved from version 0.9 to version 11.1, a metric ass-ton of effort has gone into making the mixer first rate, most Linux sound libraries are fully Pulse compatible, etc. etc. Surely everything is perfect now, right?

Article continues here! KEEP READING, YOU

Dead KORG microKEY, Part 2: Noobface McHamfists Desolders His First SMD

Fri 17 June 2016

J-Link and microKEY plugged into breadboard

Oh God. Oh God. I've been putting this one off, but the stuff has arrived. I can't back down now!

A brief résumé of what happened in Part 1: this great little KORG microKEY MIDI controller stopped powering up for reasons unknown. By wiring it up to a J-Link debug probe, we found that the CPU was still alive and kicking, yet somehow the computer was receiving garbled USB messages. As this keyboard has a built-in USB hub, the stab-in-the-dark diagnosis was that the chip responsible (a Genesys GL850G) had gone bad and needed replacing. Unfortunately, the chip is a 28-pin 10mm*8mm surface mounted design, and our bumbling hero has never before soldered an SMD component, much less reworked a board!

To properly capture the fear of someone doing surface-mount rework for the first time, everything in this piece was written minutes after happening.

Article continues here! KEEP READING, YOU

J-Link Detective Squad: Dead KORG microKEY-37

Sun 08 November 2015

Korg microKEY-37

I love the KORG microKEY 37. It's an excellent entry-level MIDI controller that fits unobtrusively on your desk, great for impromptu jamming when you should be focused on something boring like "tax" or "finding a new house before eviction day". The keys feel pretty soft, as they use rubber domes instead of metal springs, but the velocity response is excellent. I highly recommend it, as it's one of those products which basically lives forever and delivers year after year of good service.

I bring this up because back in about February, my KORG microKEY 37 stopped turning on. The unit would no longer connect via USB; each time it would give up at different points during the initial handshake, with dmesg spewing a number of unhappy messages. Here's one attempt at plugging the device in.

[Sun Sep 27 06:00:56 2015] usb 3-1: new full-speed USB device number 17 using xhci_hcd
[Sun Sep 27 06:00:56 2015] usb 3-1: device descriptor read/64, error -71
[Sun Sep 27 06:00:57 2015] xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 16.
[Sun Sep 27 06:00:57 2015] usb 3-1: hub failed to enable device, error -22
[Sun Sep 27 06:00:57 2015] usb 3-1: new full-speed USB device number 18 using xhci_hcd
[Sun Sep 27 06:00:57 2015] usb 3-1: device descriptor read/64, error -71
[Sun Sep 27 06:00:57 2015] xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 17.
[Sun Sep 27 06:00:57 2015] usb 3-1: hub failed to enable device, error -22
[Sun Sep 27 06:00:57 2015] usb 3-1: new high-speed USB device number 19 using xhci_hcd
[Sun Sep 27 06:00:57 2015] usb 3-1: Device not responding to setup address.
[Sun Sep 27 06:00:57 2015] usb 3-1: Device not responding to setup address.
[Sun Sep 27 06:00:58 2015] usb 3-1: device not accepting address 19, error -71
[Sun Sep 27 06:00:58 2015] usb 3-1: new full-speed USB device number 20 using xhci_hcd
[Sun Sep 27 06:00:58 2015] usb 3-1: Device not responding to setup address.
[Sun Sep 27 06:00:58 2015] usb 3-1: Device not responding to setup address.
[Sun Sep 27 06:00:58 2015] usb 3-1: device not accepting address 20, error -71
[Sun Sep 27 06:00:58 2015] usb usb3-port1: unable to enumerate USB device

Oh snap! I'm torn on what to do... buying a replacement is doable, but this one was limited edition and a replacement wouldn't be the same cool colour scheme! Maybe there's a clue to what went wrong inside the unit?

Article continues here! KEEP READING, YOU