Latest Entries »

A few posts back I was whining heavily about the gyrations it was taking to get an arcade emulator running well on a Raspberry Pi.  This had nothing at all to do with the cpu capability of the Pi (especially since upgrading to a Pi 2), but was all about the nightmares of Linux configuration, and to some extent, the less than stellar support for Linux by the makers of the arcade control hardware.

The guy who runs the joystick company had convinced me to send back the stick’s circuit board so that it could be upgraded (one time process) to support user-reflashable firmware and better Linux support: no need to recompile a custom kernel and all that.  Well, it took a month for the round trip to England and back, but it did as he advertised. But of course, there’s a catch.  The new firmware uses a completely different technique to upload the joystick control maps than the old firmware version. 

This is where it gets technical and ugly: the old version sent USB control setup packets to the default control channel, while the new one uses HID output reports to the third of three separate endpoints and HID interfaces.  Worse, the guy who wrote the original Linux utility was no longer available to lend assistance.

I know a fair amount about USB, but this went way deeper than I was used to. I also hadn’t monkeyed with any C or C++ in a LONG time.  I had to download and read significant hunks of the USB spec, the hid spec, and some pretty sparse documentation for some abandoned Linux libraries, and restructure and rewrite some decent hunks of the original app.

Shortening this long story, in a few hours of tinkering on and off over the course of about a day, I was able to completely upgrade the original app to enumerate the correct HID interface, navigate the path to the correct report descriptor, and output the correct sequences of bytes to successfully reconfigure the stick on demand. At the same time, I preserved the original logic for anyone using the older stick firmware and made the whole thing completely transparent to the user, while at the same time adding more robust error checking and fixing one or two other small nits.

Then I wrapped the whole thing back up and posted it to github. 🙂 Not too shabby for this longtime program manager.  I have to say, it’s been teaching the APCS class for the last two years that has given me the confidence in my own coding skills again to tackle stuff like this.  Yes, my degree was in CS, but that was almost 25 years ago and boy, those muscles were a bit rusty.


Well, last time I posted I mentioned I’d put up a kickstarter to make some more SP-4 SCSI boards for other Ensoniq TS owners.  There may not be all that many of those people left – we didn’t make the 21 that I needed to be able to fund the kickstarter and to get the price down aggressively via volume.

But I did have enough real backers to fill some orders anyway: I funded the small run myself, and I’m happy to say that I just completed mailing the short run of 6 fully assembled units to people all over the world – France, England, Czech Republic, and the U.S.!

Here are my little babies, just before packing them up to go out the door:


That was a fun project!

As a side note: I was pretty surprised by the crazy Kickstarter “pyramid” that starts as soon as you put a project up there.  People start pledging a dollar to you, asking that you do the same for them, hopefully as a means of driving traffic back to their kickstarter, and hoping that yours won’t succeed so they’ll never have to pay up.  And the bullshit personalized spam for offers to sell you the magic secrets to getting the backers you need, and so forth.  What a nuisance.

Last week I got some more parts from which were added to the cardboard controller box without too much hassle.  The first was a weighted arcade spinner control for games like Tempest, Arkanoid, Warlords and anything else that had a paddle controller.  (In essence, it’s a one-axis mouse.) It feels great in the hand but you have to adjust each game’s sensitivity to fairly closely match the original hardware or it may not behave right, doing things like moving “backward” if you spin the knob too fast.  I found a great page to help with this here, which tells you the exact conversion factor for the 1200-pulses-per-rotation Ultimarc controller to most of the older games which typically had much lower resolution encoders.

I also got a full-size trackball (3″ diameter”), because let’s face it, playing Centipede, Crystal Castles, or Missile Command with a joystick is just wrong.

But that’s not what I’m here to talk about today.  What I really wanted to talk about was HDMI video on the Raspberry Pi.  If you’ve read this blog long enough (which is effectively nobody but me), you know that a few years ago I did a whole bunch of HDMI-related test system development at work.  So I know far more about the ins and outs of HDMI that anybody really should have to, but it didn’t really help today…

In figuring out what sort of display to put into this arcade build, the obvious solution is take advantage of the Pi’s built-in HDMI output, which provides an all-digital link directly to an LCD monitor and digital audio as well.  This is a good thing because the Pi’s analog headphone jack is well known for having a lot of noise, for arcane reasons that aren’t worth getting into here.  Adafruit, as a major US purveyor of RPi accessories, has several very nice little LCD displays perfectly suited to embedding into a project at various sizes and resolutions.  They’ve sourced the displays from various Chinese manufacturers and seem to have paired most of them with one from a family of little driver boards that they’re getting from another Chinese manufacturer that does the work of converting the HDMI input to the LVDS standard that the panels natively require.  In particular, the one I chose is 10.1″ diagonal and has a native resolution of 1280×800, which does not quite match the “HDTV” mid-range standard size of 1280×720. This mismatch seems to be typical for small LCDs for some reason.  This matters.

The driver board interrogates the connected LCD panel and determines its native resolution, and then in turn communicates the capabilities of the display back to the computer via the HDMI cable using a standard format called EDID that describes the pixel size of the display and various timing parameters so that the computer can generate video that the display will know how to deal with.  There are several “standard” modes defined by the HDMI spec at typical TV frame sizes, and there are also many other standard modes defined for computer monitors using the same method.  The difference is that the standard for computer monitors does not include audio, while HDMI does, so when a HDMI sender thinks it’s attached to a computer monitor, it stops sending audio.

So we hook this thing up to the Raspberry Pi, and it claims to be a computer monitor, so not surprisingly, no audio comes out.  Well, the Raspberry Pi people were pretty smart and figured this out a long time ago, and added a boot-time setting that is supposed to force the Pi to produce HDMI audio even if the monitor doesn’t claim to support it.  Trouble is, it doesn’t work.  At least not with this particular monitor.  Now, you can force the Pi to produce an “HDMI standard” resolution of video, and then the audio starts working the way it’s supposed to, except then the driver board produces a resized picture at something other than the panel’s native resolution, which while not awful, is not as sharp as it could be. I just want sharp video AND actual audio output. Not too much to ask for, is it?

After Adafruit’s recommended settings failed to produce the desired results after several hours of putzing around with this, trying in vain to use the settings recommended on their site, and a large quantity of unsuccessful reboots and experiments with other settings, I had to give up and settle for a little bit of scaling. Even Adafruit, the seller of the panel, hasn’t figured this part out, but neither do they warn anybody – their forum has a thread full of people wanting to return the monitor, who all think (like I almost did) that it’s defective because they can’t get any sound out of it (with the recommended settings).

I just wanna play some games now!

Linux setup nightmares

So in that last post, I hinted that getting the user-programmable joystick working properly on Raspberry Pi’s Linux OS was, well, less than ideal.  Here’s just how non-ideal it was:


  1. Download and install tools.
  2. Run tools and play around to your heart’s content.
  3. Walk around with a silly glow on your face.


  1. Linux joystick configuration utility has a link on the manufacturer’s download page.
  2. Tool must be compiled on the Pi’s particular Linux release. (This is pretty common since Linux runs on all kinds of different processors, and this tool is not part of the “standard” OS.)
  3. Tool requires libhid library to compile.  Locate and download libhid library source.  Account must be created on a Debian archive site before download is possible.
  4. Libhid requires libusb and lib-usbcompat libraries to compile.  Locate and download libusb/lib-usbcompat sources.
  5. Libhid needs to be manually patched before it will compile properly.  Locate blog post from other unlucky user who, luckily for me, has already endured and documented all this pain, with the appropriate fixes.
  6. With libraries compiled and installed, now the joystick utility can be compiled.
  7. Discover another recommended manual patch, this one to the joystick utility’s source code, apply patch and compile again.
  8. Running the utility to reconfigure the joystick works successfully, except the joystick is dropped by the Linux kernel’s USB HID driver after reconfiguration, leaving it inoperative.
  9. Follow instructions from previous blogger to create manual scripts to allow manual re-binding of the stick to the HID driver after uploading revised configurations.
  10. Discover that the Linux kernel driver also filters out half of the valid joystick location values with any of the customized configurations.  Anonymous comment on previous blog indicates a line in the kernel HID driver that can be commented out to disable overzealous validation of stick’s output values.
  11. Download entire RPi Raspbian Linux kernel source.
  12. Modify 3 lines of code.
  13. Recompile entire Linux kernel with Adafruit’s virtual-machine kernel-o-matic. (A breath of fresh air, something easy in a tedious process).
  14. Install new kernel and cross fingers.  Luckily, it boots correctly and doesn’t brick the device. (If you’re attempting to reproduce my pain, make sure you choose the branch that matches your existing kernel!)
  15. Validate that joystick now functions properly.
  16. Discover that during some bootups, Joystick is detected as “second” joystick rather than first, causing failure to detect stick in rickety old emulator program.
  17. Research and create “udev rules” which allow particular devices to be forced to have specific names in the OS, so as not to make the rickety old emulator grumpy.

Linux:  It’s the way of the future, you know.

I’m late to the party, but I started building a retro arcade machine using a $35 Raspberry Pi as the computer. The various buttons, joysticks, and other bits of control hardware will likely cost at least 5-6x times that amount by the time the whole thing is done.

I’m doing the Linux setup and prototyping control layouts (more about that tomorrow) but I’m hoping my buddy Raman with the awesome wood shop will help build a real cabinet for it when we’re ready. The thing I want to do that’s different from most of the emulator builds people usually do is that I want the control panel to lift out like a fridge shelf and be replaceable. That way when you want to play a game like Tempest or Centipede that needed a spinner or trackball, you just replace the controls. The rest of the time you can have a typical one or two stick-and-buttons setup, but this way the cabinet doesn’t need to be a mile wide to accommodate all the controls at once.

At the moment, though, it looks more like, well, “3rdWorldCade.” But it works great. Thanks to Amazon for the flexible and sturdy “building materials framework!”



Well, there seem to be some people interested in getting a shiny new SP-4 clone of their very own, so I have launched a Kickstarter to fund the manufacturing of a new run.  By building in bulk, everyone gets them for a lower price – $110USD, which is far less than Ensoniq charged when they were new!  Shipping in the US will also be free, $15 anywhere else in the world.

There are 30 days to complete the funding (it’s an all or nothing proposition, like all Kickstarters).

See more details and back the project yourself at:

A few versions of iTunes back, upgrades started failing to install for some reason on one of my machines, which I ultimately solved with a Microsoft Fix-It. Whatever arcane magic it did allowed iTunes to be installed again, but ever since then the Apple Software Update program had an annoying behavior: Even though the latest iTunes would install successfully, ASU would keep popping up and telling me that it still needed to be installed… Again. And again.

I tried just about everything I could think of, short of a complete Windows nuke & pave. Web searches, uninstalling all Apple products then terminating with prejudice all turds left on disk and in the registry.. And there was a LOT of stuff on the disk – Appdata, ProgramData, Common Files… Nothing worked.

Today I finally cracked it- I used the Sysinternals ProcMon tool to log the app’s behavior while it determined required updates and also took a look at the Fiddler traces of traffic between it and Apple’s app catalog server.

The key seemed to be that the app was doing a pretty categorical walk through the entire HKCR/Installer/UpgradeCodes branch, each entry in which seems to point to an actual installed app description branch. However, the UpgradeCodes entry that pointed to the installed iTunes app also had a second entry in it that pointed nowhere, probably left behind when things burped the first time. after uninstalling iTunes one more time, only the dead link was left. I deleted it by hand, reinstalled iTunes, and finally, ASU thinks it’s completely up to date. Happy dance!

Today I received an antique in the mail.  A rather ancient SCSI CD-ROM drive, in an external enclosure, and an equally crusty 50-pin to DB-25 “Mac style” SCSI cable from  It takes me back to the good old days of somewhere around 1993-1995, when I had boatloads of external hard drives in cases a lot like this one. But the good news: After hooking it up to my Ensoniq keyboard with the SCSI board I described in the last post, success! I can load lots of different sounds from CD-ROMs now.  It’s nice when things work the first time. OK, there was one little glitch – the memory expansion I installed a month or so ago turned out to be faulty.  After loading up sampled sounds I was hearing pops and clicks where I was sure there weren’t supposed to be any.  I was a little panicky at first that somehow the SCSI interface was corrupting the data or there was a noisy signal, but then I remembered that I’d never really tested the sample RAM after installing it.  I popped the factory SIMMs back in and all the noise problems immediately went away.  So it’s just bad memory from eBay. Phew.  Time to go see if I can get the seller to exchange it for a different set.

Back in the early 90′s I bought a pretty deluxe keyboard synth, the Ensoniq TS-12. This is a pretty large and heavy beast with a 76-key weighted keyboard. The synthesis is based on sample playback with a large ROM collection, a powerful digital effects engine for reverb, chorus, delay, etc., a built-in sequencer for recording, plus the ability to load additional samples off of 3.5″ floppy disks to onboard DRAM. (It shipped with 2MB, which I’ve since upgraded to 8.)  There was also an option which very few people took advantage of, which was to add a proprietary SCSI interface to the unit which would allow much faster loading of samples, with large libraries available using a CD-ROM drive, or a hard drive formatted and loaded up by one of Ensoniq’s other units at the time, the ASR-10, which was capable of creating and writing new sample patches. They shared essentially the same playback engine and effects chip. The TS-12′s built-in SCSI interface software, however, was purely read-only.

The TS-10 and 12 still do pretty well on the eBay vintage synth market. Ensoniq was, unfortunately, bought up by Creative Labs in the late 90’s for their PC soundcard business, and not much later, shut down altogether. Creative massively overexpanded during this period and couldn’t sustain their growth.  This is a bit of a tragedy, since both Ensoniq and E-mu (another classic sampler synth company bought by Creative that suffered the same fate) were top-notch in their field but are now no longer around to support their earlier products.

Recently while dorking around with my TS-12 and realizing that performing some of the factory expansions would be both cheap and easy (old 4MB SIMMs and 256KB static RAM chips cost next to nothing), I decided that I wanted to tackle the SCSI expansion as well.  Unfortunately, the SP-4 SCSI expansion boards were never produced in large supply and they’re evidently fairly rare to encounter for sale.  In poking around at some of the old completed eBay sales, by looking at pictures of the thing I realized that the board itself would be quite simple to reverse engineer, if only I could find the right controller chip.  Everything else was stone simple – a 7805 regulator, a pullup resistor, some terminator resistor networks, and a few aluminum electrolytic and ceramic caps.  I could even see where most of the traces went.

The first pic I found wasn’t great for reading the numbers off the chip, but I could just make out the logo… AMD?

An old ebay description pic of the SP-4

With a little more poking around using Google image search, I was able to find a better pic and could read off the numbers: The controller is indeed an old AMD 33C93A-JA16, a fairly large 44-pin PLCC, and a datasheet was then also readily turned up online.  Also, the better pics showed both sides of the board, allowing me to determine the paths of the vast majority of the traces and build a fresh schematic in DipTrace.  (I find DipTrace far easier to comprehend than Eagle, despite Eagle’s foothold in the hobbyist community.)  Another enthusiast from one of the internet forums had actually done exactly this same project several years back and shared his own schematic, which was quite nice, since it allowed me to verify that I had the netlist right.  No errors found relative to the other guy’s, so good job there.

Speeds for old SCSI-1 are glacially slow by today’s standards (a whopping 5Mhz!) and the electrical spec is single ended rather than differential, so there are no big worries about signal skew, controlled impedances, or anything like that.  Still, I was careful to optimize the layout as best I could with the shortest routings I could find, significant ground plane copper pours on both sides and between traces where possible, and minimization of unnecessary vias.  I kept the decoupling caps as close as possible to the terminator networks and the controller chip’s power input.

Before it’d be worth spending money to make boards, though, I needed to find a source for the obsolete chip.  An onshore company in California was perfectly happy to quote me prices for low volumes of the chip, but the price (well over $100 for a single chip, although with very steep discounts for chips 2->N) was too daunting for a hobby project.  It seemed like it was time to plumb the depths of the Chinese online chip vendors.  For no particular reason, I went with one called UTSource, which said they’d send one for a whopping 7 bucks, including shipping.  I was a little worried about fraud or getting counterfeit goods, but hey, for that little up front, there wasn’t much of anything to lose.  I went for it – and about a week a later, as promised, it arrived nicely packaged and protected, as one would hope, with good bubble wrap and sealed in a labeled anti-static bag.  Whoohoo! Assuming that the chip isn’t counterfeit and entirely nonfunctional, we might be in business…

With that hurdle out of the way, it was time to get a board made and collect the rest of the parts.  Digi-key supplied the connectors and other components, and OSHpark made a batch of 3 boards with their nice blue soldermask. (That deep blue is my favorite color.  So much nicer than puke green.)

Here’s the bare board as it arrived:  Something about the plated connectors just looks so pretty.

My reverse-engineered SP-4

I also ordered a nifty little mounting plate from They’re a little pricy but they did a great job. This piece is a requirement to mount the board within the synth’s case.


It was finally time to put the whole thing together: My workplace has a really nice “Maker Garage” with all sorts of nifty tools, including a cheap but functional reflow oven purchased off eBay from another Chinese company.  I could easily hand-solder the PLCC, but why? Squeegee down a little solder paste with a stencil from, turn on the oven, and about 5 minutes later I had a perfectly soldered PLCC onboard.  Next time, though, I think I’ll make my own stencils using the Garage’s laser cutter and some blank mylar.  Anyone know a good tool for converting Gerbers to some easily laserable vector format?

Hand solder the simple passive stuff, and voila:


(Edit: Yes, I know the soldering job looks lousy, but it’s actually better than that. I was in such a hurry to try the thing out that I shot the picture before cleaning off the flux that had spattered around the backside.)

After inserting into the TS-12 and attaching the ribbon cable to the main system board, it comes up perfectly as expected in the disk menu with a brand new “SCSI” option!  The fact that all the needed driver software for the board already exists in ROM on every TS system board makes this possible without having to find an original unit first: Big smiles all around.  Now to go find that ancient SCSI CD-ROM drive to try it out with!

I did find a few flaws in my design during the assembly of the prototype, which I can easily fix if I decide to make any more: I’m toying with the idea of putting up a kickstarter to make some more of these for any other vintage synth folks out there who may need one, given the lack of availability of the original article.

1) Switch to all surface mount parts for ease of assembly, and lower cost, minus the through-hole connectors and the heatsunk regulator: New board design is ready.

2) The electrolytic axial lead caps I chose to match the original pics were too big for the footprint I used in the layout.  Whoops!  They still work fine, but I’ve found more suitable SMT caps for any future runs.

3) In the new board layout, all pins connected to ground use thermal standoff traces.  Direct connection to the copper pour creates a huge thermal mass that has to be heated up for quite a while before the solder will make a clean connection to the board, especially with lead-free solder, so skinny traces allow the pads to heat up more easily while still getting a good electrical ground.  I’ll also spend more time cleaning off the flux on any future attempts, although this stuff is no-clean and doesn’t present a shorting risk.  I just don’t like the messy bottom side.  More surface mount components also helps reduce the need for that anyway.

3) Didn’t realize that my measurements for the panel were a few mm off: First, the posts that the panel bolts to are NOT laid out parallel to the horizontal plane of the board for some unfathomable reason, one is a few mm lower than the other.  As a result, my prototype sits just slightly diagonally within the case since my slots were drilled horizontal to the board. :-/  Think I want to definitely fix that one so it doesn’t look goofy.  At the same time, I can fix the bug in the panel design file that caused the slots to be routed 0.5mm too shallow, so I had to manually complete the cuts with a dremel, resulting in a slightly messy edge, as you can see above.  It’s invisible once it’s mounted in the unit, but I know it’s there. 🙂 (Edit: I ordered a modified version of the panel with the holes drilled in the right place.  Now it sits perfectly in the case!)

4) The label on the board reads “Digital Reproductions” while the panel says “Electronic Reproductions.”  I think I like the former better, but I should at least be consistent.

Next update after I get an actual CD-ROM to try out…

If there are any vintage Ensoniq enthusiasts out there who think they might want one of these for their very own, leave a comment!  I’m not looking to make a profit and I’m totally happy to make some more to help out the community.  The more takers I can find the cheaper I can make them.  Maybe someone else out there might be interested in one of these fine “Digital Reproductions” products?

The Bone Clocks

I hadn’t read any of David Mitchell’s prior books, but I did see the movie of Cloud Atlas and found myself taken in by the story.  So when I discovered he’d recently published something new I thought I’d give it a shot.  700 pages later, I’ve finished The Bone Clocks.  I really, really enjoyed it.  Like Cloud Atlas it moves along in 100 page chunks following a largely consistent set of characters jumping ahead 10 or 15 years per chunk, and each one is told from the point of view of a different character.  Some come and some go throughout the story, but there is a clear through line.

There’s an interesting and engaging fantasy/sci-fi element woven throughout the entire book, but you only get to see very small pieces of it for the first 400 pages, leaving you wondering where it’s all going and if you’re ever going to be given full disclosure about “what’s going on.”  If you like fantasy and sci-fi, you will indeed be fully rewarded by the end.  If you don’t, well, you’re probably not going to enjoy that section too much.  Luckily I find myself in the former camp, and found it extremely satisfying.

However, the final section of the story is far too successful in pushing all of my societal-ills buttons:  Climate change and fossil-fuel depletion leads to the loss in the Western world of most of the modern staples we take for granted. Basic transportation: only for security forces, which soon become the oppressors rather than the protectors. Adequate electricity, food you don’t grow yourself, relatively basic medicines for the chronically ill (e.g. insulin): all gone, or rapidly on their way out the door. Even basic connection to family members or news of the rest of the world via the Net or even broadcast radio: failing.  This decline, predictably, leads during this section to the beginnings of anarchy, and the appearance of strongmen and militias.  Those with the weapons start taking what they want from the weak, and there’s also a resurgence of religious persecution by the weak-minded against the non-believers. The whole thing is pervaded by a deepening and fatalistic depression in those old enough to remember when things were better only a few years ago, with the certainty that things are getting worse and aren’t going to be getting better within what remains of their lifetimes.  While there is, thankfully, a satisfying if not entirely happy ending to this tome, the intensely believable realism of this final section depressed the hell out of me enough to leave me barely psychologically functional for the better part of the day in which I read it.  It feels that plausible, and strikes just too close to home.  For that little while, I was in the shoes of Holly, the lead character, and frankly, I hope I don’t live long enough to see it come true.

Bone Clocks, I dub thee A Great Book, but I find myself a fair bit more shaken up in the end than I really would like to be.  I attribute this to my own psychological ills, after all, there is a long proud history of post-apocalyptic literature and film, even pre-apocalyptic, I suppose, but few have managed to touch me as deeply by painting such a careful and thorough picture of this kind of all-too-believable outcome.  Well Done, and I Hate You, Mr. Mitchell, all at once.

%d bloggers like this: