Avian’s Blog

Last week when I wrote about the Hewlett Packard 9000 I stumbled upon the High-Density Interconnect handbook. I got intrigued by a caption mentioning "stacked transistors" in relation to the HP FOCUS microprocessor that the 9000 series used. I went and dug a little deeper to see if I could find out what was meant by that phrase.

At that time HP was using the NMOS-III fabrication process, which was the successor to the NMOS-II. This was a 1 μm, two-metal layer process designed specifically for their new 32-bit 500.000 transistor FOCUS microprocessor.

I found a pretty detailed description of the technology in the HP Journal. The August 1983 issue is dedicated to the VLSI process while September 1987 deals with higher-level microprocessor architecture. Both are an interesting read for anyone that is into vintage integrated circuit technology.

For instance, unlike CMOS circuits of today NMOS digital circuits had relatively large output impedance and drew a large quiescent current. First property became apparent when chips where unable to drive long PCB traces. This was especially problematic for the system's 18 MHz clock which had to be distributed throughout the computer. So they made a dedicated clock generator chip with gigantic output transistors (55 mm gate width!) and mounted everything on finistrates - special printed circuit boards with wire bonded dies, very small vias and very high-quality Teflon dielectric - all to decrease trace inductance as much as possible. Finistrates also helped solve the heating problem by having a thick copper core which conducted heat away from the components.

Remember the "self healing" RAM they mention in that advert? That was achieved with special polysilicon fuses which allowed the RAM chip to isolate defective parts by melting a part of the interconnect. Oh, and RAM used a four-transistor dynamic cell, unlike one-transistor commonly used today.

Fascinating stuff. Especially considering this was all published in a journal and not kept as a closely kept company secret.

However I didn't find what I was looking for. There is no mention of transistor stacking. On thing is clear though: NMOS-III process certainly did not have any provisions for vertical stacking of transistors (which is rare even today). So that caption most probably referred to some kind of circuit topology.

Recently I came across this vintage advertisement for a Hewlett Packard 9000 computer at the (virtual) HP Computer Museum:

The ad is quite an interesting read. For instance it mentions that the computer's integrated circuits used NMOS technology, which provided for copious amounts of heat, which in turn required a special PCB.

It's also interesting to compare it with this modern advertisement that happens to be on my table at the moment:

I can't help but think that the HP advertisement tries to help you make an informed decision while the new ad blinds you with bulleted lists full of trademarked names and buzz words. HP says they use a memory controller that can correct 32 bad memory locations, not that they have a SuperSelfHealMemTech™. Also it seems like HP advertised these computers to people that will actually use them (note how they mention finite element analysis, systems of equations, etc.) not some IT management that is only looking for a good deal on gigabytes per monetary unit.

Oh and HP 9000 name was more recently recycled for a series of printers. How sad is that?

Update: Figure 1 in the HDI Handbook I linked above says "HP FOCUS chip ... NMOS III (stacked transistors). What is "stacked transistors" referring to here? I can find no mentions of HP NMOS III process using any kind of vertical transistor stacking like ST-CMOS.

A couple of hours ago I was sitting in front of my desktop computer when I had to step away for a couple of minutes. When I returned, the screensaver had kicked-in and my ViewSonic VG2230wm LCD monitor was in sleep mode. Deep sleep mode it turned out, because I could not wake it up.

After some digging around and fruitless reboots, power cycles and cable reseatings I came to realize that xrandr was simply seeing the DVI-0 connector on my Radeon 4350 as disconnected.

Further, I stumbled upon this report in dmesg:

*ERROR* EDID checksum is invalid, remainder is 111
*ERROR* Raw EDID:
<3>00 ff ff ff ff ff ff 00 5a 63 1e a2 01 01 01 01  ........Zc......
<3>91 11 01 03 80 2f 1e 78 2e d0 05 a3 55 49 9a 27  ...../.x....UI.'
<3>13 50 54 bf ef 80 b3 00 a9 40 95 00 90 40 81 80  .PT......@...@..
<3>81 40 71 4f 31 0a 21 39 90 30 62 1a 27 40 68 b0  .@qO1.!9.0b.'@h.
<3>36 00 da 28 11 00 00 1c 00 00 00 ff 00 XX XX XX  6..(.........XXX
<3>XX XX XX XX XX XX XX XX XX 0a 00 00 00 fd 00 32  XXXXXXXXX......2
<3>4b 1e 52 11 00 0a 20 20 20 20 20 20 00 00 00 fc  K.R...      ....
<3>00 56 47 32 32 33 30 77 6d 2d 45 55 0a 20 00 39  .VG2230wm-EU. .9

radeon 0000:01:00.0: DVI-I-1: EDID invalid.
*ERROR* DVI-I-1: probed a monitor but no|invalid EDID

Did the EDID serial EEPROM just died on me? This story about reprogramming the EDID chip in a TV suggests that at least in some devices these EEPROMs aren't actually write protected. So it might also just been corrupted by a bug in the video driver or something in its vicinity.

OK, doing something like the procedure described in linked article above shouldn't be too hard. But where to find the original, uncorrupted EDID image? ViewSonic helpfully provides software for inspecting EDID, but doesn't include the original data.

Then, while searching for the original EDID image, I stumbled upon this thread about a similar problem. It suggested an amazingly simple solution:

• Plug in both DVI and VGA cable into video card and monitor,
• turn on computer and let it boot,
• shut down computer,
• unplug VGA cable but leave DVI alone,
• unplug monitor for 10 seconds,
• turn on the computer.

I found it hard to believe this voodoo would help, but considering the number of people there that said this helped, I tried it anyway. And it worked!

Interestingly, this is how EDID looks now (changed bytes in bold):

(II) RADEON(0):   00 ff ff ff ff ff ff 00 5a 63 1e a2 01 01 01 01
(II) RADEON(0):   22 11 01 03 80 2f 1e 78 2e d0 05 a3 55 49 9a 27
(II) RADEON(0):   13 50 54 bf ef 80 b3 00 a9 40 95 00 90 40 81 80
(II) RADEON(0):   81 40 71 4f 31 0a 21 39 90 30 62 1a 27 40 68 b0
(II) RADEON(0):   36 00 da 28 11 00 00 1c 00 00 00 ff 00 XX XX XX
(II) RADEON(0):   XX XX XX XX XX XX XX XX XX 0a 00 00 00 fd 00 32
(II) RADEON(0):   4b 1e 52 11 00 0a 20 20 20 20 20 20 00 00 00 fc
(II) RADEON(0):   00 56 47 32 32 33 30 77 6d 2d 45 55 0a 20 00 39

The changed byte represents the week of manufacture according to the EDID standard. 91h is invalid as a week number (at most 36h weeks in a year) and doesn't share any common bits with 22h. This makes it improbable that either some intentional mechanism or a random bit-flip in the hardware would cause this error, so it remains a mystery to me.

Is it just me or you just can't get any work done lately without some random piece of software or hardware going belly up on you?

I finally found the time to finish assembling the "Russian" tube clock I got from Dedek Mraz. It seems I'm starting to gather quite a collection of weird time keeping devices.

Assembling the kit was a no-brainer - instructions include three pictures for every component you need to solder and have you check parts of the circuit before continuing. The only slightly tricky bit was getting the tube to align nicely with the casing before soldering its (many) pins.

Considering the kit comes from US, it was a nice touch to include 24 h European time and date format (yes, the clock can also show the day of week and current date). The power brick only had an US power plug though. I replaced it with the EU one - the circuit itself already supported 230 V.

Also, the pictures don't really show how the display looks like. Mine glows in a blue-green color and isn't particularly bright (I have the brightness set to 55). If you remember old video recorders that used to blink "12:00" (they also used to have VFDs) - that's how the tube actually looks like.

One annoying thing I noticed is that it's hard to set the clock to the second. You can't wait for the wall clock to catch up with the frozen seconds display because the menu will time out in less than a minute.

This means it's harder to assess the accuracy. Also this circuit doesn't provide a trimmer capacitor to fine adjust the oscillator frequency. I had the idea to add a DCF77 receiver (it appears there's a contact provided on the PCB board for that). However the FAQ page says the boost converter is too noisy for such a receiver to work near the clock. If that's true, I wonder what other devices also are also affected by this interference.

Vacuum Fluorescent Display tube from Adafruit's Ice Tube Clock, which I'm assembling right now.

The day before yesterday the ADSL modem connecting my server to the internet went belly up. I called the national ISP's technical support and was actually quite surprised when they quickly established that their modem is to blame (my previous experience was that they aggressively stick to the "reboot windows, check control panel settings" routine for all problems).

So yesterday a technician came and replaced the modem. tablix.org is back on-line and I can read my mail again. However instead of the old vanilla modem he installed some fancy new thing that among other things can also work as an ADSL modem.

The new device is a Sinope 568+ from Iskratel. It literally includes everything plus a kitchen sink - a PPPoE client, DHCP, DNS servers, HTTP proxy with a built-in censorware (a.k.a. parental control), VOIP, ... and 802.11abg hardware. In other words, everything I don't need. And what's worse, it appears all these capabilities are potentially under the direct control of the benevolent (?) ISP. At least judging by the instruction manual that says that if you can't set something up you just call support and they set it up for you remotely.

Somehow I'm not exactly content with the idea that there's a wireless transceiver in the house that's not under my control. Now I'm playing with the idea to replace the antenna with a nice little 50Ω terminator.

The particular device I got was obviously second hand, because it was already set up with a wireless SSID "Kresho" and a password I didn't know. After some experimenting I found that factory settings can be restored by holding the reset button while power-cycling the modem.

All these useless features also come with a power price. My UPS load went up 15% after Sinope was installed. I guess that is considered progress these days.

When I was replacing the left mouse button on my EeePC 901 the other day, I turned the motherboard around for the first time. Interestingly, there's a button there that doesn't seem to serve any purpose. It faces a solid plastic wall, so there's no way to get to it while the computer is in operation.

I wonder what's it for. Some kind of an alarm if the laptop's case was opened? But as far as I can see it doesn't get pressed when the case is assembled. Is it a vestigial reset button? Maybe the pinhole under it was scrapped as a cost-cutting measure.

It would be nice if Asus would include it as a spare mouse button, but unfortunately it has a completely different shape and size.

A couple of weeks ago the left button on the touch pad of my EeePC 901 stopped working. At first it only skipped a click now and then, but it soon became completely unusable. It appears that I'm not alone with this problem.

I took the laptop apart and it was immediately obvious that the SMD tactile switch wasn't making a contact when it should be.

The switch itself is pretty special, so it wasn't easy to find a replacement. It has a standard 6x6 mm footprint with gull-wing SMD connections, but a very low profile (the top of the button is only 3.1 mm above the circuit board). Plus, it has a fifth connection for grounding its metal case.

After some time consuming searching (where's that semantic web when you need one?), I found a perfect match: APEM DTSGZM-62N. However, it turned out to be impossible for me to get it in any reasonably low quantity.

The Diptronics DTSMW-66N, as pointed out by Carl on his blog, proved to be a satisfactory replacement and was available from the local electronics shop. This switch has the same outside dimensions as the original, except the button is concealed inside a raised edge. The 901 has an extra millimeter of space under the touch pad (unlike 701) and the button is pressed by a needle that fits inside the circumference, so the raised edge isn't a problem and no other modifications were necessary. This Diptronics switch doesn't have a grounding connection, but as far as I can see, this doesn't affect its operation or the operation of the capacitive touch pad above it.

When I replaced the switch, the left click still wasn't working. After some more extensive searching for further faults I found that I must have had accidentally broken a minute PCB trace running from the button's contact to a tiny SMD capacitor nearby. I did a quick fix by bridging the gap with a blob of solder (you can see it at the button's top right pad on the photo above).

Now the left click is finally working again. Although the replacement switch has the same rated operation force (1.6 N) as the original, the button now feels slightly softer.

I must say that by now I'm severely disappointed with the quality of buttons and switches I'm seeing lately. I had to fix 901's hot keys when the computer was brand new and I'll only mention my terrible experience with the Happy Hacking Keyboard.

I managed to bring the broken Time Capsule from the office back to life today. It turned out that the problem really was only in the Flextronics power supply, so when I connected the +5 V and +12 V rails to a lab power supply it booted up.

The yellow LED is blinking which, according to the manual, means it cannot get an IP from the DHCP server. After restoring the factory settings I saw the "Apple Network XXXXXX" on wireless and was able to connect to it with my laptop.

Unfortunately, even with the hardware working, it's still a brick as far as I'm concerned. It appears that these things can only be configured with a proprietary Mac or Windows application. There's no friendly HTTP server to greet you. Instead nmap shows port 5009 "airport-admin". I did find this Java configurator, but it doesn't say anywhere if it works with Time Capsules and I haven't tried it yet.

As far as the broken power supply is concerned, I haven't found the problem so far. Starting from the largest components and going downwards in size, I got to the high-voltage MOSFET and the rectifying diodes, all of which appear to be fine.

Even if I manage to fix it, I don't think I'll be putting it back into the white box just to get overheated again.

Look what I found today:

It's an old DE-620 Ethernet adapter that was manufactured by D-Link. This used to be the only way I could get onto an Ethernet network with my Compaq Contura 4/25cx.

It has a parallel port connector on one end (largely obsolete today) for connection to a host PC and a 10BASE2 (thin coaxial, very obsolete) and 10BASE-T (UTP, common today) connectors on the other. This device had wonderful support on the old 2.0.x series of Linux kernels.

I can't recall what kind of bandwidth I could get with it, but I believe it was several orders magnitude better than a serial modem connection (especially since Contura's UARTs could only manage 9600 bit/s), but slower than the theoretical 10 Mbit/s for Ethernet.

Another curiosity was that it required external power through a power brick that's rated at 12 V and 500 mA (parallel port didn't provide power to devices). Today I guess I could almost run a complete EeePC with those six watts of power.

On my last post Dušan pointed to an article that raised suspicion that errors in non-ECC RAM are one of the main causes of computer crashes these days.

I tend to disagree - I have seen and administered enough computers that ran ordinary desktop PC grade hardware and I haven't seen the numbers of unexplained software crashes that I should have if non-ECC RAM would really be that unreliable.

However, that may just be another case of the old story where a software engineer will blame hardware when his software crashes and a hardware engineer will claim vice-versa.

So, I'm starting a very simple experiment: I'm dedicating 10% of my server's non-ECC RAM for cosmic particle detection. In other words, I've written a short program that allocates 128 MB of RAM, fills it with a test pattern and checks once every day if the same pattern is still there. I'll keep it running as long as possible.

With the best FIT figure from Google (25000 failures per 10⁹h per Mbit) and assuming that bit flips have a Poisson probability distribution:

I should have over 98% probability to see at least one error in 7 days. I would bet the proverbial case of beer that won't happen.

Of course, the logical argument here would be that my machine simply isn't in those 8% that see errors. So it would be interesting to see if this program reports any errors on some machine that experiences lots of unexplained crashes.

A while ago Google and University of Toronto published an article (PDF) about the results of a two-and-a-half year long study into DRAM reliability.

The bottom line of their findings is that they have seen on average 25 to 70 thousand errors per 10⁹ operating hours per Mbit, and 8% of the memory modules having some kind of an error in the course of a year.

Those are some pretty large numbers. My server currently sports 1 GB of non-ECC RAM. With that kind of an error rate, I would be seeing a bit-flip every day or so. I'm pretty confident that's not happening. Of course, without ECC, I don't have any way of being sure. But with a bit-flip per day, I'm sure the software would be crashing much more often than it is.

Of course, with only 8% of the population affected by errors, it can be that I just got lucky.

But still, non-ECC modules with these kinds of error rates would be unusable. Does that mean that ECC modules being sold are actually of lower quality than non-ECC? I can imagine that an ECC module with an occasional recoverable error would be easier to pass through quality control than an non-ECC one with similar reliability.

Apple users at Zemanta used to backup their machines to an Apple Time Capsule. I say used to because it went belly-up a while ago, probably for the same reason as many others of its kind. On Friday we did some clean-up in the office and I took the white brick home, to see if I can still find some use for it.

Disassembly went quite smooth. Actually, the approach was somewhat similar to what I did with Piki the Pleo. And similarly irreversible.

Inside is a normal hard drive and an embedded computer which I hear is running NetBSD. As far as my web searches have shown nobody has yet managed to run any kind of custom software for it, so I guess that option is out.

It also becomes obvious why these things are dying of overheating. What kind of a thermal design is that? The fan does nothing - it just mixes hot air around the case as there are hardly any holes in it. There's also precious little air to actually mix around because the case of so packed. Interestingly, there seems to be a temperature sensor glued to the hard drive.

So far I haven't done much more than just poked around for a couple of minutes, so right now I have no idea why it's simulating a brick and whether it's fixable or not. Nothing is obviously blown out.

DLP-232PC is described as a low-cost USB data acquisition module for process monitoring and control. In practice that means a tiny circuit board that fits into a 300 mil DIP18 socket, sports a mini-B USB connector and has 14 GPIO digital channels, 8 of which can also be switched to analog read-out. From the USB host point of view it presents itself as an USB-to-serial converter and is controlled by sending single byte commands through the virtual serial port (e.g. sending ASCII '1' puts pin 1 high).

Now imagine some old hardware that connects to the PC's parallel port and used to be controlled by old-fashioned DOS software doing bit-banging on the printer's pins. DLP-232PC sounds like a good tool to easily port that old software to a modern operating system running on a modern computer that doesn't have a parallel port (USB-to-parallel converters don't work, but that's a whole new story). Simply replace parallel port writes with appropriate writes to the virtual serial port, recompile for Windows and everything should work fine.

Well, some experiments showed that in practice it's not that simple. The data-sheet says that the serial port baud rate is set to 460800, so in theory it should be able to take 46080 single-byte commands per second (i.e. around one state change per 20 μs). Unfortunately DPL-232PC is actually implemented with a 18F2410 PIC microcontroller that reads commands from the UART and controls its GPIO pins in software.

Here's the first, simple experiment: do a burst of 8 impulses on channel 3 by writing a block of 16 bytes (8 repetitions of ASCII "3E") to the device (e.g. /dev/ttyUSBx on Linux, or COMxx on Windows).

This is the result the oscilloscope showed. You can see that doing anything that require real-time determinism is going to be hard. First two impulses are cca. 80 μs wide, while the rest are closer to 25 μs. The pattern of pulse widths changed with different block lengths. This was the result when DLP-232PC was controlled from a Windows XP host. An equivalent test with my Linux-running EeePC gave a more regular waveform, where all impulses were 80 μs wide (i.e. around 4 times theoretical minimum).

I'm not sure what is causing this. Maybe it's a quirk in the USB transport, or Windows drivers. But it does make me a little skeptical if you can reliably bit-bang, say, an I²C protocol on this.

This is another test, to see how it handles two channels. It was done by continuously writing "36EY" as fast as possible to the device, which cycles states of channel 3 and 6. Again, running on Linux gives a this deterministic waveform, with the pulse width around two times that of the first test (as expected). On the Windows machine, the things look much more chaotic.

One other interesting feature of this device had shown itself during testing: during the two channel test DLP-232PC simply froze. From the oscilloscope trace it appeared that the IO pins were put into the high-Z state and the device stopped responding to any commands from the PC (even to the reset and ping commands). Disconnect/connect didn't fix it, although the USB handshake worked normally (we did notice that the diagnostic LED blinked a little different pattern than usual on power-on). Only after being disconnected from power for a couple of minutes did it unexpectedly return to life.

My only explanation is that somehow the software in the PIC crashed (maybe receive buffer overflow) and the microcontroller didn't reset properly when the power was absent only for a short time.

So, the first impression says this is not exactly fly-by-wire grade material. Beware of hardware that is actually software in disguise.

Mailman just brought me a box of goodies. Among other things a couple of these were inside:

I never worked with an Arduino before and I thought I might try playing with one considering all the buzz that's been going on around them. And I might have just the right place to use it.