Category: OSCar

It does seem odd to make part 2 of this OSCar series about how not to give up. Especially as this is one of my actual jobs.

Here’s the thing: I spend a lot of time working with just myself and the ghost of Chris Huggett. This project will have taken me over a year by the time the synth is ready to demonstrate (hopefully at Superbooth in May). Even Paul Whittington, who is in charge of the OSCar brand, spends most of his time running PWG and dealing with the problems of supply chains, distributors, retailers, and customers. Being a company director is, after all, a picaresque adventure which is largely out of your control but always your responsibility. Anyway, long story short, his focus is not always on making the next product.

Meanwhile, I go for weeks without having anything playable, or even explicable, to show for my efforts. This stage of the project, with a desk full of hardware with a few desultory blinking lights and some quickly-moving voltages, is largely about getting the psychological barriers out of the way.

This post is not:

1. The usual ‘go out and walk occasionally’ post: I went and took a walk a fortnight ago.
2. A ‘beast mode’ post about how to distil measurable productivity from every mean minute of your life on this planet. Honestly, those people think they’re winning, but in any healthy society they would envy the homeless.
3. A post exploring technical best practice. That theme, I hope, will be mostly implicit in everything I write.

If this about anything, it’s accepting the fact that most of the things that make our planet a nice place to live were embroidered on a fabric of pissing about in company time. (You’ll find this idea expressed in myriad ways by everybody whose books you like to read, whose music you like to listen to, and whose company you enjoy.) So this, and writing about it, is basically how I keep myself in a frame of mind to finish a long, solo project that began with the intention of bringing people some joy. If you’re serious about that, it can feel like a zero-sum game.

Designing and building the hardware part was fun in its own right: I’m lucky to appreciate this stage of proceedings as a miniature challenge, on a par with a cryptic crossword. There are many right ways to translate a design to a new platform, and this choice is quite satisfying.

The doldrums for me began when I had a large amount of 1980s-era firmware to port before my synthesiser would do anything at all. I can’t just replace it with bits of the Mantis that I’d already written myself: authenticity to the original OSCar is the principal point of the exercise. First, appraise it critically and completely. Then, translate it into C for a new platform.

Firmware is where all the complexity is hidden, and people care about whether it’s done just right. The problem is that it wasn’t, really: it was written by an electronic engineer in 1983. A masterpiece in terseness it may be: scarcely a byte is wasted and the EPROM has only six left. But bugs jump out from inspection as well as in use: some weren’t noticed; others might have been, but what can you fix with six bytes free? And the user interface is of its time, which means it’s appalling.

But owning the firmware is tough. It’s high-difficulty, high-stakes, and needs to be approached with the kind of reverence that requires leaving the desk occasionally to drink tea while subjugating one’s ego. What follows is a few personal rules I made to make it more bearable.

Rule one. De-scope features that aren’t important until the end

The sequencer and arpeggiator are big parts of OSCar, but the synth is playable and demonstrable without them. 90% of the fun is in the way the thing plays, sounds, and responds as a simple instrument. We could take the prototype to Superbooth, let people play it, and those features would be missed, but not desperately. So I’ve decided to afford them no thought until I have to.

Meanwhile, the cassette interface probably won’t make the final unit because there’s no point in having it there. More on that later, and probably in a later post.

Rule two. Playability always wins

This is really an extension of rule one. Once I’d brought up the basic hardware, and proved to myself (for example) that the power supplies, timers, USB, and MIDI all work, the question was how to port Chris’s firmware. There’s thousands of lines of it, and it all has to end up inside somehow.

What, then, to do next? If I’m optimising for my own motivation, the right answer is whatever gets us closest to having an enjoyable musical instrument. So I started with the wave tables and oscillators, just so I can bodge a connector onto a test pin and hear the synth making a noise. Then I got the pitch conversions working so those waveforms can be made to respond to musical pitch. Next, I’ll get the key scanner logic going so I can play the keyboard. That will provide a very bare experience with no presets, no filters or envelopes, no pitch bend, and no real voice management. It’ll sound like a Stylophone. But it also gets me to a stage where I can play to people, get some pleasure out of my work, and hear all subsequent progress.

There are a few awkward corners of hardware that still aren’t completely tested or don’t work properly. But, as no deadline looms, even locking the PCB design is a secondary priority to having something that plays. At worst, I’ll find something off with the filters, and have to spend a day or two fiddling with resistor values and green wire. But a confrontation with my failure at the hands of the physical world is less humiliating if I can suck it up while playing a line of Bach. Also, having something playable makes debugging somewhat easier.

Rule three. Make progress visible

OSCar lends itself well to a progress-o-gram. I last messed with these when I was writing my PhD thesis at the end of 2004:

It gave me a visual evidence of the thesis word count growing. I posted it on this blog so people would hold me to account. (It was eventually submitted on 30th March 2005 at 45,508 words, 65 figures, and 108 references. Not a long thesis, but it got me there.)

With OSCar, there are 8 kilobytes of Z80 code to inspect, take ownership of, and port onto the modern platform. (8 KiB doesn’t sound a lot, but written in assembler on an 8-bit CISC processor, believe me it is.) Porting the firmware is a process of two distinct stages. The first job is assimilation. I start with a combination of my own source code (starting with an automatic disassembly the ROM and, with the help of the hardware schematics, working out what every line did over several hundred hours), and Chris’s source code, which we recovered several months later. The exercise is to determine exactly what’s going on inside the synth.

You’d think it’d be easier to junk my own disassembly and just continue with Chris’s source code, but in practice I spend little time with his work. The reasons can be explained in a later post.

A couple of things make progress-o-grams easier than they used to be. First, we have Python for this kind of scripting nonsense. Back in the early 2000s, I had to write my own GIF compressor in Object Pascal. We also have Claude so, rather than scrape the resources together to generate my own chart, I can just write a spec and see what it comes out with.

Here, then, is where we stood a couple of days ago:

The module names are from Chris’s source code: my version, of course, came out as one big lump. The striped areas are the ones I’m leaving until last because of rule one. The reason why I went through the whole cassette interface is because we have one old cassette, full of drop-outs, that contains original presets followed by a couple of demo songs by an unknown band, and then an album by The Police. At the time, we thought this was our last stand.

When users bought the MIDI retrofit, they were provided with a pre-recorded cassette that allowed them to load the original factory presets onto a new battery-protected RAM chip, because there was no longer any room for them in ROM. In a world where the compact cassette was the only reusable storage medium for music, it’s unlikely that anyone besides the Oxford Synthesiser Company bothered to preserve this data for posterity.

I decoded the old cassette routines, just so I could recover what I could from the cassette. It is, to say the least, a nonstandard modulation scheme. Again, that’ll be another post.

Fortunately, on a floppy disk backup of Chris’s dated 1983, I found the source file for the original ROM-based presets that we’d thought to be lost to history. Problem solved.

But the graph is important, because what often looks like endless, contextless, meaningless toil suddenly turns into painting a wall. As I scroll between different date-stamped versions, the wall turns red to orange to yellow to green, and I gain some small hit of dopamine that cannot be found in the minutiae of the envelope gating and triggering routines.

I gave a couple of talks last year: one to the AES that (unfortunately and mistakenly) wasn’t recorded, and one a couple of months later to ADC which was, but hasn’t officially made its way to YouTube.

If you follow my work (meaning: you’re one of my more tolerant personal friends or a fan of the OSC OSCar or PWM synths), you’ll know that I accepted the mission to bring a classic 1980s synthesiser back into current production.

OSCar is a beautiful instrument, rooted in the centre of a very interesting time and culture. Released in 1983 and remaining in production for four years, it’s a hybrid of 8-bit digital trickery and old analogue electronics that sounds and behaves like almost nothing you can buy today, and evokes the sound and history of music of the 80s and 90s. OSCar found its way into a lot of iconic music, even years after it ceased production. To have such evocative sounds at your fingertips is one of the reasons to remake it faithfully; the second is that the real thing is beset by the same problems as anything else of its age.

Rarity is one such problem: getting hold of an original OSCar is expensive. They’ve all got NiCad batteries in them that eventually dispel their electrolyte, damaging the circuit board and losing the original presets. They were made in England at a time when that was no guarantee of high build quality. They work on knife-edge timings to squeeze all the performance they can out of some very basic tech. Drop one on its end, and you’ll quickly find that some of the parts aren’t trivially replaceable. When modern analogue microchips must replace burnt-out old ones, they don’t often sound quite the same as the originals did. As it ages and its components drift, you get reliability issues that are hard to identify. Plug it into a modern system with modern expectations, and you’ll quickly find out how convenient and versatile a synth which needed a retrofit kit to deal with the arrival of MIDI isn’t. And so on. It’s like running a vintage car: you need to be either a competent mechanic, or the very close friend of one, to keep it running. And you wouldn’t want to let it out of your sight.

A well-executed remake makes sense: we’ve demonstrated a demand for it, as long as we get it right. Aside from the fact that this is a big ‘if’, remakes come with a host of caveats:

• A straight clone would rely on microchips that are no longer in production, so it’d be dependent on finding new-old-stock digital and analogue parts.
• Legally, making a new-old-stock clone is a grey area because there’s absolutely no way that a typical box containing early microprocessors and linear power supplies would pass modern FCC/CE legislation without a lot of work. People who sell modern clones duck such issues by selling direct, in small batches, to customers who understand and tolerate such issues. To do it on a serious commercial scale, with the noise that entails, means doing it legally. Major internal reappraisal and redesign is a requirement, but comes with a duty to preserve the original’s exact characteristics.
• The moment I reappraise such a design, my fingers itch to fix aspects of it that made sense at the time but no longer do. This isn’t about ego: this is about making quieter and more efficient circuitry. It’s about respecting the fact that MIDI and power are more conveniently delivered via USB than DIN connectors and a mains transformer these days. It’s about a user interface that was designed contemporaneously with the timers on video recorders, the awkwardness of which became a cliche for stand-up comedians. And so on.
• I once remade the title music for some 1980s Magnetic Scrolls text adventures for Strand Games: I did three soundtracks, only one of which has yet made it into a released title. The first and most important lesson one learns in a reboot, especially when customers really care about the end result, is that they’re looking for an experience that feels as good as they remember it to be, in the light of their far higher expectations after immersion in half a century of miraculous technological progress. It’s not sufficient to make one as good as the original actually was. For the soundtracks, I needed to rearrange a lot of the music and add or change parts just to make it listenable. Here as well as there I need to be an artist, curator, and critic as much as a technician and engineer, at every stage of the process. The vision also needs time to mature but (to paraphrase Leonard Bernstein) never quite enough time.

OSCar Rebirth (a working title for now) has been announced for preorder. We have Chris Huggett’s personal OSCar but that is something of a holy relic. I made a part-for-part clone (ish) of its original circuitry by sourcing parts on eBay and transcribing his hand-drawn schematics so that we had a playable, abusable, travelling instrument for comparison. It’s not pretty, but it’s been around the country testing demand, and is played in the video in the preceding link. The OSCar Rebirth’s prospective price has been announced too, and I’m quietly completing the electronics and firmware, along with making about ten thousand creative decisions that need to be made to finish such a thing. (With the help of Paul Whittington, obviously).

But one thing is clear about this: it’s going to be a relatively short-run item, involving a hell of a lot of work. This isn’t a Swiss sociopath’s smash-and-grab cash-in. It’s a licensed, official, world-is-watching, mess-it-up-at-your-peril undertaking. Our customers will be paying rather more than a two-voice synth with a similar spec would usually cost these days — albeit a good deal less than the cost of a mint condition used OSCar — so it’s not for everybody. In return, they’ll be getting the most considered product I [immodestly] proclaim anybody could make without escaping the bounds of what an OSCar is and should be. Yet another reason for me to stay awake all night.

It dawned on me that this elevates OSCar to the closest I’ve come to the realm of luxury goods. It involves most of what I’ve spent thirty years getting good at. The story and craft behind the new OSCar, and the demonstration of effort involved, will be just as important as the finished product. It will justify an exclusive price to a sophisticated audience, and will help to satisfy those customers and reviewers who will necessarily be asking if we’re taking the piss. To explain why the answer is ‘no, it’s actually exceptional value’, I’ll be keeping a diary here, diving more deeply into the things I talked about at ADC, and sharing details, images and material as commercial sensitivity permits. I’m about a year into this project (not, fortunately, full-time: the joys of consultancy) so the timeline might jump around a bit.

I’ve created a new page, supperware.net/oscar, to index only OSCar-related entries in the blog.