Luggage lock troubles

05.10.2017 18:32

Back in August an annoying thing happened while I was traveling in Germany. My luggage lock wouldn't open. I was pretty sure I had the right combination, but the damn thing would not let me get to my things. I tried some other numbers that came to mind and a few futile attempts at picking it. I then sat down and went through all 1000 combinations. It would still not open. At that point it was around 1 am, I had a long bus ride that day and desperately needed a shower and sleep. I ran out of patience, took the first hard object that came to hand and broke off the lock. Thankfully, that only took a few moments.

Broken luggage combination lock.

This is the culprit, reassembled back to its original shape after the fact. It's a type of a 3-digit combination lock that locks the two zipper handles on the main compartment of the suitcase. It came off an "Easy Trip" suitcase of a Chinese origin. It's obviously just a slight inconvenience for anyone wanting to get in, but I didn't want to ruin my suitcase and dragging my clothes through a narrow crack made by separating the zipper with a ballpoint pen felt uncivilized.

Inside luggage combination lock in locked position.

This is how inside of the lock looks like in the locked position. There are three discs with notches, one for each digit. Placed over them is a black plastic latch with teeth that align with the notches. In the locked position, the latch is pushed right by the discs against the horizontal spring in the middle right. In this position, the two protrusions on the top of the latch prevent the two metal bolts from rotating in. The bolts go through the loops in the zipper handles. They also connect to the button on the other side of the lock, so in this position the button can't be moved.

Inside luggage combination lock in unlocked position.

When the right combination is entered, the teeth on the latch match the notches on the discs. The spring extends, snaps the latch left and moves it out of the way of the bolts. The button can be pressed and the bolts rotate to free the zipper.

So, what went wrong with my lock? When I removed the lock from the suitcase, the spring that moves the latch was freely rattling inside the case. Without it, the latch will not move on its own, even when the right combination is set. I think this is the likely cause of my troubles. The spring does not have a proper seat on the fixed end, so it seems likely that a strong enough knock on the lock could displace it. I guess that is not beyond the usual abuse luggage experiences in air travel. After replacing the spring the lock works just fine. I'm not using it again though.

Would it be possible to get my toiletries in a less destructive way? If I knew that the problem was the displaced spring, the solution would be simply to set the right combination, make sure the button is not pressed to remove friction on the latch and then rotate the suitcase until gravity moved the latch out of the way. Another possibility would be to pen the zipper and then unscrew the lock from the inside. Unscrewed lock is easily disassembled and removed from the zipper handles, but finding the screws and space for a screwdriver might be impractical with a full suitcase.

Posted by Tomaž | Categories: Life | Comments »

Testing Galaksija's memory

26.09.2017 20:13

Before attempting to restore the damaged laminate of Mr Ivetić' Galaksija I wanted to have some more confidence that the major components are still in working order. The fact that the NAND gate in the character generator patch was still working correctly gave me hope that the board was not connected to a wrong power supply. That could do serious damage to the semiconductors. Still, I wanted to test some of the bigger integrated circuits. Memory chips are relatively straightforward to check. They are also mounted on sockets on this board, so they were easy to remove and test on a breadboard.

Character generator ROM on the Galaksija circuit board.

This is another post in the series about restoration of an original Galaksija microcomputer. Galaksija is a small home microcomputer from former Yugoslavia that was built around the Z80 microprocessor. It used EPROMs, a predecessor to modern flash memory, to store its simple operating system. As it was common at the time, Galaksija could not update its system software by itself. In fact, western home computers typically stored such software in mask ROMs. There, code and data was programmed by physically etching a pattern into the metal layer of the chip. Even though Yugoslavia had semiconductor industry that was capable of making ROMs, producing a custom chip was not economical for Galaksija, which had relatively low production numbers.

EPROMs removed from the Galaksija circuit board.

Galaksija originally came with two EPROMs. The first one, called ROM A in the manual and marked Master EPROM here, contains 4 kB of Z80 CPU machine code and data for basic operations. It includes specialized functions related to the hardware: video driver for generation of the video signal, keyboard read-out as well as modulation and demodulation routines for saving data to an audio cassette. Some higher-level functions are also included. There's a simplistic terminal emulation with a command-line interface, a stack-based floating point calculator and a BASIC interpreter based on the TRS-80. My incomplete Galaksija disassembly contains more details.

The second EPROM is the character generator ROM. Galaksija's video output is designed fundamentally around text. The frame buffer contains only references to characters that are to be drawn on the screen. How these characters look, the actual pixels you see, are stored in the character ROM. This is similar to how text mode worked on old PCs and was done to limit the RAM use. In fact, a bitmapped image of the whole screen would not fit into the 2 kB of Galaksija's RAM. Of course, this means that only very limited graphics can be displayed. By sacrificing a lot of RAM and hacking the video driver, some limitations can be worked around.

Iskra EMS6116 static RAM on a Galaksija computer.

Galaksija uses static RAM for its working memory. Using costly static RAM was obsolete even in the early 1980s and is the main reason why Galaksija originally only had 2 kB of RAM (which could be upgraded to 6 kB by inserting up to two more identical 2 kB chips). The much larger dynamic RAM would require more complicated circuitry to interface with the CPU and was only added in the later Galaksija "Plus" upgrade. Interestingly, the Z80 CPU was originally meant to use dynamic RAM and includes functionality to perform the required refresh cycles. However in Galaksija this function was instead used for video generation. This board uses a rare EMS6116 RAM chip made by Iskra Semiconductors.

Galaksija's ROM A connected to Arduino Mega.

After carefully removing all three memory chips from the board I wired them up to an Arduino Mega using a breadboard and a rat's nest of jumper wires. I used a slightly modified Oddbloke's RomReader sketch for dumping the EPROM contents. Since the 6116 RAM has an electrical interface that is very similar to 27-series EPROMs I also used this sketch as a base of my RAM test. The RAM test sketch first wrote a test pattern (bytes 00, FF, AA and 55) to all RAM addresses and then read it out to check for any bad bits. Sources for both Arduino sketches are available here.

The first few runs of the EPROM dumper showed that ROM A didn't read out correctly. Its contents differed from what I had on record and consecutive reads yielded somewhat different results. After double-checking my setup however it turned out that my Arduino Mega board only puts out around 4.5 V on the +5 V supply. This is on the lower specified limit for these EPROMs, so it could explain occasional bad bits. After supplying a more stable voltage to the EPROM from a lab power supply, ROM A read correctly. Its contents were exactly the same as what I had on record (and what I use on my Galaksija replica).

Two variants of the Galaksija character set

Similarly, the RAM and the other EPROM also checked out fine. However, in contrast to ROM A, the character ROM contents differed from what I had expected. After a closer look at the binary dump (using chargendump tool from my Galaksija tools to visualize its contents) it turned out that the difference is in characters 0 and 39 (ASCII hex codes 40 and 27 respectively). These two characters are used to draw the two halves of the logo that is displayed before the distinctive Galaksija READY command prompt.

Galaksija screenshot

The character ROM I use on my replica contains an arrow-like logo of Elektronika inženjering. The ROM in this Galaksija's image contains the game-of-life glider logo of Mipro design. Both of these logos are etched into the copper on the solder side of the Galaksija circuit board:

"design mipro" logo on Galaksija PCB.

Elektronika inženjering logo on Galaksija PCB.

I don't know why there are two versions of the character ROM in existence and how old each of them is. As far as I know, both of these companies were involved in the manufacture of the original do-it-yourself kit parts (including the PCB and the keyboard). Wikipedia currently says that later factory-built computers were built by Elektronika inženjering, so it is possible that the arrow logo version is the more recent one. The blurry screenshot from the original Galaksija manual suggests that the glider logo was used when the screenshot was made. This seems to confirm that the glider logo is older.

Figure showing Galaksija's character set from the Galaksija manual.

In any case, both versions of the ROM seem to already float around the web, so this discovery isn't terribly exciting. The Galaksija Emulator for instance comes with the glider logo version. As far as I can remember, I originally obtained my arrow logo ROM images from the Wikipedia page. The article used to contain hex dumps, but they were since then deleted due to copyright and non-encyclopedic content concerns.

In conclusion, everything worked as expected, which is great news as far as the restoration of this Galaksija is concerned and a green light to proceed to fixing the PCB. It's also a testament to the reliability of old integrated circuits. I was pretty sure at least the EPROMs have discharged. The datasheet mentions that normal office fluorescent lighting will discharge an unprotected die in around 3 years. Considering that the chips were most likely programmed more than 30 years ago, it is surprising that the content lasted this long (the bit errors at low supply voltage I've seen might be the first sign of the deterioration though). It's also surprising that the Iskra EMS6116 survived and passed all the tests I could throw at it. Domestic chips did not have the best of reputations as far as reliability was concerned, but at least this specimen seemed to survive the test of time just fine.

Posted by Tomaž | Categories: Digital | Comments »

On piping Curl to apt-key

21.08.2017 16:52

Piping Curl to Bash is dangerous. Hopefully, this is well known at this point and many projects no longer advertise this installation method. Several popular posts by security researchers demonstrated all kinds of covert ways such instructions could be subverted by an attacker who managed to gain access to the server hosting the install script. Passing HTTP responses uninspected to other sensitive system commands is no safer, however.

This is how Docker documentation currently advertises adding their GPG key to the trusted keyring for Debian's APT:

Screenshot of instructions for adding Docker GPG key.

The APT keyring is used to authenticate packages that are installed by Debian's package manager. If an attacker can put their public key into this keyring they can for example provide compromised package updates to your system. Obviously you want to be extra sure no keys from questionable origins get added.

Docker documentation correctly prompts you to verify that the added key matches the correct fingerprint (in contrast to some other projects). However, the suggested method is flawed since the fingerprint is only checked after an arbitrary number of keys has already been imported. Even more, the command shown specifically checks only the fingerprint of the Docker signing key, not of the key (or keys) that were imported.

Consider the case where starts serving an evil key file that contains both the official Docker signing key and the attacker's own key. In this case, the instructions above will not reveal anything suspicious. The displayed fingerprint matches the one shown in the documentation:

$ curl -fsSL | sudo apt-key add -
$ sudo apt-key fingerprint 0EBFCD88
pub   4096R/0EBFCD88 2017-02-22
      Key fingerprint = 9DC8 5822 9FC7 DD38 854A  E2D8 8D81 803C 0EBF CD88
uid                  Docker Release (CE deb) <>
sub   4096R/F273FCD8 2017-02-22

However, importing our key file also silently added another key to the keyring. Considering that apt-key list outputs several screen-fulls of text on a typical system, this is not easy to spot after the fact without specifically looking for it:

$ sudo apt-key list|grep -C1 evil
pub   1024R/6537017F 2017-08-21
uid                  Dr. Evil <>
sub   1024R/F2F8E843 2017-08-21

The solution is obviously not to pipe the key file directly into apt-key without inspecting it first. Interestingly, this is not straightforward. pgpdump tool is recommended by the first answer that comes up when asking Google about inspecting PGP key files. The version in Debian Jessie fails to find anything suspicious about our evil file:

$ pgpdump -v
pgpdump version 0.28, Copyright (C) 1998-2013 Kazu Yamamoto
$ curl -so evil_gpg
$ pgpdump evil_gpg|grep -i evil

Debian developers suggest importing the key into a personal GnuPG keyring, inspecting the integrity and then exporting it into apt-key. That is more of a hassle, and not that useful for Docker's key that doesn't use the web of trust. In our case, inspecting the file with GnuPG directly is enough to show that it in fact contains two keys with different fingerprints:

$ gpg --version|head -n1
gpg (GnuPG) 1.4.18
$ gpg --with-fingerprint evil_gpg
pub  4096R/0EBFCD88 2017-02-22 Docker Release (CE deb) <>
      Key fingerprint = 9DC8 5822 9FC7 DD38 854A  E2D8 8D81 803C 0EBF CD88
sub  4096R/F273FCD8 2017-02-22
pub  1024R/6537017F 2017-08-21 Dr. Evil <>
      Key fingerprint = 3097 2749 79E6 C35F A009  E25E 6CD6 1308 6537 017F
sub  1024R/F2F8E843 2017-08-21

The key file used in the example above was created by simply concatenating the two ASCII-armored public key blocks. It looks pretty suspicious in a text editor because it contains two ASCII headers (which is probably why pgpdump stops processing it before the end). However, two public key blocks could easily have also been exported into a single ASCII-armor block.

Posted by Tomaž | Categories: Code | Comments »

BeagleCore Module eMMC and SD card benchmarks

12.08.2017 13:03

In my experience, slow filesystem I/O is one of the biggest disadvantages of cheap ARM-based single-board computers. It contributes a lot to the general feeling of sluggishness when you work interactively with such systems. Of course, for many applications you might not care much about the filesystem after booting. It all depends on what you want to use the computer for. But it's very rare to see one of these small ARMs that would not be several times slower than a 10-year old Intel x86 box as far as I/O is concerned.

A while ago I did some benchmarking of the eMMC flash on the old Raspberry Pi Compute Module. I compared it with the SD card performance on Raspberry Pi Zero and the SATA drive on a CubieTruck. In the mean time, the project that brought the Computer Module on my desk back then has pivoted to a BeagleCore module. Since I now have a small working system with the BCM1 I thought I might do the same thing and compare its I/O performance with the other systems I tested earlier.

BeagleCore Module mounted on the SNA-LGTC board.

The BCM1 is a small Linux-running computer that comes in the form of a surface-mount hybrid module. It is built around a Texas Instruments AM335x Sitara system-on-chip with a single-core 1 GHz ARM Cortex-A8 CPU. The module comes with 512 MB RAM and 4 GB eMMC chip. It is supported by the software from the BeagleBoard ecosystem and in my case runs Debian Jessie with the 4.4.30-ti-r64 Linux kernel. Our board has a micro SD card socket, so I was also able to benchmark the SD card as well as the eMMC flash. I was using the Samsung EVO+ 32 GB card.

To perform the benchmark I used the same script on BCM1 as I used in my previous tests. I used hdparm and dd to estimate uncached and cached read and write throughputs. I ran each test 5 times and used the best result.

Comparison of write performance for ARM systems.

The write performance is better with the SD card than the eMMC flash on BCM1. SD card on BCM1 is also faster than the SD card on Raspberry Pi Zero, although this is probably not relevant. It's likely that the Zero performance was limited by the no-name SD card that came with it. eMMC on the BCM1 is slower than on Raspberry Pi CM.

The 16.2 MB/s result for the SD card here is somewhat suspect however. After several repeats, the first run of five was always the fastest, with the later runs only yielding around 12 MB/s. It is as if some caching was involved (even though fdatasync was specified with dd).

Comparison of read performance for ARM systems.

Interestingly, things turn around with read performance. BCM1's eMMC flash is better at reading data than the SD card. In fact, BCM1 eMMC flash reads faster than both Raspberry Pi setups I tested. It is still at least 3 times slower than a SATA drive on the CubieTruck.

Comparison of cached read performance for ARM systems.

Cached read performance is the least interesting of these tests. It's more or less the benchmark of the CPU memory access rather than anything related to the storage devices. Hence both BCM1 results are more or less identical. Interestingly, BCM1 with the 1 GHz CPU does not seem to be significantly better than the Compute Module with the 700 MHz CPU.

My results for the BCM1 eMMC flash are similar to those published here for the BeagleBone Black. This is expected, since BeagleBone Black has the same hardware as BCM1, and gives me some confidence that my results are at least somewhat correct.

Posted by Tomaž | Categories: Digital | Comments »

z80dasm 1.1.5

06.08.2017 12:26

This is becoming a summer of retro computing blog posts, isn't it? In any case, today I'm pleased to announce the release of z80dasm 1.1.5, the latest version of my disassembler for the Z80 CPU machine code.

Ast Moore recently noticed that z80dasm doesn't recognize several well known undocumented instructions. When I made z80dasm on the base of Jan Panteltje's dz80 several years ago my goal was to make a disassembler that would correctly produce an assembly listing for Galaksija's ROM. While I did add support for the sli instruction back then, it seems that Galaksija didn't use any of the other undocumented instructions.

z80dasm 1.1.4 did correctly include unknown instructions in the disassembly as raw hex values with defb directives, however it guessed the length of some of them wrong, which desynced the instruction decoder and produced garbage output. The output would still assemble back into the same binary, but the point of a disassembler is to produce human-readable output, so that was not very useful.

Fixing this problem was a bit more involved than I expected, but not for the usual reasons. One of the guidelines I had with z80dasm was to keep z80dasm and z80asm a matched pair. Being able to reproduce back the original binary from disassembled source is very useful when hacking on old software as well as in testing z80dasm. Unfortunately, it turned out that z80asm is quite bad at supporting these undocumented instructions as well. For instance, inc and dec with ixl and ixh register operands are not recognized at all. Some other instructions, like add with these undocumented operands produce wrong opcodes.

I guess this is not surprising. In contrast to the official instruction set there is no authoritative documentation for these instructions, so even the names differ in different sources. For example, both sli a and sll a mnemonics are commonly used for the cb 37 opcode.

I tried to fix some of the problems with z80asm I found, but it turned out to be quite time consuming. Both z80asm and z80dasm are written in, by today's standards, quite an archaic C style, with lots of pointer arithmetic and packing various unrelated things into a single int variable to save space. While I'm still fairly familiar with z80dasm code, the modifications I did to z80asm took a several sheets of paper to figure out.

$ hd
00000000  ed 70 dd 2c dd 23 23 3d  ed 71 dd 09              |.p.,.##=.q..|
$ z80dasm example.bin
; z80dasm 1.1.5
; command line: z80dasm example.bin

	org	00100h

	defb 0edh,070h	;in f,(c)
	defb 0ddh,02ch	;inc ixl
	inc ix
	inc hl	
	dec a	
	defb 0edh,071h	;out (c),0
	add ix,bc

In the end, I gave up and solved the problem of z80asm compatibility by leaving z80dasm to decode undocumented instructions as defb directives. However, the instruction lengths should now be decoded correctly and also the mnemonic is included in a comment for better readability. There is now also a new --undoc option in 1.1.5. If it's specified on the command-line, z80dasm will place all instructions directly into the disassembly.

As before, you can get the source code for z80dasm in a release tarball or from the git repository. See the README file for install instructions and the included man page for explanations of all command-line options. z80dasm is also included in Debian, however 1.1.5 has not been uploaded yet.

Posted by Tomaž | Categories: Code | Comments »

The Galaksija character generator patch

05.07.2017 19:55

In my first overview of Mr Ivetić' Galaksija I mentioned a curious bundle of components hidden inside a yellowing cocoon of Sellotape. It was obviously not a part of the original kit and I speculated that it was likely a workaround for some timing issue connected with the character generator. In the late 1980s several articles were published in Računari and Moj Mikro magazines that attempted to help Galaksija owners fix various hardware problems. Unfortunately I couldn't find any suggested fixes that would match what I saw, so I decided to investigate this particular hardware patch a bit further.

Galaksija circuit board from Mr. Ivetić.

This is another post in the series about the possible restoration of an original Galaksija computer that I took custody of recently. Galaksija is a small home microcomputer from former Yugoslavia that was built around the Z80 microprocessor. The designs were openly published in a magazine in 1984 with the intention that readers would build their own computers from scratch. It is similar to the Sinclair ZX80 in that it uses the CPU to generate the video signal and is constructed solely from general-purpose logic chips. It is generally considered the most successful of several domestic alternatives to computers that were illegally imported from the west.

Components that we hidden under the tape.

After carefully unwrapping layers of disgusting, decaying sticky tape I found a 74LS10 triple 3-input NAND chip from National Semiconductors, a resistor and two capacitors. The circuit is connected to the rest of the computer with only four wires: a logic input, a logic output, +5V supply and ground. The green 150 nF capacitor on top of the chip is only used for decoupling the power supply. First 3-input NAND is wired as a 2-input NAND, second NAND is wired as a NOT gate and the third is left unconnected. Together they form the following functionally equivalent logic circuit:

Schematic of the monostable multivibrator circuit.

This circuit acts as a monostable multivibrator. It will take an impulse of an arbitrary length on its input and always output an impulse of a fixed length that is defined by the time constant of the RC circuit.

When the input goes from high to low, the transition is immediately propagated over the NAND gate, the capacitor and NOT gate to the other NAND input. This latches the output low regardless of any later input changes. Over time, the resistor discharges the capacitor enough that the NOT gate input falls below the logic threshold and the output goes back high. This also unlatches the circuit, allowing another input impulse to trigger it again.

The theoretical output impulse length should be around 80 ns based on the capacitor and resistor values shown above.

Monostable multivibrator demonstration, short impulse.

Monostable multivibrator demonstration, long impulse.

I carefully unsoldered the circuit from Galaksija and connected it to a signal generator using the original lengths of wire. On the screenshots above, the yellow trace is the input and the blue trace is the output. As you can see, the circuit is still working. The output impulse length correctly stays the same regardless of the input impulse length. The circuit has a propagation delay of around 32 ns and the measured output impulse length is around 60 ns. The digital signal is distorted due to ground bounce and other effects of the wires that are quite long for signals this fast.

Location of the monostable on the full schematic.

The monostable is connected in front of the shift/load input to the 74LS166 shift register that generates the video signal. See full schematic here.

Normally the shift register shifts out individual bits on its serial output as the electron beam scans the TV screen. However, once per every 8 pixels it must load new data. To do this, the CPU reads out 8 new pixels from the character ROM. During this time, the shift/load signal must go low for exactly one transition of the 6.144 MHz pixel clock to load the register.

Timing diagram for the CPU's M1 cycle with the "M1" detect signals added.

Loading the shift register in Galaksija is quite a tricky operation as several signals must be accurately synchronized. The situation is made even more complex by the original Galaksija design. To avoid using an extra chip, the circuit does not fully decode the required CPU bus states with combinatorial logic. Instead, it generates the shift/load impulse dynamically. A 74LS74 D flip-flop is cleverly wired to the CPU bus, as shown on the timing diagram above, to create the load impulse.

Normally digital circuits are designed to work even with ideal components with zero propagation time. However, this circuit depends on the fact that the pixel data will be loaded into the shift register before the CPU settles after the last clock of the M1 state. It's one of the two parts of Galaksija's circuit where signals race each other like this.

For a more in-depth explanation of the character generator, see my old blog post about the CMOS redesign and sections 3.1.5 and 4.1.2 in my diploma thesis (in Slovene - English machine translation).

Timing detail for the shift/load signal and the pixel clock.

So, why was the monostable circuit added to this Galaksija? The rough timing diagram above shows the shift/load signal in relation to the pixel clock. The specification for the SGS Z8400B (the Z80 variant used on this particular board) only gives a maximum of 100 ns for the settling after the low-to-high transition of the CPU clock. Hence, the time the shift/load signal spends low in the original circuit (without the monostable) is anywhere between 0 and 100 ns. If this time is too short, it will miss the low-to-high transition of the pixel clock and the shift register won't load. With the monostable added into the circuit, however, the shift/load will always be low for 60 ns and will always catch the pixel clock.

It was known that the original Galaksija design doesn't work with all Z80-compatible CPUs. As the CPU manufacturers improved their processes, the signal transition times were getting lower and eventually some chips were settling too fast for the unmodified character generator circuit to work correctly. The CPU on this board has a date code from 1986, around 10 years after the first Z80 CPU was introduced and 2 years after Galaksija was first published. It's not surprising that it caused timing problems.

This patch appears to be one way to make the circuit more resilient to the CPU variations. It is not perfect though. If the transition time is too short, the impulse might be too short to trigger the monostable. A better approach is to fully decode the CPU state. This is the solution I chose when designing my CMOS replica. Of course, this comes at a cost of more logic and would not be simple to add to an existing circuit board.

Posted by Tomaž | Categories: Digital | Comments »

HiFiBerry follow up

11.06.2017 20:59

Back in December I was writing about problems with a HiFiBerry audio interface for Raspberry Pi. The audio board was apparently emitting interference on the 2.4 GHz frequency band and made the wireless LAN connection on the Raspberry Pi unreliable. I got in contact with their support and they acknowledged that the oscillators on that version of their hardware had an EMI problem. They promised to get back when they've fixed the issue and indeed in April they offered to replace the old board free of charge or sell me a new one for half the price. I opted for the latter option, since I was curious what changes they made to the design and wanted to compare the boards side-by-side.

HiFiBerry DAC+ HW 2.2

This is the old board, marked HiFiBerry DAC+ HW 2.2. The components marked with X44 and X48 are Fox Electronics Xpresso-series hybrid oscillator modules. Each of these contains an integrated circuit and a quartz crystal resonator. Unfortunately they are unmarked and I didn't bother to measure their frequency. From their designations I'm guessing one provides the clock for the 44100 Hz sampling rate and the other for 48000 Hz. Datasheet for the PCM5122 ADC suggests that the oscillators themselves are in the 10 MHz range and the clocks are then divided down inside the ADC chip.

HiFiBerry DAC+ HW 2.6

This is the new board I got. It's marked HW 2.6. The gold hybrids have been replaced with similar looking components in black plastic packages. Xpresso-series has apparently been discontinued. The new oscillators are marked only with letters BOHXA and after a brief web search I didn't manage to find their manufacturer. The new board also omits the push-button. I'm not sure what its original function was anyway.

Here are the two photographs superimposed to highlight the differences:

Comparison of HiFiBerry DAC+ HW 2.2 and 2.6

Apart from the new oscillator hybrids the most obvious change is the removal of two large copper fills on the top layer of the PCB. These large areas of copper on the top layer are all connected to the 3.3V supply. The bottom layer of the board remains one big ground plane.

Copper fill stub near the oscillators on HW 2.2.

The copper fill near the oscillators looks especially suspicious. It was only connected to the 3.3V supply with a narrow bridge between the pins of P4 on the right. It provided supply voltage to U4 and nothing else further down to the left side. It seems like it could accidentally form a quarter-wave stub antenna. It's approximately 25 mm in length, so the resonance could well be somewhere in the GHz range. This is near enough to the 2.4 GHz band that I think it would be feasible for it transmit some oscillator harmonics out from the board.

It would be interesting to see if this stub was indeed causing the problems. It should be easy to drill a hole through and decouple the left end of it with a SMD capacitor to the ground plane on the bottom layer. I could then repeat the near-field measurements I did last year to confirm. I'm not sure if I will bother though. The new board does indeed fix the problem with the Raspberry Pi built-in Wi-Fi radio and I currently don't have any particular use for another audio board.

Posted by Tomaž | Categories: Analog | Comments »

Repairing what wasn't broken

04.06.2017 21:10

Last time when I was tinkering with the insides of my portable CRT TV (UTV 6007) I happened to notice one more odd thing. One of the smaller through-hole resistors near the high-voltage transformer looked charred from heat. Ever since this TV was new it had a little bit of that characteristic smell of overheated electronics. However it worked fine, so I didn't worry too much about it and it's not unusual for cheap plastic to smell a bit when heated. But this here looked serious enough to look into it even though from the outside there were still no apparent problems.

Blackened R75 near the high-voltage transformer.

The size of the resistor suggested a 1/8 W rating. The body was too blackened to read out the colors. The position is marked with R75 and the silkscreen print underneath helpfully says it should be 1 kΩ. However I've seen that other resistors on this board sometimes don't match the values printed for their positions. Out of the circuit, the resistor measured around 900 Ω, which seemed consistent with a slightly damaged 1 kΩ. Just to be sure, I traced the circuit around it to see what its function was.

The following is the relevant part of the circuit on the main board around the HVT. Only the low-voltage secondary winding providing a few 100 V for the first anode is shown here.

Circuit around the HVT in UTV 6007.

I also traced the small circular board that sits directly on top of the electron gun pins and is connected to the main board with a (very flimsy looking) 4-wire flat cable.

Small circuitboard on top of the electron gun.

I didn't find the exact pin-out for this tube, so take the pin markings with a grain of salt. However this pin-out seems consistent with how the typical cathode ray tube is connected. For reference I used the one shown in the KA2915 datasheet and a few old TV schematics my father found in his library.

The small circuit on top of CRT pins.

The cathode K has a positive bias relative to the ground. The bias can be adjusted with the Brightness knob. The first grid G1 is grounded and is hence negative relative to the cathode. First anode A1 is on a higher positive bias relative to the ground and is hence positive relative to the cathode. The second grid G2 either isn't present in this tube or is grounded as well. There is no apparent focus adjustment. The video signal is connected to the cathode. It varies cathode potential relative to the first grid and so controls the intensity of the electron beam and thus the brightness of the spot on the phosphor.

The capacitor and diode arrangement between A1, G1 and ground is interesting. Something similar is present on all CRT circuits I've seen (see D3 here for example, from this project). Its purpose might be to put a high negative bias on G1 to stop the electron beam when the device is turned off and A1 goes low. I know that a lingering electron beam in old TV sets sometimes burned out a spot in the screen if the beam didn't shut down before the deflection. This may be there to prevent that.

In any case, the R75 is in circuit that provides the anode voltage. Only the small anode current should flow through it, and the charging current for the 2.2 μF capacitor for a short time after the TV is turned on. It's not apparent what caused it to heat up so much. The capacitor seems fine, so perhaps something arced over at one point or the TV was turned on and off several times in short succession.

Replacement R75 resistor in UTV 6007.

Since the circuit seemed to be consistent with the suggested 1 kΩ value, I replaced the resistor with a new one. I used a standard 1/4 W carbon resistor I had at hand and left it on longer leads for better cooling if something similar happened again. As expected, the TV runs just as well with the new resistor in place as it did with the old burned up one. There's currently no sign of it overheating, but perhaps I'll check again after some time.

I love playing with this old stuff. Analog TV was one of the pinnacles of consumer analog technology and it's fascinating to see how optimized and well thought out it was at the end of its era. This particular specimen is surprisingly repairable for a device that I got new in the store for 20 €. Components are well marked on the silk screen print and most have their values printed out as well (even if those don't always match reality). The only thing more I could wish for is that I could run it with the case opened without a special contraption for holding the CRT.

Posted by Tomaž | Categories: Analog | Comments »

Disabling TV audio squelch circuit

21.05.2017 14:33

I just don't have any luck with Maker Faires it seems. I had everything packed and prepared for the event last week and then spent the weekend in bed with a fever. Sincere appologies to anyone who wanted to see the Galaksija. I'm sure there were more than enough other interesting exhibitions to make the visit worth your time.

Galaksija screenshot

In the weeks leading to the Maker Faire I came across an old problem with the small analog TV (United UTV 6007) that I use with vintage computers. Ever since I first played with Galaksija's audio capabilities I noticed that sound gets very distorted when played through the TV speaker. I never really looked into it. I just assumed that perhaps voltage levels were wrong for line input or the high-frequency components of 1 bit music were interfering with something. Since I had Galaksija already setup on my bench, I decided to investigate this time. It turned out that a clean sine wave from a signal generator also sounded very choppy and distorted. On the other hand, audio from a DVD player sounded perfectly fine. This made me curious and I took the TV apart.

United UTV 6007 TV circuit board.

UTV 6007 is built around the CD5151CP integrated circuit. It's very similar to the camping set TV described in this post about adding a composite video input to it. The post on also has links to a bunch of useful datasheets. UTV 6007 already has a composite video and an audio line input out of the box, which was one of the reasons I originally bought it.

Part of the UTV 6007 circuit board marked "hbb".

I traced the audio path on the board to this curious circuit near the volume knob. I'm not sure what "hbb" stands for, but the circuit has a squelch function. It mutes the speaker when there's no picture displayed. This makes the TV silent when it's not tuned to a channel instead of playing the characteristic white noise. It actually takes a surprising amount of real estate on the small PCB.

Audio amplifier and squelch circuit in UTV 6007

This is the relevant part of the circuit traced out. The squelch takes input from the sync. sep. output on the CD5151CP. This is probably a signal that contains only synchronization impulses separated out from the video. R1, C1, R2 and C2 form an impulse filter. Positive impulses between 150 μs and 5 ms will open Q1. This discharges C3. If no impulses are present, R3 will in about 14 ms charge C3 to the point that Q2 opens. Q2 shorts the audio amplifier input to ground, making the output silent.

Q2 seems somewhat odd, since its collector doesn't have any bias current. So at first glance it appears that it would not be able to ground negative half waves of the audio signal. However, D386 amplifier has a bipolar differential input stage that sources base current. Apparently that provides sufficient collector current for Q2. In fact, the audio circuit (without the squelch) is identical to one of the D386 reference designs.

These timings suggest that the circuit detects vertical video synchronization. Unfortunately, the compact design of the TV makes it non-trivial to power it up while the circuit board is accessible. I didn't want to bother with any special setup, so I don't have any actual measurements. Sound distortion suggested that Galaksija's video signal was making this circuit erroneously trigger for a short time once every frame, which made for a choppy sound. Galaksija's video is in fact somewhat out-of-spec (for instance, it's progressive scan instead of interlaced).

Since I was not sure which timing exactly was the culprit, I opted to simply disable the circuit. I guess in the age of digital TV some untuned television noise just adds to the retro style of the whole setup. To disable the squelch I removed the R3 resistor. Without it, Q2 can't get any base current and hence always remains closed. A quick test confirmed that with that modification in place Galaksija sounds as it should on the TV speakers.

Posted by Tomaž | Categories: Analog | Comments »

Closer look at the original Galaksija

09.05.2017 20:34

A few weeks ago I met with Mr. Vojislav Ivetić in Maribor. He entrusted me with an old Galaksija computer circuit board. Several years ago he obtained it from Janez Stergar at the Faculty of Electrical Engineering and Computer Science, University of Maribor. He told me that the historical computer was in an unknown condition, very likely not working, and was interested in restoring it back to usable state. This post is the result of my visual inspection of the circuit to estimate the extent of the restoration that would be necessary.

Galaksija is a small home microcomputer that was designed in Belgrade by Voja Antonić around the Z80 microprocessor. The designs were openly published in a magazine in 1984 with the intention that readers would build their own computers from scratch. Do-it-yourself kits could be ordered by mail and eventually also complete, factory made computers. Galaksija was often easier to obtain than similar foreign computers due to heavy import restrictions in the former Yugoslavia. It is generally considered the most successful of several attempts at a domestic home microcomputer.

At the first glance, Mr. Ivetić' Galaksija appears to be built from one of the kits. It has a white mechanical keyboard and a factory made single-layer printed circuit board with the green solder mask and white silk screen print on top. The integrated circuits and other components were most likely gathered from various sources and soldered manually (not all are in sockets). All original Galaksija computers I've seen looked very similar to this. Some had black keyboards, but they all shared the same PCB design.

Galaksija circuit board from Mr. Ivetić.

The circuit board has the basic Galaksija configuration. Only the 4 kB ROM A is installed. This ROM contains the BASIC interpreter, video driver and the rest of Galaksija's minimalistic operating system (here marked Master EPROM). The ROM B socket is empty.

The quartz windows on UV-erasable EPROMs are only covered with a white paper sticker. If the board was stored for a long time exposed to light, it might be that the EPROMs have lost their charge due to ambient UV light and will have to reprogrammed.

Iskra EMS6116 static RAM on a Galaksija computer.

There is a single 2 kB static RAM chip installed. Interestingly, the logo suggests this is an Iskra EMS6116, a domestic integrated circuit. I was not aware that RAM was produced by Iskra. In fact, the original magazine article that gives instructions for Galaksija builders suggests ordering RAM and other chips by mail from abroad (with suggested distributors that will ship to Yugoslavia and tips on getting the shipments through customs). Sockets for additional two 2 kB RAM chips are empty.

All other chips are foreign made. The Z80 CPU and EPROMs are all from SGS (former Italian semiconductor company, later merged into STMicroelectronics). These also have the most recent date codes among the identifiable components on the board: first week of 1986. Original Galaksija design was published in January 1984, so this board was built at least 2 years later. Other logic chips I could identify are from TI and SGS. The oldest chip is the 74LS38 from 1979.

Improvised circuit on shift/load line.

There is a small bundle of components wrapped in sticky tape hanging off the PCB on four wires. It looks like it contains an IC in a DIP package and some capacitors. The circuit sits in front of the shift/load input to the 74LS166 shift register that generates the video signal. It's also connected to the ground and the power supply. Since the extra circuit is not connected to any other digital lines, I'm guessing it is most likely a delay to fix some timing problem.

Location of the improvised circuit on the schematic.

Normally, the shift/load input is driven directly by a circuit that detects when the CPU is in the M1 (opcode fetch) cycle. See full schematic here. I know from my previous research that M1 detection circuit on the original Galaksija is unreliable, since it depends on signal timings that are not guaranteed by the design of the Z80 CPU. It's possible that this was an attempt to work around this issue.

Two potentiometers for setting sync pulse lengths.

There is no RF modulator installed. The circuit has been modified so that composite video signal is directly present on a pair of improvised screw terminals. I'm guessing this Galaksija was used with a monitor or a TV with composite input. Those were quite rare at the time, but it was not uncommon for people to modify their TV sets to add a composite input.

Two potentiometers are wired in series with R12 and R13. They have been glued down, but are now hanging loose on wires. Potentiometers seem to have been installed to adjust horizontal and vertical sync pulse widths. They are not part of the original design. They affect the time constants of 74LS123 monostable multivibrators that generate synchronization impulses in the composite video signal.

Missing space key on the Galaksija.

The space keycap is missing, but the key itself is present. I guess even if a suitable replacement can't be found, one could be drawn in a CAD program and 3D-printed.

Example of a lifted track on Galaksija PCB.

A look at the bottom side reveals that the condition of the copper laminate is quite bad. Many tracks and annular rings have broken or lifted off the substrate. The PCB shows signs of old repairs to some of the damaged tracks, so at least part of this damage is not due to age. Maybe soldering was done at a too high temperature or the quality of the laminate was not particularly good. This Galaksija shows no signs that it was ever mounted in a case, so the damage might also be due to mechanical stress. Many tracks around EPROM sockets are broken, suggesting that the stress of inserting and removing the EPROMs was at least partially responsible.

Ruined annular rings under a transistor on Galaksija.

I've counted around 40 points on the PCB that would need repair. Some are hairline breaks in traces that seem easy to reliably bridge with solder. Other parts would require replacements of copper areas using foil and epoxy glue to bring them back to original condition. Fortunately this PCB has relatively large features compared to modern SMD boards. However, this extent of repair still seems like a lot of delicate work. I'm also not certain that other areas of the laminate that look fine now would not start failing during repair.

If all else fails, another possibility would be to have a whole replacement PCB made and re-solder the keyboard and other original components. This would obviously decrease the historical authenticity. While the scans of original PCB masks are available on the web, those are not precise enough to make a usable replacement board. They would need to be redrawn before they can be sent to a fab.

In conclusion, all basic components are there and look fairly well preserved. At the moment I have no reason to believe that any chips are bad. However the PCB should be repaired before attempting to power up this board. The extent of damage and the amount of fine work with the copper foil would make this repair quite time consuming. It would be nice to somehow check the state of the most critical chips before proceeding on that path. Fixing the PCB would be a big waste of time if the CPU or RAM chip will eventually turn out to be bad. On the other hand, replacements for 74LSxx series logic still seem to be relatively easy to come by.

Posted by Tomaž | Categories: Digital | Comments »