## 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.

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.

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).

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.

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 | 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..| 0000000c$ 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 | 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.

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.

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:

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.

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.

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.

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).

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 | 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.

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.

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:

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.

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 | 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.

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.

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.

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 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.

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 | 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.

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.

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 Bidouille.org 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.

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.

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 | 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.

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.

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.

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.

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.

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.

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.

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.

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 | Categories: Digital | Comments »

## Galaksija retrospective and some news

29.04.2017 8:59

This year my Galaksija replica is a decade old. Back in January 2007 I first brought to life enough of the circuit in my father's workshop to display some faint, mirrored characters on the TV screen. It has been the culmination of 6 intensive months of reverse engineering and documenting the original design, ironing out the odd corners and designing a compatible computer around it. In September that year I've successfully defended my diploma thesis on Galaksija at the Faculty of Electrical Engineering.

In the following five years, I've mostly focused on the software. With the help of the working replica, I've been able to document a large portion of its ROM. I found convincing clues that Galaksija's BASIC was derived from Tandy TRS-80, not Microsoft BASIC as it is commonly believed. I explored old software and wrote some new demos. Along the way I confirmed the myth that high-resolution graphics were possible on that hardware. Finally, I've summed up most of my work in the Ultimate Galaksija talk in front of fellow hackers at the 29C3.

I can't believe it's been ten years already. It feels like I've written all those articles two life times ago. In the mean time, I've been employed in vastly different fields and I guess I shouldn't be surprised that a lot has faded from my memory. The Hamburg talk was certainly the crowning moment and after the pretty exhausting preparations for it, I hardly returned to anything Galaksija-related. My replica still works, but while I once knew by heart minute timing details of every signal, the circuit diagram now only stirs up general ideas behind its operation. Still, the &2BA8 register address for horizontal sync adjustment immediately popped up from muscle memory upon touching the keyboard.

Anyway, I promised some news. There will be a Mini Maker Faire in Ljubljana in two weeks. I've always been intrigued by reports from Maker Faires and on a couple of occasions I've been very close to going to the one in Brighton. However, each time something else intervened. Hence I immediately jumped to the opportunity to participate in the first Maker Faire in our country. Also, a few people encouraged me to put my Galaksija on display once again. So, if you would like to play some Inspektor Spiridon on real hardware, or puzzle over why your BASIC program results in the WHAT? response, find my table at the Poligon Creative Centre on 13 May.

The other news is that I was recently contacted by Mr. Vojislav Ivetić. As a fan of old computers, he acquired an old, original Galaksija from one of his colleagues and was interested in the possibility of renovating it and bringing it back to life. The exact state of the board is unknown, but supposedly it is not in a working condition. From the first glance it appears to be a mostly complete article, built from one of the original kits, albeit with some crude home brew modifications. Inspired by the recent series on Xerox Alto restoration by Ken Shirriff, I offered to have a look and at least do a quick checkup and a list of things that would need to be done to get it working.

I'll post my first findings from a more detailed look at this Galaksija in another blog post here in the near future. I would love to restore this computer back to its former glory and document the process. But that really depends on how much time I'll be able to dedicate to it and how other things in my life turn out in the following months.

Posted by | Categories: Life | Comments »

## IPv6 problems on TP-Link Archer C20

26.04.2017 12:44

Recently I replaced an old 2.4 GHz-only Linksys WRT54GL wireless router with a shiny new, dual band TP-Link Archer C20 (hardware version V1). Unfortunately, the new router brought some unusual problems. It turns out some devices are now unable to get a global IPv6 address when connected over Wi-Fi. For example, my Android 5.1 smartphone and my work laptop with Debian Jessie and Network Manager don't get IPv6 connectivity. They worked just fine when connected through the old router. At the same time, a different phone with Android 6.0 seems to have no problems with the new Archer C20 router.

First a brief note on the network setup: Archer C20 is used here as a wireless access point only. Some other host on the network acts as a gateway to the Internet. That host also provides a DHCP service for IPv4 and runs the route advertisement daemon (radvd) for IPv6 SLAAC. The setup has been quite well tested and works flawlessly on the wired Ethernet. The old WRT54GL has also been used in this way, which is why IPv6 connectivity on the Wi-Fi worked fine even though the old router's firmware had no explicit IPv6 support.

As the TP-Link FAQ entry explains, the WAN port on the C20 is unused, the network is connected to one of the LAN ports and the DHCP server on the C20 is disabled. IPv6 status tab in the configuration interface shows the following:

The IPv6 problem is somewhat frustrating to diagnose, since it only appears some time after the router has been restarted. For instance, I've usually seen that IPv6 stops working the next day after a reboot. Similarly, changing some unrelated settings, like the wireless SSID, also appears to temporarily fix the issue, only for it to reappear after a while.

Searching the web I can find some discussions about similar problems with TP-Link routers, with no clear conclusion. The firmware changelog does say in a vague way that the latest version fixes an IPv6 problem. However, I've tried the V1_160427 and V1_151120 firmwares and they both behave in the same (broken) way.

After much head scratching I found out that the base cause why my laptop does not get an IPv6 address over Wi-Fi is IPv6 duplicate address detection. This is apparent from the dadfailed flag on the link local address:

$ip addr show dev wlan0 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether a0:88:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet 192.168.xx.xx/24 brd 192.168.xx.255 scope global dynamic wlan0 valid_lft 484sec preferred_lft 484sec inet6 fe80::a288:xxxx:xxxx:xxxx/64 scope link tentative dadfailed valid_lft forever preferred_lft forever  Also, when you know what to look for, this error appears in the logs: $ dmesg|grep duplicate
IPv6: wlan0: IPv6 duplicate address fe80::a288:xxxx:xxxx:xxxx detected!


So it seems that my laptop thinks that there is another device on the network with the same link-local (and hence Ethernet MAC) address. This is of course not true. In fact, if I disable the duplicate address detection, IPv6 starts working properly:

# sysctl net.ipv6.conf.wlan0.accept_dad=0


Investigating things a bit further, Wireshark shows the following curious packet capture immediately after the laptop connects to the wireless network:

This appears to be the progress of a normal attempt at a IPv6 autoconfiguration from the laptop's side. The laptop (with the MAC address a0:88:...) sends some packets to a IPv6 multicast address (33:33:...). However, all these packets seem to be immediately reflected back to the laptop by Archer C20. The incoming packets highlighted in yellow are byte-by-byte identical to the preceding outgoing packets, with only the destination address in the Ethernet header changed from the multicast to the laptop's MAC address. These incoming packets are not present when the laptop is connected to one of the wired LAN ports, or when using the old wireless router.

These reflected packets trigger the duplicate address detection in the laptop's network stack and the autoconfiguration is interrupted. It seems that at some point in the Archer C20 uptime, IPv6 multicast groups stop working correctly. In fact I don't understand why it even tries to do anything special with those. WRT54GL had no concept of IPv6 and it worked fine. I've experimented with other options that looked related to multicast (like IGMP settings), but with no success. So unfortunately at the moment I don't have a good network-side solution. Any suggestions would be most welcome. Changing the stock firmware might work, but support in OpenWRT for this hardware currently seems experimental at best.

The device-side work-around is to disable DAD like I show above, but this is somewhat ugly. There might be a way to disable it on a per-network basis with Network Manager (see dad-timeout), but I have not tried this yet. It is also still not clear why some devices appear to work. It might be that Android simply disabled duplicate address detection in 6.0.

Update: This Mikrotik manual suggests that such repeated multicast packets are expected on wireless access points that are aware of multicast addresses. So it still might be that the problem is somewhere on the client side. I did find out that enabling Client Isolation on the Archer C20 fixes this problem (with the obvious side effect that wireless clients can no longer talk to each other). dad-timeout NetworkManager option is not supported on Debian Jessie.

Update: Client Isolation doesn't actually help. After a few days I'm again getting the dadfailed flag.

Posted by | Categories: Code | Comments »

## Phase noise in microcontroller ADCs

17.04.2017 19:44

In the past few years I designed a series of small VHF/UHF receivers. They are all based on TV tuner chips from NXP semiconductors and the STM32 series of Cortex-M3 microcontrollers. The receivers were originally intended for experiments with TV whitespaces, such as detecting the presence of wireless microphones. However, European projects come and go, and so recently my work at the Institute has shifted towards ultra-narrowband technology. I keep using my old hardware though. Partly because it is convenient and partly because it's interesting to find where its limitations are.

With ultra-narrowband, phase noise is often the defining characteristic of a system. Phase noise of a receiver is a measure of the short-term stability of its frequency reference. One of its effects is blooming of narrowband signals in the frequency domain. A common way to specify phase noise is in decibels relative to the carrier (dBc), at 1 Hz equivalent bandwidth at a certain offset from the carrier. This slide deck from Agilent nicely explains the concept.

Not surprisingly, my design has quite a lot of phase noise. This was not a concern when receiving wide band FM microphone signals. However, it turns out that it's not the RF part that is the culprit. Most of the phase noise in the system comes from the analog-to-digital converter in the ARM microcontroller that I use to sample the baseband signal. I investigated this using the same setup I used for my ADC undersampling measurement - in the following measurements, no RF circuits were involved.

This is how the spectrum of a 500 kHz CW signal looks like after being sampled at 2 Msample/s (using the interleaved dual mode of the ADC). The spectrum is calculated using FFT from 2048 samples. Ideally, there should only be a narrow spike representing one frequency component, however the phase noise causes it to smear into a broad peak:

From this, I drew the phase noise plot. This shows half of the dual sideband power, calculated at 1 Hz equivalent bandwidth and relative to the total signal power:

At 10 kHz offset, this gives:

\mathcal{L}_{ADC}(10\mathrm{kHz}) = -77 \mathrm{dBc @ 1 Hz}

On the other hand, typical phase noise from the datasheet of the tuner chip I'm using is:

\mathcal{L}_{tuner}(10\mathrm{kHz}) = -93 \mathrm{dBc @ 1 Hz}

For comparison, the National Instruments USRP N210, another device I use daily, is only 3 dB better at 10 kHz (according to this knowledge base page):

\mathcal{L}_{USRP}(10\mathrm{kHz}) = -80 \mathrm{dBc @ 1 Hz}

Proper lab equipment of course is significantly better. The Rohde & Schwarz SMBV signal generator I used in the measurement only has -148 dBc of phase noise specified at 20 kHz offset.

What causes this phase noise? The ADC in the microcontroller is driven by the system clock. The accuracy of this clock determines the accuracy of the signal sampling and in turn the phase noise in the digital signal on the output of the ADC. In my case, the system clock is derived from the high speed internal (HSI) oscillator using the integrated PLL. The datasheet doesn't say anything about the oscillator, but it does say that the PLL cycle-to-cycle jitter is at most 300 ps.

Using a Monte Carlo simulation, I simulated the phase noise of a system where signal sampling has a random ±150 ps jitter with a uniform distribution. The results nicely fit the measurement. The shaded area below shows the range of 𝓛(f) observed in 5000 runs:

So it seems that the PLL is responsible for most of the phase noise. Unfortunately, it appears that I can't avoid using it. There is no way to run the integrated ADC from a separate external clock. I could run the whole system from a low-jitter high-speed external (HSE) clock without the PLL, however HSE is limited to 25 MHz. This is quite low compared to my current system clock of 56 MHz and would only be feasible for significantly lower sample rates (which would require different analog anti-aliasing filters). External ADC triggering also wouldn't help here since even with an external trigger, the sample-and-hold circuit appears to be still driven by the ADC clock.

For some further reading on the topic, I recommend Effect of Clock Jitter on High Speed ADCs design note from Linear, which talks about phase noise from the perspective of serious ADCs, and Phase Locked Loop section in STMicroelectronics AN2352.

Posted by | Categories: Analog | Comments »