Adding input auto-select for Scythe SDAR-2100 amplifier

I have a Sonos system set up at home. The Play:1 speakers start to play music whenever I press the play button on the Android control app; however, the Connect units which hook up to my existing amplifiers need something different. For my AV receiver I solved the problem using Python SoCo library and Marantz telnet interface. For my PC amplifier Scythe SDAR-2100 I had to think of something else as it does not have any control interface.

Front panel without lid.
Front panel without lid.

I took a look at the amplifier and noticed that the preamplifier board is separate from the power amplifier. Therefore I decided to replace the preamp with one that sniffs the inputs and changes the input if needed. As a bonus that way I could get rid of an intermittent volume control potentiometer.

The circuitry is nothing fancy; Arduino Pro Mini takes care of all the processing involved; PGA2311 is used for the volume control. Inputs are amplified with a pair of LM358 op-amps and then fed to the A/D converter of the AVR. A bank of relays takes care of switching the input. Switching regulator AM1D-1205DZ generates the +/-5 V rails from the 12V rail. As a bonus I use the AVR to pulse width modulate the backlight of the VU meters (the black/red cable in the photo).

Modified preamp board.

The trickiest part of the project was to design the PCB layout so that all the potentiometers, switches and connectors meet up with the main PCB and the holes in the enclosure. It involved a lot of measuring. I also experienced some software bugs which resulted in some VERY LOUD output… luckily I tackled those quite quickly.

Overall view of the circuitry.
Overall view of the circuitry.

While I had the amplifier in bits I also replaced the horrible stock speaker jacks to better ones. Overall I am very happy about how the modifications turned out. I no longer have to turn any knobs in order to play music from Sonos!

Arduino core memory shield is ready and for sale

Hi all,

I was selling this core memory shield it as a kit on Tindie between 2016 – 2022 but it is now discontinued. See Andy Geppert’s Core64 project if you’re interested in getting into core memories, or build your own based on the information on this page.


Here is all the material related to the kit:


Thanks to Ben North and Oliver Nash at for the inspiration and encouragement!

Building a ferrite core memory, part 2

My ferrite core memory is progressing nicely. I have received the PCB and assembled it for the most parts.

Core memory shield without sense circuit

This evening I tried out how the H bridges worked – after a few tweaks in the Arduino code I was able to get this sequence out:

Bit read values from an array of cores.

The only remaining things are to assemble the sense line circuit and to do the final testing and tweaking, which will most likely take a long time.

Building a ferrite core memory, part 1

A while ago I ordered some ferrite cores from Bulgaria in order to build a vintage memory out of them. Yesterday I managed to build a one-bit memory by following what Wayne has done.

Writing 1,0,0 to memory which was in state 0. Enable pulses in yellow, sense line in cyan.


Now that I have an understanding of the technology and the characteristics of the cores I have I will continue to build a 32-bit version in the form factor of an Arduino shield (my own twist of this project).

Blog is back up

Today I put the blog back online as I think I now have enough time to maintain it since I have completed my studies. I went through the old articles and polished them up a bit. I hope I will soon have exciting new projects to share.

I also enabled commenting as I am hoping there won’t be too much spam. I go through every comment prior to publishing them.

Nixie VU meter

Most of my projects seem to deal with lights and music.  VU meters are not fashionable anymore, and the few commercial products I found don’t look too stylish at all. Therefore I decided to build my own using six Soviet IN-9 nixie tubes I had lying around.

The schematic is not too exciting at all. The audio input is connected to a MSGEQ7 graphic equalizer IC which I got from Sparkfun. Its output is processed by an Atmel ATmega88 microcontroller which sends commands to a M62359P DAC. The DAC outputs drive the tubes using a current sink described in “Driving IN-9 Neon Displays” by Dipl.-Ing. Jan Philipp Wüsten. The specific DAC was chosen because it was one of the few 8-channel DACs in DIP package that I could find without spending a fortune on shipping. Nixies are powered by a 1363 power supply. I had to connect a filter to its output (the large Teapo cap + a small resistor) to stop it from whining.

As the nixie tubes require a lot of space, a large enclosure was bought from TME. The mounts in the enclosure were quite far apart so the PCB became quite large. For that reason I etched the PCB myself, which I do quite rarely these days.

For future improvement I could check whether the MSGEQ7 output is linear or logarithmic – I’m thinking it’s linear as the sometimes the readings shoot way up without a great difference in perceived volume. Still, I think that the meter looks great and I’m quite pleased with it.

Playing music using floppy drives, revisited

Playing music on floppy drives is nothing new. The Moppy project has been popular for a few years now, and it was the project that initially caught my attention as well. However, I though that it lacked a certain sense of elegance; FPGA would be much better in generating the waveforms for a bunch of floppy drives at the same time. That project also combines Arduino and Java, both of which are not my favourite things in the world. It also requires a PC.

So I decided to roll an implementation of my own. Last summer I programmed the midi parser on an ARM microcontroller, which sent the data to the FPGA via SPI. The basic VHDL block consists of nothing more than a counter and a lookup table. Eight of these blocks were instantiated in a higher level block and connected to a SPI block which was trivial to program.  The MIDI file was hard-coded in the program memory of the microcontroller as a C array. It worked, but it was certainly not satisfied. There’s no need to have anything besides a single FPGA, and the project must have an user interface. Changing the song was too hard in the old version.

In late 2013 I dug up my Terasic DE2 board, which is on loan from my university (thanks TUT!). It’s been a while since my VHDL and SoC classes but I was able to create a QSys system in a short time. Of course, I also had to wrap my HD44780 and waveform generation blocks to use Altera’s Avalon bus. I was really amazed how smoothly everything went.

IPs connected in QSys
IPs connected in QSys

Besides the aforementioned blocks I also used Altera’s SD card IP. It didn’t work with my SDHC card, but an old 128 MB SD card worked fine. I can just save mid files on the SD card and choose the song to play from the HD44780 LCD screen. User input is given using pushbuttons (parallel IO).

HD44780 LCD showing the MIDI files on SD card.
HD44780 LCD showing the MIDI files on SD card.


The “music” waveforms are output from the GPIO header and fed to a 74LVC245 buffer. Besides buffering, it also converts the 3.3V signals to 5V. The buffer outputs are directly connected to the floppy drives using 10-pin IDC cables and a simple adapter PCB. The PCB also has an LED indicating power – it also turned out that the current draw of the motors made them flicker in a nice way.

My PCB which brings out all the signals in a single 10-pin connector.
My PCB which brings out all the signals in a single 10-pin connector.
Buffer PCB
Buffer PCB

That’s all there was to it really. I think this is as far as I’ll go with this as I think my solution is now elegant enough and I’m sick of hoarding floppy drives. Possible improvements would be combining the channels and floppy drives more intelligently (not all floppy drives are the same and play at the same volume  – some sound much more ugly than the others). Sometimes beautiful melodies are hidden beneath the grunting sounds from the other drives.

Here’s a few songs I recorded.

Testing Amiga DRAM

A friend of mine has an Amiga A500. As usual, the machine was kept in a storage until its retro value was significant, and during those years of storage the battery of the “memory & RTC” expansion had leaked and grown a thick fur on the PCB.

The module didn’t work even after cleaning up the mess. I told I could take a look at it, and sure enough I soon had the module in my hands. As I don’t have an A500 of my own, I decided that the best way to troubleshoot would be to talk to it through the connector, and so I built a testbench out of an Olimex LPC1114 board. The microcontroller has 5V tolerant GPIO pins, which is a bonus.

Amiga DRAM test circuit

It turned out that the microcontroller was quite slow with its bit arithmetics and the debugger on so that the timing didn’t become an issue. After a few hours of debugging with my logic analyzer and fixing a few bad pin choices (eg. mapping an address line to a SWD line) I was finally able to write to each location of one of the chips and read it all back. After repeating it for the other chips I found out that one of the chips was faulty, and the board shall return to its rightful owner after I get a new IC from an eBay surplus store.

Of course, it would have been more elegant to program this thing with Assembly and carefully take note of the timings, but I wrote it in C and made sure that the cycles are not too long. After all, the performance of this device doesn’t matter as testing the chip even with my unoptimized code takes only a few seconds.

Playing music using floppy drives

The Moppy project, which enables an Arduino to use floppy drives to play music, is something a lot of people have tried, but I was not comfortable with installing Netbeans to run the Java app. Instead, I built my own system from scratch.

I used my NXP LPC1768 dev board “LandTiger” for all the complex stuff. It had the MID file in its memory as an array, parsed it and sent the notes over SPI.

A Micronova Mercury FPGA board received the notes and generated the waveforms to play the notes. I used an FPGA so that I could utilize its parallelism for the waveforms and to prevent my VHDL skills from rusting. A neater way would have been to replace the microcontroller with a softcore one inside the FPGA, but I didn’t feel the need as I was just dicking around.

Regrettably, this video is the only piece of evidence I have left. Well, the system consisted of a lot of software and a few wires, so there was nothing much to see.