Amiga 600 recapping

The Commodore Amiga 600 was a force to be reckoned with when it was released back in 1992. It was a low-cost but very capable gaming machine. That is why it still has a loyal following.

A friend of mine belongs to the vintage gaming crowd and as such is the proud owner of an A600. Unfortunately for him, eventually his A600 gave out. After some googling he came across a number of A600 owners who have had the same problem with their units. Most of them were able to bring their machines back to life by replacing the electrolytic capacitors of the mainboard. A “re-capping kit” is relatively low-cost so my friend went ahead and ordered one. When it came he took his machine and paid me a visit.

The re-capping process ended up taking a lot longer than I had expected, but that was due to my inexperience with the specific machine. In the process I gathered a lot of information that may be of use to others, so here goes.

The first step is opening up the case. You do that by removing the screws on the underside of the machine and then carefully popping it open. There are a number of plastic clips on the inside of the case that need to be pried open with care. You can see a few of them in this picture (top part):

A600_open

Looking at this picture you will also notice that my friend has put in a 1MB RAM upgrade as well as an HDD emulator (the 4GB flash drive).

After you have opened up the case you need to remove the mainboard. To do that you have to remove the one screw visible on the lower edge of the mainboard. After that you must lift the mainboard along with its metal shield from the right side, clearing the two ports. You will need to use a little force. Be careful – these plastics are over 20 years old and thus do break easily. When you have cleared the right side you pull the board towards the front of the case and then up so as to clear the rear connectors. Now you have removed the board from the plastic case.

Now you need to separate the mainboard from its metal shielding. To do that you take out this pesky little screw:

Mainboard_screw

Then you have to unscrew the hex screws on the rear connectors. There are 8 of them in total. I haven’t taken a pic of them but they are pretty easy to spot.
Now all you have to do is bend out of the way the little pieces of metal that are situated around the shield, like this one:

metal lug

Assuming all has gone well, you should have the mainboard out and be ready to start the procedure.

There is a number of caps that need to be changed. There are 4 through-hole components and a number of SMD parts.

I have circled the offending caps in this pic:

MB_out_marked_caps

Some people choose to also change the two caps located on the back of the audio out ports. These caps are just DC blocking caps, they are not to blame for the death of the machine. Plus, they are located in a very tight spot, making replacing them too risky of a procedure.

So, first I took out the through-hole parts. That was relatively easy. Just bear in mind that you will need a relatively powerful soldering iron since the (-) sides are soldered to the ground plane which is extremely efficient at sinking heat.

Next up were the SMD parts. I had desoldered SMD caps in the past with no difficulty using a regular soldering iron but these ones proved to be particularly nasty. My first attempt ended in me pulling out one of the solder pads. I said to myself “bad luck.. whatever..” and moved on to the next cap. You guessed it – the next one also had the same luck. At that point I decided to change strategy and go with the hot air rework station. It proved to be much better at desoldering the old caps. For some reason even with the hot air I managed to pull off one SMD pad.

after_left_caps

So now I had 3 caps missing pads. That is considered bad. I decided to go to the schematics and see if I could get away with not replacing the specific caps. It turns out that I was lucky. The rightmost cap (C214) is a DC blocking cap that sends the summed L+R audio to the RF encoder IC. Since my friend does not (and will never) use the RF modulator, it was OK to not care about this cap.

I was not so lucky with the next one, C460. This cap is used to bypass the U12 IC, which I’m afraid is actually necessary for proper operation of the board. So I had to get creative. The missing pad corresponds to the GND connection, so I thought I would just solder some wire from the bottom of the cap to a nearby GND point. It turned to be much easier than that. I scraped the green lacquer from the remaining trace and managed to solder the capacitor to that by turning it a bit. In other words, I got lucky.

With the third cap (C235) I did what I did with the second one – scraping off the lacquer and soldering at a small angle. After I had done the procedure I remembered to look at the schematic to see what it was for – it turned out that I could have gotten away with not installing it since it was also a DC blocking capacitor, this time from the encoder IC to the RF modulator module. Oh, well..

When I was done the board looked like this:

Finished

This was the moment of truth. We hooked up the board to its power supply and my (very bare) test display.

Testing

We plugged in the power and voila! The Amiga 600 lives! 🙂

Boot

We then proceeded to put the machine back together and do another test, this time with the HDD installed. As was expected, everything was working just fine:

Boot_2

So, there you have it. An (almost) fully re-capped Amiga 600. My friend is in for some serious gaming. 🙂

Pipo X7: An ultra low cost Windows PC as a music transport

A few days ago I received the Pipo X7 that I had pre-ordered back in January.

It took so long to source & ship because it is immensely popular – after all, for less than 100€ I got:
– An Intel Baytrail Quad Core CPU @ 2.16GHz
– 2GB of low power DDR3 RAM
– A 32GB SSD drive (Samsung MBG4GC)
– An HDMI out
– WiFi b/g/n, 10/100Mbps Ethernet & Bluetooth connectivity
– 4 x USB 2.0 ports

All of that inside a slick aluminum box, not much larger than a CD, powered by a silent 12V/2.4A power supply.

IMG_9228

But the best part is that it runs a fully activated copy of Windows 8.1 (32bit)!

Yes, Microsoft is essentially giving away Windows 8.1 for use in small devices (like set-top boxes, such as this one) with only one catch for the OEM: He is not allowed to set Google Search as the default search engine. However, this does not mean that you can not set Google as your preferred search engine if you wish (instead of the dreadful Bing).

Now, I must admit that this was largely an impulse buy for me, since I already have a full size HTPC and a Squeezebox Touch as an audio transport, but I just couldn’t resist the temptation. So, since I had it, I decided to run a series of audio-oriented tests on it.

My player of choice is Foobar, feeding a Buffalo III DAC through an Amanero Combo384. The files were stored on a file server on my LAN and the Pipo was connected to the LAN via 100Mbps Ethernet.

The first test included outputting DSD to the Amanero. All the necessary Foobar components were loaded, including of course the Super Audio CD Decoder and the necessary configuration was performed:

Pipo-X7-DSD-out-1
Note: There are several steps involved in getting Foobar to output DSD. It is not the purpose of this post to fully outline them. A Google search would turn up a number of guides / how-tos.

First up was a “plain” DSD64 file. The Pipo had no problem playing it back, with less than 1GB of RAM use and about ~13% CPU utilization:

Pipo-X7-DSD-out-3

Let’s make it more interesting. DSD128:

Pipo-X7-DSD-out-4

Still no problem. As a matter of fact, CPU load has actually decreased! That is probably because the DSD64 file was from a SACD ISO, so some CPU time was used in handling the big file.

Moving on to a worst case scenario: A DXD file:

Pipo-X7-DXD-out

Still, no sweat, with the CPU barely sweating at 16% load. RAM has not climbed above 800MBs.

Since the machine appeared to have some decent horsepower, I thought I would try the well-known SoX Resampler DSP for Foobar. I set it up as best I could, since I don’t really have much experience with the actual DSP:

Pipo-X7-SoX-config

I chose to go the “x4” upsampling way, with the “Best” quality setting. This meant that a 44.1KHz file would be upsampled to 176.4KHz and a 96KHz file would be upsampled to 384KHz, hitting the limits of the Amanero interface. A 192KHz file would not be supported, since that would mean that it would have to be upsampled to 768KHz. The idea was to do a benchmark, so I just played two versions of the same files, one at 44.1K and one at 96K. This was the result:

Pipo-X7-SoX-44.1K-x4

Pipo-X7-SoX-96K-x4

So, still no serious sweat, with the CPU averaging 29% load, with one of its cores (presumably the one doing the actual upsampling) getting about 50% usage.

At that point, I called it a day.

In conclusion, it seems that the Pipo X7 is perfectly capable of supporting audio playback, even with upsampling enabled. As a matter of fact, I might keep it as a music transport.

The Raspberry Pi: Audio out through I2S

There are currently four ways to get audio out of the RPi:

  1. Use the audio out 3.5mm jack. It’s very easy to get it to work, but the sound quality is pretty bad, since it uses PWM to generate the sound. Due to that, its real resolution is in the neighbourhood of 11 bits. We have no use for that.
  2. Use the HDMI port. It works OK, but is useless to us audiophiles.
  3. Use a USB to I2S adapter, such as an Amanero or an XMOS-based device. Now we’re talking. They work quite well, and the quality of the I2S signal is dependent largely on the technology used (CPLD vs. XMOS, etc) as well as the quality of the on-board clocks. The problem is that they add another link to the audio chain, as well as increase the cost. Remember, the RPi is supposed to be a low cost solution.
  4. Use the GPIO pins of the RPi to get direct I2S output. This sounds way more interesting, right? Let’s try that!

According to several sources on the Net, this is the pin out:

Raspberry_Pi_B_Plus_I2S_out

You will probably notice that the RPi does not support MCLK output. This means in practice that your DAC will need to have its own on-board clock (or internal PLL / oscillator or whatever). We can live with that.

Luckily, my Buffalo III has its own clock (of course it does!) and thus can be connected quite easily. Let’s try that:

IMG_8297_resize

Now we have to configure the software for I2S output. For my distribution of choice, Archphile, it’s a piece of cake: http://archphile.org/howto/i2s-dacs-and-the-raspberry-pi/

Audio playback works just fine!

Well, almost fine..

You see, in theory the RPi has a bit of a problem with its I2S output. Since the only clock onboard the RPi is a 19.2MHz crystal, it should have trouble generating proper clocks for its I2S output. For example, for 44.1KHz audio, the LR Clock must be running at precisely 44.1KHz. That is not possible, since the frequency is not a multiple of 19.2MHz. Thus, the frequency can be either 19.200.000 / 435 = 44.138KHz or 19.200.000 / 436 = 44.0366KHz. This is a limitation of the Broadcom BCM2835 in conjunction with the 19.2MHz crystal and there is nothing that can be done.

In order to confirm the theory, I decided to run a few tests. I hooked up my logic analyzer to my RPi, set it up for I2S output, and fed it some 44.1KHz music.

IMG_8453_crop_resize

I took 1 sec worth of samples with my logic analyzer, configuring it for I2S signal. I got this:

logic analyzer 4

The PCM Clock is already appearing a little dodgy. Let’s zoom in:

logic analyzer 5

logic analyzer 6

As you can see, the pulses do not have the same duration. They appear to alternate between two values. So it is obvious that the signal has jitter. A lot of jitter. Since we’re here, let’s have a look at the LR Clock signal as well:

logic analyzer 7

logic analyzer 8

The duration of the pulses appears to alternate between 11.33μS and 11.38μS, giving respectively 44.12KHz and 44.04KHz, values very close to the ones I calculated previously.

So, the theory is sound and the RPi’s clock is not up to snuff by strict standards. What this means is that the RPi’s I2S output is not capable of “Hi End” audio transmission. It is essentially not bit perfect (edit: this is not correct, strictly speaking. It is in fact bit perfect, it is just not “proper”.).

In the real world, chances are that this problematic clocking will not be particularly audible under normal circumstances, say with a normal-specc’ed sound system. But an audiophile should definitely steer clear of the RPi’s I2S output, instead opting for a USB to I2S interface.

The Raspberry Pi: Low cost music streamer

Enter the Raspberry Pi B+:

Raspberry Pi B+

It features:

  • A Broadcom BCM2835 SoC processor running at 700MHz
  • 512MB of RAM
  • A Micro SD slot for storage
  • A 10/100Mbps Ethernet port
  • 4 x USB2.0 ports
  • An HDMI output port
  • An analog audio / composite video output port
  • A 40-pin expansion header, exposing 26 x GPIO ports
  • A camera and a display interface port

Somehow they have managed to cram all that in an almost credit-card sized PCB.

And it costs less than 40€.

It runs Linux (of course..). There is a large number of general-purpose distributions available, as well as a few custom built ones. One of them is Openelec (an XBMC Media Center distro), another one is Volumio (an audiophile music player), a third one is SqueezePlug (it emulates a number of Media Servers, like Logitech Media Server, MediaTomb, MiniDLNA, etc. It also works as a Squeezebox (client)), etc.

So far, my favorite distribution is Archphile, an audiophile linux distribution. It may not have the polished look of Volumio or play 1080p video like Openelec, but is plays music wonderfully through a USB port (or through I2S if you are more of a DIYer).

So, what am I doing with it? I wanted to put a music streamer in my kitchen. I already have two Squeezeboxes in other rooms, so for the kitchen I thought I would try something more interesting.

But along the way, I discovered that it is a lot more useful than that. A very useful (and very rare) feature it has is the ability to bitstream DSD audio (a.k.a. SACDs):

RPi outputting DSD to Buffalo DAC

Raspberry Pi B+ outputting DSD to my Buffalo DAC

So now I’m considering adding an RPi network music transport to my main system.

Synology DSM 5.1 now supports Amanero!

First, a little background info.

Synology makes great NAS products. They are user friendly, fast, and multimedia oriented.

A little known feature of said products is that they support direct connection to USB enabled DACs. All you have to do is connect your DAC to your NAS with a USB cable, fire up Audio Station and tick the box for USB Speakers:

USB-Audio-out-1

Now you have a new output device, called USB Speakers:

USB-Audio-out-2

You just select that and now your Synology plays through your USB DAC. It’s that simple.

Now, this feature has been available for quite some time, so why am I making such a fuss about it now? It’s simple: Synology just started supporting my favorite USB-to-I2S interfacing board, the Amanero.

So, if you have an Amanero and a Synology NAS, just upgrade your DSM to 5.1 and enjoy full compatibility!

DS211j with Buffalo DAC