Avian’s Blog

First, congratulations to the Cyberpipe computer museum team for the successful repair of the Macintosh SE. Sorry guys, this was just too good not to be posted ;)

Martin writes (this is a rough translation of the relevant part of the text): The cause of the malfunction turned out to be a blown 3.9μF bipolar electrolytic capacitor in the horizontal deflection circuit. The problem however was that you can't buy a 3.9μF capacitor, because it's not a popular value and shops don't have it in stock. So we had to replace it with a substitute - three capacitors connected in series. After the fix the computer worked, but the picture was stretched horizontally. Replacement capacitors held for a couple of minutes, then one of them blew up again.

You can't say for sure, what caused the replacement to blow, however you can say why the picture was stretched from the photo of the replacement capacitor circuit below (the original capacitor is on the left). Bonus points if you can prove it mathematically:

Some time ago gEDA moved their source repositories from CVS to Git. I've heard a lot of nice things about Git but so far I stayed away from it since its philosophy (and terminology - for example meaning of words like commits and revisions) is different enough from CVS and SVN that I never quite understood what certain commands did. Yesterday I finally took some time and read through most of its manual.

I must say that after reading the documentation things do begin to make sense. So I checked out the latest gEDA sources and experimented with Git a bit. Since I wanted to try out how convenient it is to make modifications to your local branch and then submit patches back upstream I started modifying things and in the end I (mostly) fixed one annoyance with gschem.

The problem is that when you have the view zoomed out the schematic quickly gets unreadable. I tried to solve this problem a while ago by porting gschem to Cairo, which provided nice anti-aliased lines and fonts. However that had problems of its own and Cairo support still hasn't been incorporated into gschem source.

Now I took a much simpler approach. It turned out that mayor factor contributing to unreadability is the grid. When zoomed out the features of the schematic get lost in closely spaced grid points. However making grid darker produced the problem that when zoomed in the points were hard to see. So I did a simple modification (made less simple by the awkward handling of colors in the code) that made grid points stand out less from the background when the view is zoomed out.

As you can see from the pictures below, the difference on a zoomed-out view is quite noticeable. It definitely makes gschem usable for editing on one zoom level more than before.

Left patched gschem, right original gschem.

Left patched gschem, right original gschem with grid color changed so that it matches grid color of patched gschem when zoomed out.

You can download the patch from SourceForge.

My grandfather gave me two old calculators a while ago. Now I've finally found some time to have a close look at them.

First one is TRS 529, made by Tvornica računskih strojeva Zagreb (I wonder if the same acronym as Tandy/RadioShack is a coincidence). As you can see from the photo it's a scientific calculator with basic trigonometric functions and memory for one variable.

A look inside reveals a tiny vacuum fluorescent display powered by an early DC-DC converter made by Ematron Inc., Taiwan. This hybrid circuit converts +6V from four AA batteries to -25V which is then used as anode voltage for the display and also for powering the processor. CPU is Rockwell A4001CC inside a plastic staggered dual in-line package. 7801 says that it's been manufactured in the first week of 1978.

Sadly it doesn't work anymore. As far as I can see the power supply works correctly, however the CPU appears to be completely dead. When I connected it to an oscilloscope I could see no attempts at keyboard scanning or display multiplex.

The other calculator is Hewlett Packard 21. It's the first RPN calculator I've seen. I remember it as the calculator that had the "Enter" key like the big computers and that only my grandfather knew how to use.

From the technical standpoint there is little I could add to information that is already available on the internet. This one did show some signs of life when powered up. The little LED display shows "0 0", however it appears there is something wrong with the keyboard, since only the top row of keys produces any response.

I didn't try to open it to see what's wrong since at first I didn't see any obvious way of taking it apart. Now that I know that you have peel away the front two rubber legs I'll probably look into it.

My work at Zemanta in the last two weeks included optimizing performance of some core software components. This mostly means moving stuff from Python to C++ which also means that I've been exposed to more C++ in the last week than in five years at the Faculty (where I tried to stay away from it as much as possible except for a few odd KDE hacks back when I still used it).

Anyway, IO streams always seemed awkward to me. But that's usually the case when you start using a language you're not fluent in. So I tried to go on with them and waited for the enlightenment when I would say "Oh! I don't know how I ever lived with the plain old stdio.h". Well, today I finally got it, but it was the other way around. I'm moments from making it a policy that all my C++ code will strictly use the plain old stdio.h for console and file I/O.

Why? Well, consider the following example. I want to make a string that will hold a hex representation of a 32 bit integer. It's going to be read by another program so the format must be pretty strict. Using the C++ way, you would do that like so:

stringstream g;
g << "0x" << hex << setw(8) << setfill('0') << i << endl;

It's long and relatively unreadable. Add a couple more manipulators and you could easily have a statement that prints 10 characters span multiple lines. Compare this with C equivalent:

printf("0x%08x\n", i);

Ok, maybe I'm biased regarding readability. However compare what these two programs print out:

# C++ version
0x000b,eaf
# C version
0x0000beaf

Why is there a comma in the middle? I just spent an hour debugging this earlier today. The cause? Well the comma is a thousands separator from the current locale which the stream library helpfully inserts in your string. Yes, a thousands separator that actually separates four thousand and ninety sixths. A solution? Adding another string manipulator that modifies the locale (a manipulator that just turns off the thousands separator doesn't actually exist). Just beautiful.

The fun doesn't stop there. I spent another hour today debugging some piece of code that opens a file. In the end it turned out that the open call was failing because I tried to open a file that was a couple of megabytes over the 2 GB limit and the program wasn't compiled with support for large files. I don't mind that, it was my mistake. However I do mind that it took me as long as it did to find the cause.

The fstream objects just silently fail when there is something wrong. The damn things don't even throw exceptions by default. Isn't that the C++ way of handling errors? Instead they set some hidden state you have to specially check and even then you can only get the message that something failed, not what specifically went wrong. Add to that the horrible mess that is STL documentation and you see why I only found out what was causing the program to crash when I dumped fstreams and rewrote the whole thing to use stdio.h functions.

So, in conclusion, C++ itself is pretty nice as a language (and blindingly fast compared to Python, which has the speed of a snail nailed to the table) but the standard infrastructure that comes with it causes more problems than it solves. Instead of using it and waiting to find out the bright sides of it, I'll use the old way I know from C and wait until someone else shares his enlightenment with me.

Some time ago I was writing about two big wooden boxes full of vacuum tubes. It turned out they were old radios that were brought by my dad's colleague to be repaired.

The first one was RIZ 634 UKV, the last radio made by Radioindustrija Zagreb that used tubes (designed in 1963 according to one source).

This one was pretty easy to fix. The schematic is actually available on the internet, but we didn't need it much. The radio required new electrolytic capacitors for the rectifier and some tuning of the RF circuitry (since someone obviously tried to fix the radio before us by turning all those little trimmer capacitors and coils because all seals on them were broken).

My dad wanted to preserve the authentic look of the circuitry, so he hid modern capacitors in the emptied case of the original capacitor.

The other radio is more of a mystery. It's obviously a lot older than RIZ 436. It only has a long and middle wave receiver and my dad puts its design around 1935 - 1940. A sticker on the back says "Philips AL 394 HU" while all text in the front is in Spanish, so I'm curious how it ended here. I couldn't find any info about it on the internet, so if you know anything about it, I would happy if you dropped me a mail.

Most of the passive components (capacitors and resistors) were heavily damaged because of age and we decided that it would ruin the historical value if we attempted to replace them with modern equivalents. So we basically just cleaned up the interior and took a few pictures.

Here's a nice example of simple instructions that anyone could follow. This is a picture of the back plate with pictograms showing what to plug into various connectors on that side. It seems that you should connect one wire to the water pipe (ground) and another to your clothes line (antenna).

If you're wondering, two connections on the right are for the gramophone and external speakers.

I've made a simple day-of-week display today. I hope it will help my grandmother and grandfather remember which day it is so they can take the correct medications.

It seems that complexity of scheduling various pills rises exponentially with age and I was surprised that I could find no electronic aides on the market that would help old people with that. It's simple to write the schedule on paper but you still need some kind of automatic calendar that doesn't depend on the user to advance the "today" indicator. I couldn't even find a clock that would display the day of the week in Slovene (not to mention in big readable letters).

So I made my own. Time was important so I made this as simple as possible (it took me a day and a half to put everything together): I used an old stopwatch and connected a simple detector circuit to it instead of the buzzer. The detector gives a clock impulse to a 7-state Johnson counter each time the alarm would sound which in turn advances the display for one day.

I power the clock from a 1.5V battery which removes the need for 12V to 1.5V DC-DC conversion and adds the benefit that the clock continues to run even if someone unplugs the device.

Looking at it now it reminds me of those scenes in Hollywood movies where they argue if someone should cut the red or the blue wire.

A quote from a highly moderated comment on Slashdot:

Thermionic valves have vastly superior tolerance to electromagnetic radiation, acceleration, shocks, and other hostile conditions.

After you drop a transistor and a tube on the floor, guess which one will be perfectly fine and which one will be a useless pile of glass shards?

On the other hand, the linked video is really nice and shows step-by-step construction of vacuum tubes by a French amateur radio operator.

Remember my rant about Mac OS X Leopard? I said how it reminded me of Windows Vista because it's constantly asking you to confirm this or that.

Here's a confirmation dialog I've just had to click through that beats all others I've previously encountered:

And yes, this was an ordinary HTML file, not an application of any sort.

asus_acpi.ko kernel module provides an interface to what look like electronic power switches for different peripheral devices in Asus Eee PC.

For example doing echo "0" > /proc/acpi/asus/camera will cut power to the integrated web camera. If you want to get as much battery life out of Eee as possible it helps to switch off devices that you're not using. However typing commands like above quickly gets boring. So here's a little Perl script that does that in a bit more user-friendly way:

avian@galxpolx:~$ eeepower
Asus Eee PC peripheral power utility. Copyright (c) Tomaz Solc. Under GPL.

  SD/MMC reader   off
   Wireless LAN   on
         Camera   off
avian@galxpolx:~$ eeepower help
USAGE: eeepower [ device ] [ on | off ]

Available devices:
        cardr    SD/MMC reader
         wlan    Wireless LAN
       camera    Camera