I was getting bent out of shape that I needed to somehow reconstruct the system clock out of the data stored inside a delay line. But fooling around with an old discrete delay line simulation in a circuit simulator by replacing the giant stack of flip flops with a proper length delay line shows that I don’t need to be too concerned
As long as
The delay line stays a constant delay length in terms of time (dubious)
The system clock stays a constant speed (actually very easy because amazingly stable crystal oscillators are trivial nowadays)
Delay lines varying in time is
Highly probable with any sort of rotating media (magnetic drums, etc)
Less likely for “solid state” delay lines such as acoustic torsion delay wire.
Unknown for any other technology (tape loops?)
For rotating media or tape loops, it would probably be good to assume they require a second timing track. It’s somewhat of a “waste” of media density, but you should only need one per media – so one track on a drum or one track on the tape. You can have as many other tracks as you can cram on there.
For the more stable media, where the main drift is due to temperature, there could be some type of calibration mode where a signal is put into the delay line and then compared to the current clock speed. The clock speed could then be adjusted to match. This could even be automatic – perhaps something you would perform once on startup, and then once again when the machine is up to operating temperature. Of course any thing that is temperature dependent is probably best handled by installing a heater and keeping it at a steady 100degF (or whatever) no matter what.
Aka “ADDDA” or “AuDiDeDrAr” or “aww dee dee drawer” or “A3DA”
I’ve had this idea bouncing around in my head that you could use 1-bit wide DRAM as a delay line if you simply counted up through it’s addresses, reading and writing as you go. 1-bit wide DRAM like the M3764 have separate pins for Data In and Data Out which makes the read-and-write method easier.
The light bulb moment was coming across an old post on diystompboxes.com where one commenter provides a short snippet of code to do a Delta-Sigma analog to digital converter using the Arduino’s analog comparator pins. I had planned to do this purely in software by using the normal ADC pins and then calculating the Delta myself. But the built-in comparator makes this dead simple!
I have a small collection of vintage calculators that I stumbled into collecting. I found one at a garage sale, and then one was given to me, then I found a neat one on eBay for a good price… Before I knew it, I was a calculator collector.
I actually use most of them despite having a great calculator app on my phone because I prefer their physical interfaces. I have one on each desk and one in my bag so I don’t have to go searching. I don’t have that many bags and desks though so there is also a small stash in a drawer.
My latest addition is a National Semiconductor 4510 Mathematician from the mid 70s. It has an 8 digit red LED display and runs on a 9 volt battery. There is a jack on the top edge for connecting a wall supply if you’ve got a lot of math to do.
It is in great condition and the seller even included a brand new battery. It is one of the lesser RPN calculators of the 70s and not expensive. Like most of my collection, is not valuable but it is uncommon.
Conway’s Game of Life (CGoL)has always fascinated me. It is probably the most well known of all cellular automata and also probably the most intuitive. Yet even simple patterns can turn into complex sequences of shapes, patterns, and noise.
Years ago, when learning about the HTML5 WebAudio API, I came across a fun little demo called Blips of Life by Mike M. Fleming. Use your mouse to draw some dots and then click the triangle Play icon in the bottom left. Great, right? I’ll let you play around with that for a while. Leave it running while you read, perhaps?
When it came time to start prototyping new modules for my modular synth, I was inspired to recreate Mike’s work in hardware. I didn’t have exactly the parts to fully recreate his Blips of Life, but using the parts I had in hand I made a prototype.
My version has only an 8×8 grid and only has a major pentatonic scale. The small grid means that there are fewer possible patterns, although not so few it is monotonous. The major pentatonic scale is fine. The largest problem with the prototype is that I used CircuitPython to write it, which has no interrupt support. I love Adafruit – they’re a great company and they design terrific boards. But removing interrupts from their fork of MicroPython has cut several projects short.
The prototype works pretty well and exposed a new design challenge: how do you deal with “games” that end in loops? They’re a subset of steady state patterns in CGoL – a pattern can go “extinct”, “steady”, or loop in a finite sequence. The first case is easy to detect and deal with. If all the cells of the grid are off, repopulate the board. You can detect a steady state by comparing the next board with the previous. If they’re identical, repopulate.
But loops can be any arbitrary length, and can step through rather complex patterns. The only way I know to detect them is to have a list of boards known to be part of or lead to a loop. I’ve got some ideas how to do that either via live loop detection or with a precomputed list of boards. As yet, the performance limitations of CircuitPython really prevent tackling it. I’ll need to reimplement the code in C++ using Arduino. Hats off to Adafruit for supporting both Python and Arduino on their boards.
I’ve continued to work on the optical ray diagram tool prototype. I added a way to measure the effective focal length (EFL) of the lens system. It isn’t automatic, but by adjusting the parameters you can align an intersection at the optical axis and read off the EFL. Obviously this should be a one button click sort of thing, but it is kind of interesting to see how the various parameters affect EFL.
My main area of interest before going to automation is identifying and coding all the various measurements that you want of a lens. To identify these, I’ve been reading the excellent Applied Optics and Optical Engineering edited by Rudolf Kingslake. Chapter 3, Photographic Objectives, traces the history of the development of lenses from the development of photography to the book’s publication in the 1960s. I would recommend either starting there if you have some familiarity with optics already. If you’re new to optical design, start with Chapter 1, Lens Design. I got my copy from the public library but you can also borrow a digital copy from the Open Library on archive.org.
I realized I should change the example lens configuration in my prototype to a Cooke Triplet after reading Chapter 3. As the book points out, a lot of modern lens designs can be traced to or analyzed as variants of the Cooke Triplet. It is also unique in being only three elements but having performance that is good enough to warrant doing the work of designing one yourself. It is also non-trivial enough that you want an automated tool to design one, so it makes a good example.
The next step will be to add proper measurements of the various aberrations and distortions. I’ll be using worked examples from Applied Optics and Optical Engineering to check the calculations of my tool. The current default configuration is from this student project in MIT OpenCourseWare by Choi, Cooper, Ong, and Smith. I think I’ve already found a discrepancy in my results so my work is cut out for me.
Over the weekend I tore down an old RCA Super8 camcorder. It came with a power supply but it had already been damaged in the past. The viewfinder showed text over static and the tape mechanism just made a horrible squealing sound.
I was interested in perhaps using the imager somehow but it seems to be damaged and not worth chasing down. The autofocus and motorized zoom work great though, so I’m hoping to use those paired with a Raspberry Pi camera. Even if I don’t ever use the motorized features, they’re manually adjustable so that will make for a nice setup.
The other electronic parts of the camera are a bit too specific to be useful. I’m hoping to reuse some of the mechanics of the tape transport in my 1/4” audio tape experiments. 8mm is larger than 1/4” (6.35mm) so I think some of the various guides and rubber pinch rollers will come in handy.
Before I send all the extra parts to the electronics recycler, I need to plug it all back together and document the connector pin outs.
I have a few prototype Eurorack modular synth modules in the works. I tend to get them working well enough to be musically interesting and then move to work on the next prototype. It’s not because I don’t plan on finishing them – it’s more that all the biggest questions are answered and I want to move on to the next prototype and answer whatever questions it is trying to answer.
This module is based around the Yamaha YM3812 chip, also known as the OPL2. You might know it as part of the capabilities of the AdLib and original Sound Blaster sound cards. Think of the classic sound of the Doom soundtrack – that’s coming out of a YM3812 (emulated or otherwise).
But you can do a lot more than what you hear on the Doom soundtrack – even though I’d be fine if that was the limit of it’s sonic capabilities. FM synthesis is “weird” in the way it can produce wild sounds that are very hard to produce with subtractive synthesis. As an added bonus, the YM3812 has multiple symmetrical channels and is this capable of impressive polyphony. One module isn’t just one voice – it’s 6. Also it has a drum synth mode… It makes sense that it is so capable if you think about all the great PC game soundtracks made with one, but it isn’t what you’d expect to be coming out of a single modular synth module.
In the modular world, you tend to break apart and de-integrate as much of the synth chain as possible. This is so you have the freedom to reconfigure the synthesis signal path in wild and fun ways. So a module with not only a complete voice but six complete voices is swimming against the current in how you typically design these things.
One outcome of such a non-modular module is the matter of the number of possible parameters available. Typically a module might have 1-4 inputs and 1-2 outputs. That’s a gross simplification but gives you an idea of the majority of signal complexity involved. A single channel of a YM3182 has about 16. And then you have 6-8 copies of those – each voice can be configured more or less independently. So we’re talking hundreds of possible inputs.
It has one output.
So on the face of it, this is a bad match. And therein lies the hypothesis of this design. “How can you adapt a YM3812 to the modular synth design norms?” How do you make it understandable to someone thinking in terms of fairly straightforward signal chains? How do you present the configuration of a YM3812 so it matches the mental model of someone used to something like the Behringer Neutron?
A Lone Voice
I can’t do anything about the output space. There is literally only a single pin for the output and there isn’t any access to the individual voices. So right off, I decided that this prototype would be a single voice. That might seem wasteful, but I can use the other voices to “mirror” the main voice to fill it out by slightly detuning them or by playing notes related by harmonics such as octaves or triad chords.
That also reduces the input space. We’re down from hundreds to a dozen or so inputs if we’re only treating this as a single voice. Some existing designs stop there, but I wanted to go further.
There are broadly two types of inputs to a voice: time varying and time invariant. The time varying inputs configure, for example, the way the amplitude of the sound changes over time. In a modular synth, input like this are controlled by other modules. So I decided to discard all time-varying parameters. Parameters like the amplitude of the voice would be modified externally using voltage controlled amplifiers (VCA) just like you would do with a standard modular signal path.
This reduces the input space by half. We’re looking at about 6 inputs. That isn’t bad – there are definitely synth modules with 6 inputs. But I wanted to go further.
The YM3812 is a digital chip. All of the OPL series of synth chips are. This is what made them such a great product for Yamaha. It was easy to make a digital chip out of silicon so they could produce the entire sound path out of a handful of parts that would take thousands of separate analog components to replicate. And because it’s digital, it’s very easy to use in a PC sound card. The CPU just sets the input registers of the chip and away you go.
In a modular synth, all of the patch paths are analog: continuous time varying signals between about -10 to 10 volts. To adapt these kind of signals to the YM3812, I would need to digitize them using an analog to digital converter (ADC). But there’s a problem here too – what sort of digital resolution should I use? If I use too low a resolution, the continuous varying signals end up being converted to broad, stair step patterns. It means your smooth subtle varying input gets turned in to sudden chunky sound changes. People call this effect “zippering” because it can cause a sound similar sound when a parameter moves through those discrete stair step values. That isn’t intrinsically bad in the world of analog synths, but you’d like to at least have the option to avoid it.
Some of the input parameters of the YM3812 have a very limited range of possible input values. As an example, the strength of the feedback from one internal voice generator to itself is controlled by just three bits. That’s only 8 possible values! That does not map well to a 20v swing input.
So I took all the parameters that did not have enough bits of configuration available to be used with an analog input off the table. I would still have them accessible, but through manual switches and control knobs. They’d be more for setting the broad mode of the voice, not for use inside the time of a single note playing. That removes a handful more inputs from consideration. In fact, you’re down to only four. That is a completely respectable number of inputs for a synth module. But I wanted to go further.
One of the interesting things about FM synthesis is that a lot of the timbre results from the mathematical ratio between the different frequencies of the oscillators involved. In the YM3812, each oscillator has 12 possible frequency multipliers to aid in defining these ratios. So while there are only 12 values for a given oscillator, there are 144 combinations between the two oscillators of each voice. Twelve steps isn’t enough for an analog input but 144 is fine. So my final reduction was to combine the two ratio inputs into a single input.
And that leaves us with just three inputs: one that controls the frequency of the voice, one that controls the amount of mixing between the two internal oscillators, and one that controls the ratio between the oscillators. To put it another way: one controls the pitch and the other two control the timbre. That sounds like a perfectly understandable module. It is still more integrated than you would see in a traditional module where the timbre modification would occur in a separate module (or sets of modules), but it is much closer.
And there you have how I arrived at the final design of the prototype. All other design considerations stem from the decision of which inputs to use: the physical layout, the specifics of how signals map to sound changes, the size of the module, etc.
There are a lot of details I’m glossing over here, and I’ll talk about them more in future articles.
Because the first assembly language I learned was for my TI graphing calculator, I’ve have a soft spot for the Z80 CPU. It’s a nice 8 bit architecture and widely used in pre-MSDOS machines. The Apple II used a 6502 but more or less all the “business class” machines ran CP/M on a Z80.
It has a 16 bit address bus so it can address 64k of RAM, which is fine for an 8 bit machine. You can do bank switching to get access to more, which is what CP/M does.
I’ve breadboarded some very rudimentary Z80 machines over the years, but the Z80-MBC2 by Just4Fun is a great take on the genre. The twist is that it uses a Atmel AVR as a supervisor/ROM emulator/IO coprocessor of sorts. It makes it very easy to rapidly develop ideas when your IO system is reprogramable!
After assembling and experimenting with one, I decided I wanted the ability to support traditional expansion methods. There is standard DIY-oriented bus format for Z80 systems called RC2014. It is more or less the 40 pins of the Z80 CPU itself spread out in a 1×40 header. So I built an adapter that sockets in-between the CPU and the MBC2, pulling the bus lines out to one side. I used veroboard because its straight-through traces make extending the bus a cinch.
I haven’t had a chance to revisit the project lately, but I plan to. I assembled a composite video card for RC2014 and need to try it out.
I haven’t shared much about my modular synth, but I really should. I’ve created several custom synth modules – even designing PCBs and custom 3D printed faceplates for them. The circuit design is also my own although heavily inspired by the very helpfulsynthDIYcommunity. There’s only so many ways to build an Arduino-based utility module, anyhow.
This module hasn’t been finished but the front panel is pretty much complete. In addition to visually displaying a signal on the meter, it also has an “attenuverter”. This is a circuit which multiplies the input by a manually adjustable value between -1 and 1. This can both attenuate and invert the input signal – thus the portmanteau attenuverter. It’s a handy capability for modifying control voltages like and LFO or ADSR. I’m adding the ability to add an offset to the output, which allows you to move some control voltage up or down by some bias amount in addition to attenuating it.
I think I’ll also add a few modes to the meter such as a low value mode for voltages between -5 and 5, a high value mode for voltages between -10 and 10, and something like a VU meter – which looks at the average peak value. These have all been breadboarded in the past but I need to combine them all into one circuit and make a PCB for it.
The front panel printed out correctly on the first shot – even the snaps that hold the meter in place work great. That’s satisfying.
I need to find a typeface more suitable to printing though. Anyone have recommendations? Drop me a line. I’d like something that doesn’t have floating regions unconnected on the first print layer. Those seem to get messed up when I use cheap filament because of adhesion issues. You can see that in the photo in the case of the second capital R.