DDDAC 1794 AC Power Distribution

The current power distribution can be cleaned up. Multiple wires in a too small terminal block and separated relay board. Time to clean it up.

My build of the DDDAC1794 The 230VACpower distribution exists out of:

  • 1x AC 230VAC coming from the mains connector
  • 1x Power Supply for the DAC
  • 1x Toroidal Transformer with dual secondaries for the clean an dirty digital supply
  • A (solid state) relay controlled by the soft power down controller
  • A momentary switch to start the system until the soft power down controller takes over

It would be nice if all could connect to a small power distribution PCB. And for size and stability the current relay replaced by a solid state relay.

power distribution schematic,

The Omron G3GMB-202P 5 volt version is a 2A solid state relay with zero-crossing detection. It already contains an internal resistor, so you can directly control with 5V/10mA.

The controller activating the solid state relay is described in Raspberry Soft Power Off. There a conventional relay is used which is directly activate after the controller is booted . This happens when the momentary switch is pressed, which temporary bypasses the relay until released. The start of the controller is fast enough to be unnoticed by the user.

With a solid state relay including switching on the 0 crossing this is different, while the momentary switch is closed the relay can’t be activated, it requires that some current can flow. And then it requires 1/2 a power cycle + 1 mS = 11mS. The system load (on the dirty 5V supply) is required to run at leased this time without AC to startup the solid state relay, before dropping below the 4.5VDC. That will not be a problem.

The used parts are in the table below.

ReferencePart
J1TerminalBlock_Phoenix:TerminalBlock_Phoenix_PT-1,5-2-5.0-H_1x02_P5.00mm_Horizontal
U1Omron G3MB-202P 5V version
J4TerminalBlock_Phoenix:TerminalBlock_Phoenix_PT-1,5-2-5.0-H_1x02_P5.00mm_Horizontal
J5TerminalBlock_Phoenix:TerminalBlock_Phoenix_PT-1,5-2-5.0-H_1x02_P5.00mm_Horizontal
J3TerminalBlock_Phoenix:TerminalBlock_Phoenix_PT-1,5-2-5.0-H_1x02_P5.00mm_Horizontal
J2TerminalBlock_Phoenix:TerminalBlock_Phoenix_PT-1,5-2-5.0-H_1x02_P5.00mm_Horizontal
part list

Next is to design a small PCB with those components:

PCB Layout

An impression of how the final result would look:

PCB Render with Kicad

But before we create a real PCB, lets first create a proto to see to see if we are satisfied with the practical use.

proto top side

For safety remove unused pads between the phase, neutral and control signals:

proto bottom side

And mounted in the actual DDDAC 1794:

proto mounted to the side panel of the enclosure

It works great and organize the power distribution in a neat way. It is time to order a real PCB. With the current proto in place I’m not in a hurry, so lets order it at oshpark with their famous PCB color.

OSHPark PCB

In case you also want to order a PCB, the PCB is shared at oshpark. OSHPark supplies a great quality at nice price, only it take a while be fore the good are delivered.

Update: September 26th the PCB’s have finally arrived:

Finished PCB’s.

MPD with custom Sox recipes

2020-09-04: The custom sox recipes patch has been accepted by MPD on the master branch!
2020-09-14: The custom sox recipes are part of the upcoming moOde 7.0.0 release. MoOde even provide a nice GUI for it.

MPD can use the famous soxr library for resampling. Soxr is very flexible with the configuration of the resampler. Only MPD only provide the default recipes with the quality setting.

You can find a lot on internet about the usage of soxr or sox (the commandline version of soxr) , including a kind of measurements.

The patch mpd-0.21.x_soxr_customrecipe.patch (or for mpd-0.22~git) will add settings to MPD section of the resampler. In only unlock the already present settings in soxr, the functionality of sox is untouched.

SettingDescriptiondefault
precisionNumber of used bits [16|20|24|28|32]20 (matches HQ)
phase_response0 =MINIMUM_PHASE, 50=LINEAR_PHASE, intermediate is between those.50
passband_endOriginal bandwidth of source used (%, < 100) 95.0%
stopband_begin(% > 100)100.0%
attenuationLowers the source to prevent clipping. Expressed in db. 0 db
flagsBit fields:
01 ROLLOFF_SMALL 0.01 dB
01 ROLLOFF_MEDIUM 0.35 dB
02 ROLLOFF_NONE For Chebyshev bandwidth.
08 HI_PREC_CLOCK Increase `irrational’ ratio accuracy.
16 DOUBLE_PRECISION Use D.P. calcs even if precision <= 20
32 SOXR_VR Variable-rate resampling.
0

To enable the custom recipe the quality should be set to "custom". If another quality is selected and the custom settings are still present you will get warnings in the MPD log about unused settings.

Example MPD configuration:

resampler {
  plugin "soxr"
  quality "custom"
  threads "2"
  precision "24"
  phase_response "45"
  passband_end "95.0"
  stopband_begin "100.0"
  attenuation "1.0"
  flags "0"
}

More MPD soxr selective resample modes

2020-09-14: The MPD soxr selective resample modes are part of the upcoming moOde 7.0.0 release. MoOde even provide a nice GUI for it.

Earlier I wrote about moOde with MPD Selective Resample about sox and resample. With selective resample takes in account if source sample rate is multiple of 44.1kHz or 48kHz. With selective resample the target sample rate is a integer multiply of source sample rate.

Sox with integer ratio only cost 50% of the CPU resource. Sound wise maybe less artifacts are introduced, but that is up to you and your ears to decide.

The selective resample could only be turned on or off. With a new patch some more flexibility is available.

The selective resample mode is set by combining several flags:

SELECTIVE_RESAMPLE_MODE = ADHERE_BASE_CLOCK and [UPSAMPLE_ALL | UPSAMPLE_ONLY_48 | UPSAMPLE_ONLY_44]

If non is set (0) then default scheme of sox is followed, resample (up and down) everything to the provided target rate.

If the resampled target rate should be a multiple of the source base rate can be set with the flag ADHERE_BASE_CLOCK.

When to resample a source:

  • UPSAMPLE_ALL- Only upsampling.
  • UPSAMPLE_ONLY_48 – only upsampling sources below 88.2kHz.
  • UPSAMPLE_ONLY_44 – only upsampling when source is 44.1kHz or below.

Where the flags have the following value:

  • ADHERE_BASE_CLOCK = 0x08
  • UPSAMPLE_ALL = 0x03
  • UPSAMPLE_ONLY_48 = 0x02
  • UPSAMPLE_ONLY_44= 0x01

In table the behavior is shown for several source sample rates and target sample rate of 192kHz and 176.4kHz.

Selective Resample Modes

When resampling is used the output rate is shown bold.
Note that using a target rate as expressed in a multiple of 48kHz behaves more natural then express in a multiple of 44.1kHz.

Use

To support this modes you need to patch your MPD executable. The patch is available for the latest 0.21.xx [24|25| and upcoming 26] releases and the 0.22~git development branch.

You can find the 0.21.xx patch here and the 0.22~git patch here.

Applying the to your MPD source tree:

cd MPD/src
patch -b -p2 < /path_to_the_patch/mpd_0.21.xx_selective_resample_mode.patch

After applying the patch, you can build your MPD executable.

If you have an MPD version with support for it, you need to add the following to the MPD configuration:

selective_resample_mode "4"

Note: If you switch back to a version with mode support remember to remove this line, else MPD will not start.

moOde with MPD Selective Resample

2020-09-14: More flexible version is available, see MPD soxr selective resample modes .The MPD soxr selective resample modes are part of the upcoming moOde 7.0.0 release. MoOde even provide a nice GUI for it.

Music Player Daemon is a daemon used in a lot of (Raspberry Pi) audio distributions. Including the one that I use; moOde Audio Player. MPD supports a bunch of plugins, including SoxR for high quality resampling. Which can be used for both up and down sampling.

The most common used audio sample rates are based on two ‘base’ clocks; multiplicity of 44.1 kHz or48 kHz. Typical matching sample rates:

  • 44.1 kHz based: 44.1 , 88.2, 176.4, 352.8 kHz
  • 48 kHz based: 48, 96, 192, 384 kHz

Is you resample to a different base clock, for example from 44.1 to 96 kHz, you will get a big performance penalty with SoxR. At least compared with from 48 to 96kHz. It takes twice the number of CPU resource than from 48 to 96 kHz.

In MPD you can configure a target sample rate. Lets say we configure MPD to upsample to 96kHz. This works nice for 48 and 96kHz source, only for 44.1 and 88.2 kHz the outcome is a little bit different. You can image that from 48 to 96 (ratio 2) is a lot easier than 44.1 to 96 (ratio 2.17). You Raspberry Pi agrees and is lot busier with 44.1 to 96kHz. Almost twice the number of CPU resources are used. I don’t dare to say something about the audio quality, I just focus of the used CPU resources.

Wouldn’t it be nice if the 44.1 is just upsample to the nearest round base sample rate? This is what the supplied patch will do.. You just provide the max, as specified in a 48kHz base sample rate and 44.1 based will just match to the closest (but lower) sample rate.

At the end of this articles the results of performance test are shown and includes the commands to reproduce it yourself.

Patch MPD

Please follow the updated instructions concerning patching and installation in https://github.com/bitkeeper/dddac1794build/tree/master/raspberrypi/software for MPD patch and custom settings for Moode MPD !!!

moOde only supports the resample option by using the global audio_output_format setting. Due this the patch will introduce a global setting called selective_44k_resample.

This will not work with Volumio because it doesn’t use the global resample option audio_format option, but the one on the output device. Of course the supplied patch could be changed to also support output devices.

The patch is tested with moOde 6.4.2 and mpd-0.21.20. For building the patch the easiest way is to do it directly on your target. The build instructions below are based moOde build recipe.

pi@moode:~ $ wget http://www.musicpd.org/download/mpd/0.21/mpd-0.21.20.tar.xz
pi@moode:~ $ wget https://www.bitlab.nl/wp-content/uploads/2020/04/mpd_0.21.20_selective_44k_resample.patch
pi@moode:~ $ tar xf mpd-0.21.20.tar.xz
pi@moode:~ $ cd mpd-0.21.20
pi@moode:~ $ patch -b -p1 < ../mpd_0.21.20_selective_44k_resample.patch
pi@moode:~ $ meson . output/release --buildtype=release -Db_ndebug=true
pi@moode:~ $ meson configure \
-Dalsa=enabled \
-Dbzip2=enabled \
-Dcurl=enabled \
-Ddatabase=true \
-Ddsd=true \
-Dffmpeg=enabled \
-Dfaad=enabled \
-Dflac=enabled \
-Dhttpd=true \
-Did3tag=enabled \
-Dlame=enabled \
-Dlibmpdclient=enabled \
-Dmad=enabled \
-Dmpg123=enabled \
-Dpipe=true \
-Drecorder=true \
-Dshout=enabled \
-Dsoundcloud=enabled \
-Dsoxr=enabled \
-Dvorbis=enabled \
-Dwave_encoder=true \
-Dwavpack=enabled \
-Dzeroconf=avahi \
-Dzzip=enabled \
-Dao=disabled \
-Daudiofile=disabled \
-Ddbus=disabled \
-Dexpat=disabled \
-Dfluidsynth=disabled \
-Dgme=disabled \
-Dipv6=disabled \
-Djack=disabled \
-Dlibsamplerate=disabled \
-Dnfs=disabled \
-Doss=disabled \
-Dpulse=disabled \
-Dsidplay=disabled \
-Dsmbclient=disabled \
-Dsndfile=disabled \
-Dsqlite=disabled \
-Dudisks=disabled \
-Dupnp=disabled \
-Dwildmidi=disabled \
output/release
pi@moode:~ $ ninja -C output/release

Especially the latest step will take quite some time. After the build there should be an MPD executable in the ./output/release directory.

Now we have to copy the executable to the location where the system will use it. We have to make sure it isn’t in use, else the file will be locked.

sudo killall worker.php
sudo killall watchdog.sh
sudo rm /run/worker.pid
sudo systemctl restart php7.3-fpm
sudo systemctl restart nginx
sudo systemctl stop mpd
sudo mv  /usr/local/bin/mpd /usr/local/bin/mod.orig
sudo cp output/release/mpd /usr/local/bin
sudo /var/www/command/worker.php

If you are coming from a stock Moode 6.4.2 ( with mpd-0.20.16) you need to regenerate you library, due some changes in the mpd-0.20.21 code.

Usage

To use a MPD build with the selective_44k_resample patch:

  1. Set audio_out_format to a multiplication of 48kHz like 96000:24:2 (Off course you have to make sure the target requested sample rate is supported by your output and/or DAC.).
  2. Set selective_44k_resample is set to yes.

For use with moOde the first one is clear. Open the MPD Configuration page and set the wanted resampling options.

Moode MPD config Sox Resampling configuration

The second one is a little bit harder to do. moOdedoes support small subset of the available MPD settings, let alone new settings. And because moOde generates the configuration for MPD any manual made tweaks are overwritten.

We need to make a small change to MPD configuration generator.

I use myself another patch for moOde. That patch adds the possibility to add additional global and device MPD options by using the moOde web interface. There we can just add the option selective_44k_resample "yes" to the general parameters.

Custom Moode MPD Tweaks

Search in the file /var/www/inc/playerlib.php for the following two line in the function updMpdConf. With Moode 6.4.2 the function starts at line 1521.

$data .= "max_connections \"128\"\n";   
$data .= "\n";

Insert between the two lines a new one with the content below:

$data .= "max_connections \"128\"\n"; 
$data .= "selective_44k_resample \"yes\"\n"; 
$data .= "\n";

Reboot your Pi to make sure the new code is used. After boot go the the mpd configuration page and press save to make sure the mpd configuration is generated.
To be sure you can check if the settings is in the mpd configuration by executing the following command:

cat /etc/mpd.conf| grep selective_44k_resample 
selective_44k_resample "yes"

It should return the setting with yes.

Performance tests

The test are performed with the command line version of sox.

Used test environment:

  • Pi 2B
  • Raspbian Buster Lite 10.2
  • kernel 4.19.97-v7+
  • SoX 14.4.2

Tests are run on a ramdisk. As test file the default audio from moOde is
used. To prevent testing decoder/encoders test files are wave files.

Performed tests:

  • 44.1/16 to 96/24
  • 48/16 to 96/24
  • 44.1/16 to 88.2/24

In the results below it is clearly visible that the resampling from 44.1 to 96 takes twice as more CPU resources that for 88.2 or 48 to 96.

To be able to reproduce the test yourself in the file below all commands to setup and execute the tests are in the attached file:

Test 48/16 to 96/24

pi@moodedev:/mnt/ramdisk $ perf stat sox LRMonoPhase4_48_16.wav -b 24 LRMonoPhase4_96_24.wav rate -v 96000

 Performance counter stats for 'sox LRMonoPhase4_48_16.wav -b 24 LRMonoPhase4_96_24.wav rate -v 96000':

          2,574.54 msec task-clock:u              #    0.999 CPUs utilized
                 0      context-switches:u        #    0.000 K/sec
                 0      cpu-migrations:u          #    0.000 K/sec
               245      page-faults:u             #   95.183 M/sec
     2,169,128,394      cycles:u                  # 842707.224 GHz
     1,492,424,845      instructions:u            #    0.69  insn per cycle
       103,511,129      branches:u                # 40214113.831 M/sec
         2,726,871      branch-misses:u           #    2.63% of all branches

       2.577343598 seconds time elapsed

       2.436878000 seconds user
       0.140396000 seconds sys

Test 44.1/16 to 96/24

pi@moodedev:/mnt/ramdisk $ perf stat sox LRMonoPhase4_44_16.wav -b 24 LRMonoPhase4_96_24.wav rate -v 96000

 Performance counter stats for 'sox LRMonoPhase4_44_16.wav -b 24 LRMonoPhase4_96_24.wav rate -v 96000':

          5,097.92 msec task-clock:u              #    0.999 CPUs utilized
                 0      context-switches:u        #    0.000 K/sec
                 0      cpu-migrations:u          #    0.000 K/sec
               309      page-faults:u             #   60.624 M/sec
     4,385,703,707      cycles:u                  # 860448.049 GHz
     2,983,902,787      instructions:u            #    0.68  insn per cycle
       316,741,603      branches:u                # 62142751.226 M/sec
        10,099,792      branch-misses:u           #    3.19% of all branches

       5.101232776 seconds time elapsed

       4.960521000 seconds user
       0.140014000 seconds sys

Test 44.1/16 to 88.2/24

pi@moodedev=/mnt/ramdisk $ perf stat sox LRMonoPhase4_44_16.wav -b 24 LRMonoPhase4_88_24.wav rate -v 88200

 Performance counter stats for 'sox LRMonoPhase4_44_16.wav -b 24 
 LRMonoPhase4_88_24.wav rate -v 88200'=

      2,385.83 msec task-clock=u       =    0.998 CPUs utilized
             0      context-switches=u =    0.000 K/sec
             0      cpu-migrations=u   =    0.000 K/sec
           243      page-faults=u      =  101.887 M/sec
 1,992,758,822      cycles=u           = 835538.290 GHz
 1,371,449,852      instructions=u     =    0.69  insn per cycle
    95,114,857      branches=u         = 39880443.187 M/sec
     2,507,847      branch-misses=u    =    2.64% of all branches

   2.389982451 seconds time elapsed

   2.248309000 seconds user
   0.139894000 seconds sys

Hifiberry Digi+ Pro with Allo Isolator


For quite some time I’m using the Allo Isolator for galvanic isolation between the Pi and the HifiBerry. Everything was upsampled to 192kHz and works great. No more cracks, deep dark sound.

Only when starting playing with different sample rates (44.1kHz based) MPD hangs. Before using the isolator it did work. If seems that something is wrong.

The HifiBerry Digi+ Pro has two crystals onboard; one for a multiplicity of 48kHz and one for multiplicity of 44.1kHz based sample rates. The crystal selection is done by using GPIO 5 & 6. Only GPIO 5 isn’t isolation by the Allo Isolator.

This can lead to two scenarios:

  • If the power supplies aren’t isolated (for example shared ground), it will work. Only your system isn’t isolated as it should.
  • If the power supplies are really isolated, GPIO 5 becomes floating. In my case this even damaged my crystal.

 The image below illustrate the difference between GPIO6 (pin31) and GPIO5 (pin29).

Isolated vs not Isolated pin

Fixing the isolation

Lets first take a look at the Isolator. In red is shown which pin is isolated by which isolation ICs (Si8630, Si8631 and Si8502). Each pin has a certain fixed role; output(>), input(<) or bidirectional (<>).

Allo Isolator IO Pins vs Isolator Electronics

Also not clear from the Isolator documentation is that the SPI isolating works different from the GPIO isolation; SPI isolation means no connection at all. Yes that is also isolated, but not usable.

For the clock selection we need an unused output pin. Below is an overview of how my system is using the Pi IO header.

Raspberry Pi Io Header usage

GPIO16 (pin 36 ) looks like a good match.

Only the HifiBerry can’t be configured to use a different pin. We could rework the Allo Isolator in such way that GPIO 6 is using isolation electronics from GPIO16 (and disconnect GPIO16 from the Pi).

Steps to reuse the GPIO16 isolation electronics:
– [bottom side] pin 29; cut trace to via
– [bottom side] pin 36; cut connector from the solder pad
– [bottom side] solder wire between pin 29 and pin 36 on the bottom side
– [upper side] solder wire between pin 29 and pin 36 on the bottom side

I choose a different approach, which only requires one electronical modification to the Isolator; break the connection between GPIO5 upper and lower connector of the Allo Isolator. The trick is that we will make software modification so that the HifiBerry software driver will use the already isolated GPIO16.

Steps to take:

  1. Electrical isolate GPIO5 upper and lower connector from the Allo Isolator.
  2. Connect GPIO5 to GPIO16 on the isolated side with a jumper wire.
  3. Create a software mod to use a different GPIO pin.

Isolated GPIO pin 5 from the Pi

First we have to make sure GPIO 5 (pin 29) is electrical isolated. On the bottom of the Isolator there is a via that connects GPIO5 from the bottom connector to the top connector. This via is connected with a very small trace going from to the solder pad of pin 29.

Just cut this trace with a small X-Acto knife or what ever for small knife you have. Probably you need to have some loupe of smartphone to see it clear enough, at least I did. You don’t need to remove the entire trace, just can scarf will do. Don’t forget to measure the connection between the upper and lower connector before and after to see if the cut is good enough. 

Connect GPIO 16 to GPIO 5

Next we have to connect from the Isolator upper connector GPIO 16 (pin 36) to GPIO 5. You can solder a wire between solder pads of pin 36 and pin 29 and you are good to go.
Because my HifiBerry has the additional male header installed, I did have another choice available; Just connect a jumper wire from pin 36 to pin 29 on the HifiBerry upper connector. No soldering required.

Jumper wire for connection between GPIO5 & GPIO16

Do you notice the connector in position P3? You can use this one to feed both the HifiBerry and the Isolator with clean 5V. In this way you can avoid the less available 6.5V for the Isolator. Both the HB and Isolator use own regulators for 3.3V, which what the actual chips are using.

Make the Pi use GPIO 16 for clock selection

Let the Pi HifiBerry driver use an other GPIO for the crystal selection is standard not available. To make this work we need to change the driver overlay a bit.

This involves the steps:

  • create a new overlay that support reconfigure the clock selection GPIO
  • configure the Raspberry Pi to use it.

Create a new overlay

Luckily it isn’t hard to make a new overlay which allow to configure the used pins.
But you need to know a little about using the command line command of Linux. First login open a SSH session, for example with PuTTY.

Or alternative you can download the overlay here and just copy to the overlays directory on the SD card. It is build on Moode 6.4.2 with kernel 4.19.97-v7+ #1293.

  • Install the device tree compiler
sudo apt-get install raspi-gpio device-tree-compiler
  • Download the remap overlay source here or create a file called hifiberry-digi-pro-remap.dts
vi hifiberry-digi-pro-remap-overlay.dts
  • If not downloaded fill the content with:
// Definitions for HiFiBerry Digi Pro clock select remap
/dts-v1/;
/plugin/;

/{
 compatible = "brcm,bcm2835";


 fragment@0 {
  target = <&i2s>;
  __overlay__ {
   status = "okay";
  };
 };

 fragment@1 {
  target = <&i2c1>;
  __overlay__ {
   #address-cells = <1>;
   #size-cells = <0>;
   status = "okay";

   wm8804@3b {
    #sound-dai-cells = <0>;
    compatible = "wlf,wm8804";
    reg = <0x3b>;
    PVDD-supply = <&vdd_3v3_reg>;
    DVDD-supply = <&vdd_3v3_reg>;
    status = "okay";
   };
  };
 };

 fragment@2 {
  target = <&sound>;
  hifiberry_digi_pro: __overlay__ {
   compatible = "hifiberry,hifiberry-digi";
   i2s-controller = <&i2s>;
   status = "okay";
   clock44-gpio = <&gpio 5 0>;
   clock48-gpio = <&gpio 6 0>;
  };
 };

 __overrides__ {
  clock44_gpio_pin = <&hifiberry_digi_pro>,"clock44-gpio:4";
  clock48_gpio_pin = <&hifiberry_digi_pro>,"clock48-gpio:4";
 }; 

};
  • Compile this file with:
dtc -@ -I dts -O dtb -o hifiberry-digi-pro-remap.dtbo hifiberry-digi-pro-remap-overlay.dts
  • Copy it to the correct system location:
sudo cp hifiberry-digi-pro-remap.dtbo /boot/overlays/

Use the new overlay

Steps:

  • Open the file config.txt (/boot/config.txt) in editor.
  • search for the line dtoverlay=hifiberry-digi-pro
  • make it a comment by putting an # before it so it looks like:
#dtoverlay=hifiberry-digi-pro
  • Create a new line just below it with :
dtoverlay=hifiberry-digi-pro-remap,clock44_gpio_pin=16,clock48_gpio_pin=6 
  • Save the file an (re)boot the Pi

If you aren’t familiar with how to edit the file on the Pi with SSH, just remove the SD card an put the card in your normal computer.

If you want to be sure and check if the overlay is correctly loaded else then by playing aa 44.1kHz based file run from the SSH console:

sudo vcdbg log msg |& grep -v HDM

In the output the following lines should appear:

002107.626: dtdebug: Opened overlay file 'overlays/hifiberry-digi-pro-remap.dtbo'
002109.778: brfs: File read: /mfs/sd/overlays/hifiberry-digi-pro-remap.dtbo
002155.779: Loaded overlay 'hifiberry-digi-pro-remap'
002155.842: dtparam: clock44_gpio_pin=16
002156.047: dtdebug: Found override clock44_gpio_pin
002156.100: dtdebug:   override clock44_gpio_pin: cell target clock44-gpio @ offset 4 (size 4)
002156.569: dtparam: clock48_gpio_pin=6
002156.788: dtdebug: Found override clock48_gpio_pin
002156.841: dtdebug:   override clock48_gpio_pin: cell target clock48-gpio @ offset 4 (size 4)

Update 2020-09-14:
In the article DDDAC1794 build is shown how the power supplies are connected. The Isolator isn’t fed with 6.5VDC. I use 2x times 5V(dirty + clean ) for it. The power supply for the Isolator is coming from the 5V connector on top of the Hifiberry. Therefor the extra regulator of the Isolator is bypassed and we can use a more common voltage of 5V.

moOde MPD Tweaks GUI

2020-09-14 The upcoming 7.0.0 release of moOde contains another patch of me, that will make the one below obsolete.

The moOde Audio Player MPD configuration only support a very small subset of the available MPD options. The one that are supported comes with a very nice user interface. Only sometimes I just want to try unsupported or even new MPD options.

Just editing the mpd.conf isn’t an option, because Moode will overwrite the configuration file. You can work around it by modifying the Moode MPD configuration generator. But that isn’t very flexible. This article provide a patch to make experimenting with MPD a little bit easier by using the web interface of Moode.

On the bottom of the MPD configuration page an MPD Tweaks section is added.

When enabled two text input boxes are shown:

One for general parameters and one for the default output device. It doesn’t provide a very rich interface, but it beats changing the MPD configuration generator by hand. Multiple options can be set separated by ‘;’.

When the tweaks are disabled, the settings are still kept in the database only it isn’t used. This makes it easier switch on and off the settings.

Any parameter added to the MPD Tweaks General or Device parameters will override any parameter set by Moode it self.

In the final generated MPD.conf it is shown which parameters are coming from the MPD Tweaks settings:

Install the MDP Tweaks Patch

wget https://www.bitlab.nl/wp-content/uploads/2020/04/moode_mpd_tweaks.patch
wget https://www.bitlab.nl/wp-content/uploads/2020/04/moode_mpd_tweaks.sql
cd /var/www
sudo patch -b -p2 < /home/pi/moode_mpd_tweaks.patch
sqlite3 /var/local/www/db/moode-sqlite3.db < /home/pi/moode_mpd_tweaks.sql
sudo systemctl restart php7.3-fpm

Or if you want to download the patches yourself:

All due the patch is installed, it is still hidden from the user. We need to unlock it by setting a field in the database like:

$ sqlite3 /var/local/www/db/moode-sqlite3.db 'UPDATE cfg_mpd  SET value="1" where param="mpd_tweaks_unlock";'

Usage

Go to the MPD configure page and on the bottom you will find the MPD tweak. Default it is disabled.

To enabled it:

  • change the toggle button to on
  • press the set button next to it

Now the additional text input for general and device parameters should be present:

Enter the configuration parameters separated by “;”. See the original MPD documentation for the available parameters.

For example adding log_level "verbose" general parameters adds message to the /var/log/mp/log file.

DDDAC 1794 Build

This article is about building my own version of the DDDAC 1794 NOS DIY dac. Designed by Doede Douma. The NOS stands for Non Over Sampling DAC, without any filtering.

More info:

There is a massive thread diyaudio about the DDDAC 1794; nos-192-24-dac-pcm1794-waveio-usb-input. It can be a little overwhelming; it contains today almost 8000 messages. In 2017 it were only 6000 messages to read.

Audio Creative has published some nice article about this DAC. They are also the official channel to for available DIY DDDAC 1794 kits.

You can start a DDDAC 1794 NOS build very basic and depending on your budget and time extend it in time. I started my build in 2017 and completed most at the beginning of 2018.

In its most basic form it contains:

  • Power supply (kit available, but of course you can use your own)
  • Mainboard (sold as kit)
  • One or more DAC boards (sold as kit)
  • Output decoupling choice (default a cheap capacitor is supplied)
  • An enclosure and even that is an option.

In the most basic form only a SPDIF input is available. Other sources can be connected to an I2S input.

Specs of this build:

  • DDDAC 1794 subsystem exist out of:
    • 1x Blue Mainboard.
    • 2x DAC with Tent boards.
    • 2x Cinemag 600/600CLI Transformers as output decoupler.
  • Raspberry Pi 3B
    • HifiBerry Digi+ Pro as I2S source for the DAC.
    • An Allo Isolator for galvanic isolation between the buildin Pi and HifiBerry + DAC.
    • Moode Audio as software distribution.

Special features of this build:

  • Nice enclosure with:
    • OLED Display with information about the current track
    • Source button to choose from:
      • Raspberry (long press of the source button pause or continue current track)
      • Digital Source 1 SPDIF/Toslink
      • Digital Source 2 SPDIF
    • Soft power down for Raspberry
  • Allo Isolator mod to use both Crystals from the Hifiberry
    • Allo Isolator doesn’t required 6.5VDC
  • Software mods for:

All schematic, drawings, tweaks etc can be found at my github repo dddac1794build.

Article Content:

  • Overview
  • Main board + DAC modules
  • Power Supply
  • Output decoupler
  • Raspberry Pi
  • Enclosure
  • Source selection
  • OLED Display
  • Soft power down
  • Part list

System Overview

Overview is provided by three diagrams:

  • Blocks
  • Actual used electronics and global interconnections
  • Electrical scheme (kiKad)

The functional blocks of the system are:

This system DDDAC 1794 building blocks

The used electronics and connections are shown in the following diagram:

Connections between the blocks

The exact connection between the modules are shown in the diagram below:

Schematic of the system

The remainder of the article provide more detail of some of the modules.

Main board + DAC modules

The DIY kits supplied by Audio Creative are beautiful kits. You directly see that PCB are high quality. SMD components are already mounted on the PCB, you only need to solder the through hole components your self.

It includes silver wire for connecting the DAC with the main board. The kit also include Dale resistors for the I/V conversion. If you like to use silver solder, you can buy also a small amount from Audio Creative. You can find the construction documentation and more also on the DDDAC page of Audio Creative.

DDDAC1794 main and DAC module kits
Assembled main module
Assembled DAC module
Main with a single DAC module

Currently my system contains 2 DAC modules and have room left for a third DAC module.

Power supply

For the Mainboard and DAC boards a stock DDDAC 12V PS kit is used.

DDDAC1794 12V PS

The other components use 5V, but no DDDAC 5V PS kit is used for it. The 5V PS exists out of a clean 5V and a dirty 5V. The clean is used by the Hifiberry and the Allo Isolator (at least the clean part of the isolator). The dirty 5V by the Pi and other auxilary components. The 5V uses a toroidal transformer with secondary 2x6VAC, 30W. Followed by a dual DIYIHNK 4.17uV 5V/1A regulator. It uses a TPS7A4700 for regulation.

Dual DIYIHNK 4.17uV 5V/1A regulator

The Raspberry Pi is direct fed by the 5V dirty on the GPIO connector 5V, the USB PS connector is not used.

To the Hifiberry a connector on position P3 is added. This is used to fed the clean 5V to the Hifiberry and the Allo Isolator. If you had used the PS connector of the Allo Isolator it self, that voltage had to be 6.5VDC, because the voltage drop of the onboard 5V regulator.

By the way both the Raspberry, HifiBerry and the Allo Isolator all have onboard 3.3V regulators that are used to fed the electronics onboard.

In my build there is no connection between the dirty and clean ground. Make sure that in that case you also have the mod for the clock select.

Output decoupler

I replaced the default no name caps first by 2x MKT-Capacitor ax. 2,2µF ERD 1813 NOS. Later followed by Cinemag 15/15b transformers.

And finally settled with two Cinemag CLMI 600/600C to decouple the outputs. Both are nicely mounted to the side of the enclosure with a 3D printed mounted (Thanks Henk!).

Cinemag transformer mount

Raspberry Pi

Hardware

The Raspberry Pi is in this system not only important as a I2S source for the DAC, but the Raspberry Pi also controls most of the auxiliary modules like the display and source selection.

You can see this back in use of the Raspberry expansion header:

Raspberry Pi GPIO usages

The hardware is stacked as following:

  • On the bottom the Raspberry Pi
  • Followed by a PiFace GPIO Shim
  • Then the Allo Isolator
  • And finally the HifiBerry Digi+ Pro

The PiFace GPIO Shim makes it possible to breakout the GPIO and others pins, while continue stacking other boards.

PiFace GPIO Shim -Header Breakout

Special attention is needed for letting the Allo Isolator and HifiBerry work together and still honor the separation between the dirty and clean 5V modules. See an other article for more details.

All GPIO interfacing including the power supply for the Pi connected to the PiFAC GPIO Shim.

Operating System

Tested a lot of software distributions. Started with Rune Audio and currently Moode Audio 6.4.2 is used. It provides an easy to install system, a nice (web) GUI and is easy to mod.

It requires two configuration settings for make it work for this specific system:

First select the the HifiBerry Digi+ Pro as I2S device, which will require a reboot.

Second force to use 24 bit as output signal, source that aren’t 24 bit are converted. You can also provide a fixed upsample rate. See the article Selective Resample for an other interesting option.

Additional software for the display, source and soft power are handled in the previous paragraphs.

Enclosure

The chosen enclosure is a model of the Hifi2000 Galaxy line, the Galaxy Maggiorato GX388 330 x 280mm x 2HE 10mm front panel SILVER, including a Base Galaxy GX.

Galaxy Maggiorato

The base plate makes it easy to mount all components first on the base plate and then place the base plate in the case.

Base Galaxy GX

To see if everything fits the following floorplan is used.

floorplan

For designing the front and pack panel I used Front Panel Designer from Schaeffer. Within this application you can directly see the cost of the design and place an order with Schaeffer. Also it provides nice renders of the panels.

The project files can be download from:

I wanted the display a little bit sunken in the front, but not the full 10 mm. Therefore also on the back some material should be extruded to bring the display more to the front.

front panel
back panel with deepened location for the display PCB

I am very satisfied with the end result:

Source selection

The system has three sources:

  • Raspberry Pi, I2S
  • Digital 1, SPDIF or Toslink
  • Digital 2, SPDIF

Selecting the source is done with momentary switch next to the display. The switch is directly connected to the Raspberry Pi.

On power on default Digital 1 is selected. When the Raspberry is booted the Raspberry is default selected as source and the switch led is turned on. As long as the Raspberry is booting the screen will stay dark.

A short press will select the next source. If the Raspberry is selected a long press will pause or continue the current track.

The led current is to much for the Raspberry it self, the soft power down PCB contains a transistor to drive the led.

A dual relay module is used for selecting between I2S or SPDIF and selecting between Digital 1 or 2.

Dual Relay Module

The relay module is also controlled by same daemon on the Raspberry Pi as for controlling the display. The module is mounted against the back panel of the enclosure.

OLED Display

The system contains a small display to show source information.

The display specs:

  • Size :1.3″
  • Type: OLED
  • Resolution: 128×64
  • Interface: I2C
  • Driver: SSD1106

The display shows information about the Raspberry or the Digital Source (1 or 2):

If the Raspberry Pi is active the following information is show:

For controlling the display a daemon is running on the Pi. This daemon is written in Python and will work uses two libraries for the main functionality:

  • pyhton-mpd2 is used to connect to MPD for reading out information about the current song and playlist.
  • python-luma.oled is used to drive the display itself.

The daemon also contains the functionality to read the source button and control the led in the source button. Due using the MPD client library, you don’t have to integrate with Moode Audio itself. It will work on any MPD based or compatible audio player, even over the network if you want a separated display.

Soft power down

There is risk to corrupt the SD card of Raspberry Pi when it isn’t proper shutdown and I do power down my audio equipment when not in use, a solution is needed.

A software power down module is developed for this purpose. See the article Raspberry Soft Power Down for more information.

Part List

To give a clue about the number of parts and investment required hereby the list of my specific system.

Small parts like wiring, additional nut, bolts and some connectors are not on the list.

nrdescriptionsubsystemSuppliercountpricetotal
1DDDAC 1794 blue mainboarddacAudiocreative1€ 165,00€ 165,00
2DDDAC 1794 DAC boarddacAudiocreative2€ 159,00€ 318,00
3DDDAC 12V PSdacAudiocreative1€ 94,00€ 94,00
5DIYINHK Ultra Low Noise PSstreamerDiyinhk1€ 41,82€ 41,82
6Block RDK 30VA/2x6VstreamerConrad1€ 19,64€ 19,64
7Raspberry 3streamerSOSsolutions1€ 36,95€ 36,95
8SD Card 8 GBstreamerSOSsolutions1€ 7,95€ 7,95
9Hifiberry Digi+ ProstreamerSOSsolutions1€ 42,95€ 42,95
10AC Main C14 Chassis partcaseConrad1€ 5,25€ 5,25
11Fuse 20mmcaseConrad1€ 1,20€ 1,20
12Torx147 Optical SPDIF Receiver 192kcaseDiyinhk1€ 3,35€ 3,35
13CinchConnector Rean AV NYS367-9caseConrad1€ 4,36€ 4,36
14CinchConnector Rean AV NYS367-2caseConrad1€ 4,36€ 4,36
15CinchConnector Rean AV NYS367-4caseConrad3€ 4,36€ 13,08
16Cinch-connector internalcaseConrad1€ 1,48€ 1,48
17OLED Display 1.3″ I2CcaseDiymall by ebay1€ 8,51€ 8,51
18Galaxy Maggiorato GX388 330 x 280mm x 2HE 10mm front panel SILVERcaseModus1€ 53,00€ 53,00
19Base Galaxy GX345/348/385/388caseModus1€ 8,00€ 8,00
20Case feetscaseModus4€ 3,50€ 14,00
21Frontplate JobcaseSchaeffer1€ 58,89€ 58,89
22Backplate JobscaseSchaeffer1€ 42,38€ 42,38
23Relais board arduino 1x relais (active high)caseDX1€ 2,30€ 2,30
24Relais board arduino 2x relais (active low)caseDX1€ 4,00€ 4,00
25Attiny85case?1€ 2,30€ 2,30
26Switch TRU COMPONENTS LAS1-AGQ-22E, BLcaseConrad2€ 19,82€ 39,64
27Allo IsolatorstreamerSOSsolutions1€ 60,95€ 60,95
28Cinemags CMLI-600/600 setdacAudiocreative*1€ 249,00€ 249,00
29PiFace GPIO ShimstreamerKiwi Electronics1€ 5,95€ 5,95

The partlist can be downloaded at:

AMIGA Keyboard tester

AMIGA keyboard tester

During the a repair of an Amiga 2000 keyboard I didn’t found it very handy to use my Amiga as tester for a defect keyboard:

  • During testing, to prevent damage with unplug or plugin of the keyboard, it requires power down of the Amiga.Which takes a lot of time and proceedings (the boot, shutdown etc)
  • Change to damage the keyboard port of the Amiga if something was really wrong

So the idea began to take shape of we could build a simple tester.
Next to me laying was a Arduino Uno with a Multi Functional Shield laying around. And the Amiga Keyboard protocol doesn’t seem to hard to me.

Hmmm lets first see if you one else already did use an Amiga Keyboard on an Arduino.
And yes the is. The purpose of the solution in the thread, is using the Amiga keyboard on other computer with Arduino as USB adapter. I used the script provided in message #90 as basis. It is original written by Janne Lof, but I can’t find the original reference. You can find the modified Arduino sketch at :

The Arduino Uno doesn’t support using the device as an USB hid. So first get rid of the the USB code and use an Serial.print to test if it works. And then switch to use the 4x 7 segments display.

Amiga 2000/3000 pin out

Lets connect a suitable connector for my Amiga 2000 keyboards. See AMIGA Keyboard connector pin-outs for pin-out of the other models. Due the shield already taken a bunch of pins, we need other free pins to use. Preferred some that are already available on the unused headers on the shield.

#define PIN_KLCK 6 // black (was 8)
#define PIN_KDAT 5 // brown (was 9)

For testing we use serial port, after testing the serial code is disabled. In the Arduino IDE under the Tools menu is a serial monitor. In setup make sure Serial.begin(9600); is called. Ok that seems to work.
Now the script will be changed to:

  • Show the amiga (hex) keycode on the two first digits of the display. 
  • On a key press the dp(=point) on the last segment will be on.
  • On a key release the dp(=point) on the last segment will be turned off again.
  • If an out of sync situation occurs the display show “____”.

In general it works well, but sometimes “____” or the key release doesn’t react. Lower the time of kdat low seems to improve it, but set to short, according to the protocol, some hardware will refuse to work it.

For reference it is nice to have the Amiga Keyboard codes at hand:

My Mitsumi based Amiga 2000 keyboards works fine, but the Cherry based version doesn’t. That board takes to much power from the USB 5V.

On my bucket list for further improvements:

  • Joystick test
  • Mouse test
  • Maybe on other SPI or I2C display for more rich feedback.
  • How to deal with the Cherry board (separated supply … ?)

mBlock Arduino Multi Function Shield

My kids like easy coding with Scratch or mBlock. I found a nice Arduino shield for them to play with, only it could only be programmed with the Arduino IDE. Luckily mBlock provided a way to extent the mBlock environment.

The Arduino Multi Function Shield is a low cost shield provided by several suppliers.
It contains a lot of basic IO for fun experiments. Typical the stuff you put normally first on a breadboard.The shield contains:

  • 3x push switches
  • 4x leds
  • 1x buzzer
  • 1x potentiometer
  • 1x 4 segments 3461 BS display 
  • And some interfaces for optional io/sensors

You can code it your self in the Arduino IDE or use an existing library like the arduino-multi-function-shield library

mBlock

mBlock  is a Scratch like IDE for making computer program, but it also supports several hardware platforms like the mBot, but also Arduino. My kids use this very accessible environment for the mBot, but is also support other hardware like the Arduino Uno.

mBlock environment web or app

mBlock Extension

To make the it able to use the Arduino shield in mBlock, a so called extension should be created for it in the mBlock online extension builder.
When a extension is finished it can be published for approval. In the will so up in the Extension store.

In the extension center you create for a certain category a number of blocks.

new block in the extension builder

Each block can be hooked to matching C code for :

  • declare
  • setup
  • code
set led block configuration

For use it needs to be added to you mBlock environment. Unless you want to hack the extension yourself, you can use the MF Shield from the extension center.

MF Shield extendsion in the extension center

MFS Blocks

Below are the new blocks created for use with the MF Shield and are available in mBlock:

Overview of the MF Shield blocks in mBlock

The MFS library use a Timer in the background to update the leds, display segments and read the switches.The MFS library has a very nice way to read the switches; it puts every event in a round robin queue.The function MFS.getButton get the first one from the queue. Using this function several times in the main loop is a bad idea.
That’s why the functionality is splitted in two;

  1. get first entry in the queue – (get button state block)
  2. eval if a certain key is pressed – (is button [x] [pressed] in [button state] block)

Read the switches

If you only have one button test you can use the get button state block directly in the eval block. If you have multiple you first need to store the button state into a variable and use that variable in the eval:

Only one switch test in your program:

Use multiple switches in your program:

Leds

Potentiometer

Display

Try-out extension

Try out the extension before it is published (before is applied to and approved by the mBlock Des):

  1. Click in the extension editor download
  2. Save it own disk
  3. Open mBlock 
  4. Open an explorer to the downloaded extension
  5. Drag and drop it onto mBlock
  6. Restart mBlock
  7. Chose add extension
  8. Add the MFS extension to your project (project device has to be an Arduino, only tested with the Uno)

If you to update the extension repeat step 1-6.

Resources:

You can find the extension on:

Other handy links:

If display segments are used with raw data (instead of display test use set display segment) you can enable each led of the segment. A-DP are the bits of the segment.

AMIGA 2000 Cherry keyboard restoration

Some time ago I was offered a defective Amiga keyboard. It was Amiga 2000 Cherry Keyboard, one of the more rare Amiga 2000 keyboards. The previous owner informed me that the keyboard was not working at all.

This keyboard has several unique distinctive features:

  • Red Amiga keys (notice different location of those keys; there is space between those keys and the space bar).
  • Uses Cherry MX switches.
  • Double shot caps (except for the Amiga keys); not printed symbols, but two colors of plastic. Just like my C64 keyboard.
  • Small function keys.

Let’s see how far we can get the keyboard working again.

First examination

An inspection of the exterior:

  • Plain label on the front with “Amiga 2000”
  • Slightly yellowed
  • No label of id on the bottom
  • US QWERTY layout
  • Nice red Amiga keys !
  • Big ass Return key
  • Six clickers for opening the case
  • Not the ergonomic connector seen with others, but I found pictures with exact the same connector and cable so it seems to be the original.
  • Foots the bottom are missing
  • In my opinion, the keyboard wobbles on the outer edges
  • It is opened before; the six clips looks scratched

After opening the case and inspecting the internals:

  • Identification:
    • On the PCB component side 4 labels:
      • 879/00 11883 13047552 (white upper left corner)
      • Unreadable (orange above the F1/F2 keys)
      • 197 (yellow above the F7/F8 keys)
      • Unreadable (white left from the cursor key > )
    • On the solder side of the PCB as part of the PCB: Cherry 601-1435  Rev.: 0.2
  • No metal plate to support the PCB and add a nice weight to the keyboard.
  • Old school lower quality pertinax PCB; the old brown stuff.
  • Damage to the traces and some pads
    • Normally on those two pads the shield cable is soldered.
    • Can be that there was to much mechanical stress and the traces came lose from the PCB.
    • The mask indicates that there should be 2 capacitors. But I’m not sure that it was ever there. Lets see if t can find photo’s of this area.
  • Due the damage above someone resoldered the shield cable
    • The solder looks no good.
    • It is connected to pin of a capacitor.
    • The trace did come loose from the pcb. (to hot welding temp used ?), so the capacitor is now floating.
  • Both pins pf the 6 MHz crystal looks to have bad solder joints. One is even loose.
  • PCB lacquer looks a little lumpy, nothing serious just aesthetic.
  • No other damage visible.

Some research

After some searching found that the PCB ID Cherry 601-1435 matches  with Amiga Commodore   G80-0879HAU (601-1435)  Cherry MX Black. It looks like that this keyboard is only used for the first batch of Amigas A2000A r4.x (the German design) from 86/87. The USA based sites find it a rare keyboard, but I think in Europe it isn’t because the A2000A is never sold in the states. Nice article can be found on AmigaLove.
On deskthority information and pictures are available.Based on one of that pictures:

  • It has the same cable and connector, so it it original. On AmigaLove it was stated that this keyboard has the ergonomic connector, but this isn’t always the case. The one on deskthority and mine obtained models have a different connector.
  • The pads (with the broken traces, on the images below the 4 holes right next to yellow wire) which are empty on my board are also empty on that picture, good news.
Image from deskthority.

It seems that the PCB from deskthority doesn’t have the brown pertinax PCB.

The connector is a 5-pin DIN plug. The pins are:

  1. Clock,
  2. Data,
  3. in not used.
  4. Ground,
  5. +5V.

The keyboard controller is made out of one of the first Intel 8 bit micro controllers (MS48 family):

  • Intel P8049AH (from 1977!)
  • ET 2716 Q1 (EPROM) with version 467
  • 74LS373
  • 74HCT373
  • Crystal 6MHz

The good thing about this is; no special MOS chips involved. All later Amiga keyboards use a MOS keyboard controller. The P8049AH contains 2k ROM, it isn’t used and relies on an external EPROM for the program.


I’m not sure about it, but it looks that this keyboard PCB is produced by Cherry Germany and not Commodore. Cherry did use this controller logic with several of their other products. They used instead of P8049AH also P8039AH, which is the same model but without internal ROM. Are pin compatible and can de swapped. It is configured to use the external EPROM.

The repair attempt

Shield

Based on the damage found, I think that the ground is floating and not connected to the PCB. The damage is related to relocated and resoldered (with to much heat?)  of the wire connected to shield carton. Lets first correct that by cleaning up add add a bridging wire and remove the shield wire.  

Ok caps light will now turn on at startup, but further it is still dead.
Remove the bridge wire again and provide are more permanent solution;

  • Desolder the bridge wire 
  • Scrap the lacquer for 3mm from trace that is left, but unconnected. Clean it with IPA, followed by flux with heating.
  • Again clean with IPA and apply flux.
  • Finally apply solder to the fresh cleaned copper.
  • Measure the connection

If keyboard is working again restore the shield wire by an little bit more easy to handle wire and also solder it on an different location.

Crystal

Next in line are the bad solder joints on pad/pins of the crystal. Not clearly visible in the image, but both pins are loose in solder joints. Just reflow the joints. To be sure measure the crystal is still working check it with the scope. And the answer is no. Maybe are the bad joints related to the mounting method, it hings on the legs and provide mechanical stress to the joints. The crystal will be replaced and will get little support of a drop soft (removable) glue.

EPROM Check

Next I will check it the EPROM is this functioning. For this I need an ROM image to match it against. This ROM is part of the Mame emulator a2000kbd_g80_us device.
Size and checksums are provided:

namesizecrcsha1
467.u42048fb92a773e787dc05de227f30a47ac5b9ee7a355c2e9e693b

This source did only provided the checksums, but not the ROM it self. The checksums are just fine for verify that the content of the ROM is still ok, but I like to also have the image itself. Luckily the site retroroms provides all Mame roms including the a2000kbd_g80_us.zip rom.First check if the ROM matches the checksums provided above. I use the hex editor HxD for such things.
Because the ICs on the keyboard PCB are soldered without sockets, I first have to desolder (so happy with my ZD-915 desoldering station !) the EPROM.

Now I can verify, using an old  programmer Leap EP-1 with Windows 98 SE, if the content of the EPROM matches the ROM image. And yes it does.

The EPROM checks out to be ok!

New Shoes

Instead of soldering it back, I decide to first solder an DIL socket back. Normally maybe not wise for keyboard to have ICs in sockets, but it makes future repair, checks and replacements easier. And this keyboard will get an easier life that the previous 30 years, therefore I trust that the IC will remain in its socket. And while busy with the iron lets give the other ICs also some shoes 😉

Spare parts

To be prepared see if I can get replacement parts, if needed.T he two 74xxxxx can be obtained from normal electronics stores.  The CPU and EPROM is different story. Luckily there is a company specialized in such parts and ask reasonable prices. This company is Slawmir in Poland (also present on ebay, use the filter “seller:slawmir” ).
An used P8039AH CPU and an ET 2716 EPROM will cost less then €5, lets order it for just in case we need it.

Schematic

Lets check the traces again, this time not only optical but also with the multi-meter.
To make sure everything is tested correct a schematic of the electronics would help, I could not find it only.  Lets recreate an schematic with KiCad. The PCB is self and the MCS-48 Family User’s manual are used to create the scheme.
Is fairly basic setup:

  • Timing circuit .
  • Reset circuit.
  • Extern EPROM with latch for the lowest 8 bits.
  • Additional 8 inputs with a HCT373.
  • Use port P1 and part of port P2 for IO.
  • The kclock and kdata use both two pins; one output and an interrupt input.

The only tricky one is the reuse of the for lowest bits of P2 for both address and IO.

Now we have a schematic, additional I will also create the PCB layout with only component placement (no traces):

Both together make it very efficient to measure the connections without constant following the trace. And because the ICs already have sockets, let get the IC’s out to make the measurement even more easy and have no risk at damaging the old ICs.Just following the connection from pin to pin in the scheme to see if it works. Also check for double connections.

Trace Connections

We start with measuring only the area where the control electronics are, not the connection of every Cherry MX switch. I only will follow a few of those just see if at least one switch and its connections are correct.
After measuring with the multimeter at least the A8 and A9 signal seems not connected to the EPROM.
Finally with an inspection with 8x zoom showed very thin crack in the upper layer of the underside of the PCB.The crack is spread over 6 traces, one affected (A10) is still working. Clearly I need some better tooling for visual inspection.

Restore A8 & A9

First quick fix is to temporary add some bridge wires for A8 and A9 to see if this is the last error to fix.
Boot with AmigaTestKit (formerly SysTest) And yes it works! Only the O and Z aren’t working, probably due the other broken traces (checked the switches).

Remove the coating from the damaged traces and cleanup with IPA and flux.

Then apply flux and with a very small soldering tip apply some tin on it. Steady hand required each trace is less then a 0.4 mm width.

And after soldering each broken trace all keys work again.Finish this with a strong lacquer to seal it.

Cleaning and put it back together again

Time to clean the enclosure and keys. All keys are removed and cleaned piece by pieces.

Now the keys are removed, you can seen that it are really double shot keys; no printed symbols, but used two different colors of plastic. This guarantees that the colors will not fade in time or use. Only the Amiga keys are an exception, those are still printed. All A2K,A3K,A4K keyboards that come after this model all have printed symbols.

Hmm I don’t like the way the spacebar is moving. It seems that one guidance of the stabilizer is broken.

Use some power glue to restore it and add some soft (removable) glue to outside to provide some support.

If that doesn’t work I can always order an original-cherry-2u-pcb-stabilizer.
Replace the missing foot rubbers by fresh new ones.

Due the clips of the enclosure closing and the the tight space for the keyboard cable, I use the following order for putting the enclosure back:

  • Take the upper part of the enclosure.
    • Place it up side down.
    • Place the PCB.
    • Make sure the keyboard cable is placed correct .
    • Place the two internal screws, but not fully tight them.
    • Move the PCB to most up.
    • Now you can tight both the screw.
  • Take the lower part of the enclosure
    • Place it up side down
    • Place the shield (with metal folly to the plastic)
    • Fix it with some tape or fold the folly in place with your hand
  • Now you can place both together and press the clips

And the end result:

Bonus

Because the schematic and PCB layout are created in KiCad, we also now have a nice render of the PCB. Including identification of the problems areas. Each of the three areas was enough to make the keyboard not work. This is the first I had to repair something with a triple error with the same effect; a dead keyboard.