Daniel Schneller's Blog

Amiga 500 Restoration: Mouse and Mainboard Maintenance

2020-08-25T01:31:00.001+02:00

With the memory expansion board fixed in the last post, I needed to perform more electronics fixes, this time to get the mouse back in working order. Notice that I did this in March 2018, but somehow forgot to write the post. So with a little delay, here it is.

This is the fourth post in a series about restoring an Amiga 500 back to its former glory. Here are all of them so far. I’ll try to remember to update this in all related entries.

2017-12-24: Amiga 500 Restoration
2018-01-05: Retrobrighting I
2018-02-05: A501 Memory Expansion
2018-02-05: Mouse and Mainboard Maintenance

To Click, or Not To Click

When I won the ebay auction, I quickly realised that finding an Amiga compatible (modern) monitor would be a problem. Luckily, my 2011 Panasonic plasma TV has a SCART input, which I remembered to be compatible with the Amiga RGB output. Resisting my first urge to build a cable myself, I instead ordered one for a few Euros from another ebay seller. While waiting for it to arrive, I could just do a very superficial check. Read the first post Amiga 500 Restoration for more on that.

When the cable finally arrived, in the meantime I had received two sets of Workbench and Extras disks, too. Armed with those, without even having the keyboard caps put back on, I hooked up the Amiga to the TV, just because I was so curious to see the Workbench for the first time in decades. Fully aware that I wouldn't be able to type anything, at least I could click around with the mouse for a bit. Or so I thought.

When the workbench screen came up, I noticed that only one of the mouse buttons worked. The menu bar would change when clicking and holding the right one, but no click events were registered by the OS for the left button. My first guess was that the left button switch was just worn out and had failed and would have to be replaced. But, I thought, maybe it was something else, because both buttons sounded and felt just the same. So I suspected something might be wrong with the cable or the connector and I would have to investigate in more detail. Spoiler alert: Sometimes your first idea is not wrong, but also might not be completely right.

The Mouse Cable

I opened the mouse and checked continuity between the connector on the mouse PCB and the D-SUB9 socket at the end of the cable. And bingo: The line for the left mouse button did not show any connection, unless I added a thin wire to the probe and shoved it very far into the corresponding hole in the socket. Visually the plug looked quite worn out, too, so it made sense that the pin from the Amigas male D-SUB counterpart did not reach far enough into the socket to make a connection.

I ordered a replacement connector, and when it arrived, I cut off the original, taking a few closeups to easily verify the order of the wires later.

Next, I tinned the leads to make it easier to fit them into the new connector…

… and then soldered them into place:

Turns out, the first one was easy, but with each further one, it got more difficult to fit them into their little solder cups while not burning the insulation of the previous ones. I am quite pleased with the end result, though.

I double checked I had connected each color to the right pin and also verified connectivity between the connector inside the mouse, and the new plug. This time, none of them made any trouble.

Finally I just needed to put the casing around the connector. This is what it looked like in the end:

It is not quite as slick as the original one, but what can you do...

To Click, or (still) Not To Click

Eager to finally get some clicking action done, I hooked the Amiga up to the TV again. Imagine my ~~surprise~~ disappointment when it still did not work. Also, and I had noticed that before, but not paid attention to it, the pointer only moved along one axis. So there was still something wrong with that mouse, or was it?

With the new connector in place, I had a closer look at the mouse port on the motherboard. At first, it looked ok, but when I pointed a light directly at it at just the right angle, this is what I saw:

So not only was the connector on the mouse worn out, but also its counterpart on the board had three broken pins. Port 2 was fine, but AmigaOS does not let you choose between them for the mouse. So that needed replacement as well. Here's a close-up of the broken port from a slightly different angle, making the damage even more obvious:

Once the ordered replacement arrived, I needed to desolder the defective port from the motherboard. That turned out to be quite challenging. There are two anchoring hooks, one each to the left and right of the actual socket. Those are supposed to provide mechanical stability for the ports, but at the same time they act as a heat sink, because they are directly attached to the connectors casing and also linked to the board with big blobs of solder. So it took quite a while to get everything hot enough to finally melt the solder and get the old part out. This is the result (from the underside of the board) after cleaning up the mess of flux and solder remains:

As you can see, not only does the socket and its shield act as a heat sink, but they are soldered to a large ground plane on the circuit board as well, so if you ever need to do something like this yourself, be patient and make sure to use a soldering iron with enough power. Alternatively, preheat the board around that area with hot air, if you have a hot air station.

Getting the new part in was, of course, way easier. Here's a comparison of the old and new sockets side by side, and the underside of the board with the new part in place:

I made sure to again put a good amount of solder in the mounting holesto provide the required physical strength to survive lots and lots of insertions for years to come.

To Click, or... Well, You Know What's Coming...

Clearly, now with the connectors on both the computer's and the mouse's side fixed, what could possibly go wrong now? First of all, at least the pointer was now moving correctly along both X and Y axes, but the left button was still not working. Remember the opening paragraphs of this post?

Spoiler alert: Sometimes your first idea is not wrong, but also might not be completely right.

You might be guessing it already: When I had checked for continuity after replacing the plug, I had measured from the mouse PCB connector to the other end of the cable, but not from the switch. And, of course, the left button had actually failed. I had a few of those in stock, so as a final step I replaced them both the left and the right ones.

Finally!

When first hooking up the computer to the TV little did I expect how much damage had to be repaired to get the mouse working again. Nevertheless, following through with all these individual repairs was a good exercise in fault finding, and in staying persistent, even when the initial fix did not bring the mouse back to (full) life.

In the end I can now be sure, however, that mechanically this mouse and mainboard are going to last for a long long time :)

HAProxyConf 2019: Inspect, Control, Report: HAProxy as the SRE’s Door Man

2020-04-13T16:27:00.001+02:00

In November 2019 I spoke at HAProxyConf in Amsterdam about how we at CenterDevice use HAProxy to protect backend servers from malicious users and log information that is vital during troubleshooting. HAProxy ACLs serve to classify unwanted traffic, including vulnerability scanners and spam bots, and then HAProxy deny rules filter traffic. Moreover I talk about how HAProxy gives us detailed logs and metrics, which we visualize using Grafana, Elasticsearch and Kibana, and how we employ DNS service discovery to automatically configure load balancing to backend servers.

Conveniently the HAProxy folks have provided a full transcript of the presentation, as well as a recording. To read along, visit the HAProxy User Spotlight Series page.

Schoko Toffee Cookies

2018-12-02T23:16:00.001+01:00

Nachdem ich zufällig über das YouTube Video zum “Brown Butter and Toffee Chocoloate Chip Cookies” Rezept von “bon appétit” gestolpert war, habe ich heute die zweite Ladung Kekse produziert. Da das Rezept mit amerikanischen Maßen hantiert, und ich heute erneut leicht genervt Cups und Butter-Sticks umzurechnen hatte, lohnt es sich wahrscheinlich, das ganze einmal mit hierzulande gebräuchlichen Einheiten zu reproduzieren. Die Umrechnung ist nicht exakt so, wie man sie in den typischen Tabellen findet, sondern auf etwas "glattere” Werte gerundet. Bisher sind allerdings noch keine Klagen hinsichtlich der Ergebnisse gekommen :)

Das Rezept reicht für etwa 30 Cookies.

Zutaten

200g Brauner Zucker
60g Weißer Zucker
250g Mehl (Type 550)
250g Butter (keine Margarine)
2 Eier (M)
1 Päckchen Natron (entsprechend 1 Teelöffel)
1 Teelöffel Kochsalz für den Teig
1-2 Esslöffel Salzflocken für die Dekoration
200g dunkle Kuvertüre
2 Rollen “Rolo” Karamellbonbons
1 Vanilleschote oder ca. ½ Fläschchen Backaroma Vanille

Teig vorbereiten

Butter bräunen.

Dazu die Butter in einem kleinen Topf bei mittlerer Hitze auf dem Herd schmelzen. Dabei insbesondere zu Beginn öfter umrühren, damit es nicht spritzt. Sobald die Butter aufschäumt, die Hitze etwas reduzieren und einige Zeit weiter schäumend köcheln lassen. Es setzt sich Eiweiß nach oben ab, das durch Rühren immer wieder etwas untergezogen werden sollte.

Die nächsten Schritte lassen sich parallel vorbereiten. Dennoch ein Auge auf den Topf haben und gelegentlich rühren, bis die Butter nach etwa 10 Minuten anfängt am Boden einen braunen Satz zu bilden. Der Geruch ändert sich, wird nussiger und erinnert bereits an Karamell.

Wenn das soweit ist, die Butter vom Herd nehmen.
Mehl, Natron und das Kochsalz vermengen.

Dazu alles in eine kleine Schale oder einen Suppenteller geben und mit einem trockenen Schneebesen durchmischen.
Die Kuvertüre auf einem großen Schneidbrett mit einem Kochmesser mit breiter Klinge zerkleinern. Dazu möglichst senkrecht jeweils etwa 0,5cm breite Streifen von dem Schokoladenblock “abschneiden”. Das Ergebnis sind Schokoladenbröckchen, die sich später gut unter den Teig mischen lassen. In einer Schüssel oder Suppenteller zur Seite stellen.
Rolos aus ihrer Folie auswickeln. Jeweils 5-6 Stück auf dem Schneidbrett in einer Linie aufreihen und mit dem Kochmesser in 3-4 Scheibchen schneiden. Wiederholen, bis alle Rolos geschnitten sind. Die Stückchen nicht in eine Schale, sondern auf dem Brett ausgebreitet liegen lassen, weil sie ansonsten durch das Karamell klumpig zusammenkleben.
Die inzwischen gebräunte Butter in eine Rührschüssel gießen — eine Metallschüssel empfiehlt sich, weil die Butter daran schneller abkühlen kann. Mit einem Teigschaber oder Löffel auch den am Boden des Topfs noch anklebenden Satz mitnehmen.
Braunen und weißen Zucker in die Butter geben und mit einem Mixer vorsichtig etwas eine Minute durchmischen. Dadurch senkt sich die Temperatur der Butter bereits erheblich.
Abwarten, bis die Mischung aus Butter und Zucker sich nur noch warm, aber nicht mehr heiß anfühlt. Andernfalls läuft man Gefahr, dass die Eier stocken.
Unter Rühren mit dem Mixer das Vanillearoma und die Eier hinzufügen und für 1 bis 2 Minuten aufschlagen. Die Masse wird dabei hellbraun und sämig.
Mixer auf langsames Tempo stellen und die Mehlmischung in drei bis vier Portionen hinzufügen. Nur so lange rühren, bis das Mehl sich mit den feuchten Zutaten vermengt hat. Nicht darüber hinaus aufschlagen. Der Teig dürfte zu dieser Zeit bereits merklich klebriger und fester werden, daher die restlichen Schritte zügig durchführen.
Zuerst gehackte Schokolade, dann Rolos hinzugeben und jeweils mit einem stabilen Holzlöffel unter den Teig heben. Hierbei nicht mehr den Mixer verwenden, um die Schokolade nicht weiter zu zerkleinern!
Die Schüssel mit dem fertigen Teig mit Frischhaltefolie abdecken und mindestens 30 Minuten ruhen lassen. Ich stelle ihn dazu in den Kühlschrank. Dadurch lässt er sich später besser portionieren. Laut Originalrezept kann man den Teig bis zu drei Tage im voraus zubereiten.

Portionieren und Backen

Backofen auf 160-170°C vorheizen (Heißluft).
Backblech mit Backpapier auslegen. Falls es sich von selbst wieder aufwickeln möchte, einfach an den Längsseiten einmal beherzt zugreifen und es etwas zerknittern. Dann bleibt es auch freiwillig liegen.
Vom kühlen und festen Teig etwa 1 Esslöffel aufnehmen und zwischen den Händen zügig zu einer Kugel mit Größe eines Golf- oder Tischtennisballs formen. Mit reichlich Abstand auf dem Backpapier verteilen. Die Cookies werden beim Backen deutlich größer, daher fasst ein Backblech nur 6 Cookies.

Beim Platzieren der Kugeln so gut es geht darauf achten, dass eventuell vorhandene größere Karamellstücke möglichst mittag nach oben gerichtet sind, damit sie mittig im fertigen Keks landen. Liegt ein solches Stück am äußeren Rand des Kekses, wird es beim Backen flüssig und der Keks hat keine gleichmäßige runde Form mehr. Schmeckt genau so gut, sieht aber nicht ganz so schön aus.
Über den Teigkugeln jeweils zwei Salzflocken zwischen den Fingern zerkleinern und verteilen. Wenn etwas Salz daneben fällt ist das kein Problem, da der Teig im Ofen zerfließt und dabei die umliegenden Flocken “einsammelt”.
Kekse in den vorgeheizten Ofen schieben. Bei Heißluft lassen sich problemlos zwei Bleche gleichzeitig backen.
Je nach Ofen beträgt die Backzeit etwa 8-11 Minuten. Die Cookies sind fertig, wenn sie komplett zerlaufen sind und sich der Rand erkennbar bräunt. In der Mitte sind die Kekse dann noch ein bisschen weich. Beginnen sich am Rand Risse zu bilden, ist es höchste Zeit sie herauszunehmen. Wenn sich auf der gesamten Oberfläche Risse zeigen, ist die Temperatur wahrscheinlich zu hoch und die Cookies werden hart.
Kekse Aus dem Ofen nehmen und auf dem Backblech noch wenigstens 10 Minuten liegen lassen. Die Kekse sind zu dieser Zeit noch viel zu weich, um bewegt zu werden.
Nachdem sie für einige Minuten abgekühlt sind, die Kekse mit einem flachen Spatel – vorzugsweise aus Metall – vorsichtig vom Backpapier lösen und zum endgültigen Abkühlen auf ein ebenfalls mit Backpapier ausgelegtes Kuchengitter legen. Nach jedem Keks die Vorderkante des Spatels reinigen, da hier Karamell festklebt, das das Ablösen der weiteren Kekse zunehmend schwieriger macht. Sie neigen dazu, dann daran festzukleben und zu zerreißen.
Das Backpapier braucht meiner Erfahrung nach nicht ausgewechselt werden. Es bietet sich aber an, nach jeder Ladung Kekse mit dem Spatel eventuelle Schokoladen- und Karamellreste zur Seite zu schieben.

Bon Appétit :)

Add Custom HTTP Basic Auth Entries to iCloud Keychain

2018-06-16T15:19:00.000+02:00

While automatic filling of HTTP basic auth credentials works fine on the Mac, I have had significant trouble getting it to work on iOS devices. This is especially unfortunate, because while on the road I sometimes need to have a look at monitoring systems that have HTTP basic authentication enabled and that use long complex passwords. Should be easy with iCloud keychain, right? Yeah...

Opening the respective site in iOS Safari pops up the basic auth credentials dialog. It also shows the little key icon in the keyboard toolbar which gives access to iCloud keychain entries. However, while on the Mac the username and password fields are correctly populated, on iOS you cannot even see the respective entry.

Turns out, and I assume this is a bug in iOS Safari, the type of keychain entries shown is limited to "Web form password". Safari on the Mac stores the entry as "Internet Password" though, as can be seen in the Keychain Access application on the Mac:

Knowing that, we just need to change the type or create a new entry in the iCloud keychain. That should be easy, right? Well...

Turns out, there is no way to specify the type when adding a new entry via the Keychain Access app. So that does not help. On to changing the existing "Internet Password" item then... But also no luck there. While you seem to be able to change the type in Keychain Access by just changing the value of the "Kind" field, this apparently has no impact on the actual type in the database underneath.

There is a (kludgy) way, though, that works: Edit any other "Web form password" that was created by Safari (when you allow it save a password for a website with a login form) and then edit the URL, username and password fields in Keychain Access. What caught me at first and almost made me think it didn't work was that you need to hit Cmd-S to save the changes made to the entry. For some reason using the "Save Changes" button in the window did not actually do that.

Getting a new web form entry is also quite easy, without having to actually use a real website. I just saved this minimalistic HTML form to a local file to my local drive as "dummy-password.html" and then served it up to Safari with the Python SimpleHTTPServer:

<html>
  <body>
    <form action="http://localhost:8080/doesntmatter" method="post">
    <label for="username"><b>Username</b></label>
    <input name="username" placeholder="Enter Username" required="" type="text" />
    <label for="password"><b>Password</b></label>
    <input name="password" placeholder="Enter Password" required="" type="password" />
    <button type="submit">Login</button>
  </form>
</body>
</html>

Then in the same directory where the file is saved start the HTTP server via Terminal:

$ python -m SimpleHTTPServer 8080

Now, in Safari go to http://localhost:8080/dummy-password.html. It will show you simple password form. Enter the credentials you want to save in the keychain and hit the Login button. Even though you will get an error message displayed, because there is nothing the data can actually be sent to, Safari will nevertheless offer to save what you just entered:

Keychain Access will show the new entry as "localhost". Double click and edit the entry. Remember to save with Cmd-S when done. Notice that it seems to not reliably save multiple changed fields at once. I noticed that while the domain part was correctly saved, the changed port was not. So I went in again and changed the port, which finally made it stick.

After a few seconds they entry showed up on my iPhone, too. Heureka!

One final tidbit: The ordering in the list of credentials shown on the iPhone is a little strange. At first I could not find my new entry (which was a little longer than the one shown in the screenshot above). Turns out, Safari orders them by the second level domain, not by the subdomains. It makes sense insofar as that otherwise most sites would be sorted under "w" (www being a very common subdomain). But when you have something like "monitoring.staging.test-domain.com" you will find your entry sorted under "test-domain.com", not "monitoring".

Amiga 500 Restoration: A501 Memory Expansion

2018-02-05T10:00:00.001+01:00

The previous posts were mostly about cosmetics. This one is more technical, dealing with the repair and some preventative maintenance of the A501 memory expansion card. If you are curious to learn more about the retrobrighting of the computer’s case, don’t worry — I’ll get back to that at a later time.

This is the third post in a series about restoring an Amiga 500 back to its former glory. Here are all of them so far. I’ll try to remember to update this in all related entry.

2017-12-24: Amiga 500 Restoration
2018-01-05: Retrobrighting I
2018-02-05: A501 Memory Expansion
2018-02-05: Mouse and Mainboard Maintenance

Amiga Memory — The Basics

When the Amiga 500 was first introduced, it came with 512KB of memory. That was already double the amount the original Amiga 1000 had, but still not a whole lot. Especially when developers started to get familiar with the audio and video capabilities of the machine, RAM became a limiting factor in what you could do. Merely copying a single floppy disk with its 880KB required swapping back and forth between the source and destination disks, because there was no way the contents could be loaded into a memory buffer in one go.

So one of the more popular additions to any stock Amiga 500 was the A501 memory expansion card. There were a few original Commodore revisions, and a plethora of 3rd party clones. They all get installed in the so-called "trapdoor slot", aptly named, because it is reachable by opening a cover on the underside of the computer. With it installed, the Amiga now has 1MB of RAM to work with — a way better baseline for many tasks. I will not go into detail here on the different kinds and speeds of Amiga RAM here. It is a rather complicated story because depending on several hardware and software factors memory could have different speeds and capabilities, especially when it came to the custom graphics and sound hardware. Suffice it to say though, that even the slowest possible expansion is still better than the rather anemic stock 512KB.

When buying my Amiga from eBay I made sure, that it came with a memory expansion. In my case, it even was an original Commodore A501.

The Real Time Clock

In addition to the extra memory virtually all trapdoor expansion boards also add a battery-buffered real time clock. The Amiga itself — apart from very late models — does not have a clock on board. Without one, whenever the power is turned off, the computer forgets the date and time. When you switch it on the next time, it believes it's sometime early in the 1980s, or whatever the last modification timestamp of your boot disk is (which in my opinion is even worse). The A501 fixes that. It brings a clock chip, a very small amount of memory dedicated to keeping the date and time, and a rechargeable NiCd battery to supply the chip while the computer is off. When the computer is on, it gets charged up again. That way software can read the current time and date from the expansion on boot, sparing the user the tedious task of having to set it manually every time.

Batteries don’t age well...

So far so good. Unfortunately, batteries — especially NiCd ones — tend to leak when they get old. When that happens, the chemicals from inside the battery start to corrode and aggressively dissolve anything they come in contact with. Over time, this effect spreads — almost like an infection — across the memory expansion board, destroying the copper traces, solder joints, etc. Given enough time, it will creep into chips and destroy them from the inside. My original Amiga suffered this fate when its battery leaked unbeknownst to me while it was in storage. When I finally tried to use it again years later, it would not even start up to the Kickstart screen, because the damage had spread and eaten parts of the motherboard.

As I remember, it looked quite similar to this poor thing. The pictures were taken from part 1 of Keith Noneya’s YouTube series on meticulously repairing a heavily damaged A501 board. I recommend watching it. The 2nd picture shows that the copper was completely dissolved around where the battery was connected to the board.

So with my new arrival — which was functioning according to the eBay seller — one of the first starts I took was to remove the A501 expansion from the computer and inspect it closely for signs of battery leakage, before even turning the computer on. To do so, I had to remove the metal shield the board was encapsulated in:

To do so, just with the RF shield covering the computer’s mainboard, a series of metal tabs must be opened. Unfortunately, on the A501 they are not just bent over, but also soldered shut. Obviously, Commodore didn’t want curious customers to peek inside. But with a little patience, and armed with a soldering iron, a simple desoldering pump, and some copper braid, I got it open. The pictures show the position of the tabs, and one close up.

If you intend to put the board back into the metal case later, make sure not to lose the plastic sheet that is inside, insulating the underside of the board from the metal of the case. Without it, you would get random short circuits between the soldering joints! You can, of course, also just leave the shield off afterward. Most of the 3rd-party clones did not even have one in the first place.

Removing the Leaking Battery

Fortunately, at first glance my board was not in a bad shape, even though the battery had definitely already begun to leak. This is what one side of the contacts looked like:

The green crust is corrosion, and it has already spread down along the connectors. So it was clear, it needed to be taken off the board. To do so, I heated the soldering points on the underside of the board thought the copper braid. Carefully taking turns heating each of the joints, with a careful but firm pull on the battery from the upper side, it came off after a few cycles.

Once it was out, some minor damage became obvious, but luckily nothing serious:

I cleaned the area with an old toothbrush and Q-tips. To neutralize the alkaline battery fluid residue, I used some vinegar first and cleaned everything up later with and isopropyl alcohol. I took a bit of time to make sure the through-hole and the back of the board were also cleaned. Once everything had dried up, it looked not much different from before, just the crusty bits were gone.

With the battery removed, the RAM expansion worked. That was a good start. But of course, it could not keep the time while off anymore. So this needed to be fixed next.

Building a Battery Replacement Board

While in theory I could have gotten an identical or at least similar battery type, that one would be prone to leaking over time, too. So I — and others before me — wanted to use a more common and more reliable battery type as a replacement. The omnipresent CR2032 coin cell has a nominal voltage of 3V. Even though this is less than the original battery’s 3.6V, the OKI clock chip’s specifications say it can keep working down to 2.0V. With a capacity of about 240mAh (as opposed to only 60-80mAh in the original NiCd), it could theoretically keep the clock chip powered for more than 2 or even 3 years. Good enough for my taste, especially because they are cheap and easy to get, should the need arise.

However, because they are not rechargeable, precautions must be taken to keep the Amiga’s charging current away from it. Otherwise you could be in for some nasty fireworks.

My first idea was to just follow Jan Beta’s lead closely and put a coin cell holder directly onto the A501. However, for a few reasons I decided to modify my approach a bit:

The battery holder I bought has a very tight spring keeping the battery in place. Getting it out for replacement takes quite a bit of force, and I didn’t want to risk damage to the A501 in the process.
In Jan’s video, you can see that the cell holder does not fit on the board too well, making it a bit difficult to get the A501 into the trap door slot. The same was true for the one I had.
This being one of the first things I ever soldered in my life, I wanted to limit the risk for the A501 of me damaging accidentally to a minimum.

So I decided to build a little extra circuit on a piece of perfboard. On that, I would place the cell holder, a diode and some additional resistors, which are recommended by a CR2032 manufacturer. This is what it looks like from the top:

I measured 5V charging voltage coming from the Amiga. For that, the PDF linked above recommends at least 200Ω of protective resistance. I only had 150Ω resistors at hand, so in total it is now 300Ω. This is only the second “line of defense” — usually the diode ensures that the battery does not get charged by blocking the charging current from the computer. At the bottom there is a 2 point pin header for jumper wires that then go to the A501.

From below, this is what the board looks like. Notice the I flipped the previous picture, so it aligns with the bottom view.

Finally, after checking everything with the multimeter, I wrapped the edges and the bottom side of the board with insulating tape:

On the A501 I needed to add pin headers, too, to allow me to hook up my little creation. Getting two single pins off of the larger piece took a few tries, because the plastic was rather brittle. But with an old fruit knife and some patience, I managed to do it.

Putting it all together

With the A501 prepared, I could now connect the external battery holder board with two jumper wires.

And because thankfully there is quite a bit of free space in the Amiga’s case, I could easily mount the battery board right next to the trapdoor. I put a power strip on the inside of the bottom case and just stuck the board on there:

The isolating tape sticks to the Power Strip pretty tightly, so I am not worried it will easily come loose. The wires are long enough so that I can take out the A501 through the trapdoor and either disconnect them, or reach in and wiggle off the battery board. This should allow me to safely swap the battery in the future.

Battery Backed up Clock (not) found?

With all this being done, I confidently booted up a Workbench disk. Just to be greeted with this:

I must admit, I was a little disappointed. Should all the careful repair work have been in vain, because in the end the clock chip had been damaged by something in the past? At this point in the Amiga’s startup sequence the setclock load command is called. It tries to load the time from the expansion board. Apparently, it either could not find the clock chip at all, or at least could not read from it.

I continued to boot and attempted to save the time, both using the Preferences application, as well as via a Shell and setclock save. Same error message as before: Battery Backed up Clock not found.

Browsing through some forums I learned, that apparently the clock chip memory can get in a corrupt state if it is disconnected from the battery. For these cases, the recommended solution was to run setclock reset. This, however, apparently is not supported on (my) Workbench 1.3, so no luck there.

Fortunately, a little later I came across this thread on amiga.org with a link to Thomas Rapp’s homepage. In the download area, he offers a little utility called RestartClock. It comes in binary and (assembly language) source code in the RestartClock.lha archive. From what I can tell, it calls the underlying OS clock reset function to bring it back into a known state. So I downloaded it onto my Mac, just to face the next problem: How do I get it onto the Amiga?

File Transfer without a cable — Back to BASIC

With the Amiga RestartClock executable on my Mac, I was stuck. I did not have a serial (null-modem) cable at hand, which I figured I could use to send the file over. But even if I did, I couldn’t find my RS232-to-USB dongle. So I needed another way to get the program across the air-gap. At this point the prospect of ordering a cable and waiting for it to arrive did not appeal to me very much 🙂

I remembered how back in the day we used to type in pages and pages of program listings from computer magazines, because only very few (expensive ones) came with floppy disks attached. Granted, most of that was done on my first computer, the Atari 800XL, but I digress… So just typing on the Amiga would probably not take very long.

But not having an assembler for the Amiga at hand meant that I needed to bring over the binary version. What I did have was an Extras 1.3 disk with AmigaBASIC on it. I figured, if I hex-dumped the executable on the Mac, I could write a small BASIC program to output these bytes into a new file. This is the program:

REM Set this to the path and name       
REM of the executable to create.

filename$ = "RAM:RestartClock"

OPEN filename$ FOR OUTPUT AS #1
DEFINT a-z

REM Number of bytes processed so far 
n=0

REM Read from the DATA section below until
REM the magic value of 1000 is found. It 
REM marks the end of the DATA
REM Every 40 bytes print begin a new line.
REM For every byte read, print a dot.
REM Values in the DATA section go from
REM -127 to 127, because of how they were
REM dumped on a Mac. When writing them to
REM the Amiga executable, they must be
REM moved to 0-255. That's what the IF
REM statement in the middle takes care of.

READ x
WHILE x<>1000
  IF n MOD 40 = 0 THEN PRINT
  PRINT ".";
  IF x<0 THEN x=x+256
  PRINT #1,CHR$(x);
  n=n+1
  READ x
WEND
CLOSE 1
PRINT 
PRINT "done writing ";filename$

REM DATA section begins. This is a dump of
REM the executable file, created and
REM transcribed manually from a Mac. :D

REM 0
DATA 0,0,3,-13,0,0,0,0,0,0,0,1,0,0,0,0
DATA 0,0,0,0,0,0,0,86,0,0,3,-23,0,0,0,86
DATA 72,-25,-1,-2,65,-7,0,-36,0,0,50,60,3,-1,112,0
DATA 32,-64,81,-55,-1,-4,67,-6,0,-51,44,120,0,4,78,-82

REM 64
DATA -2,104,44,64,103,84,114,1,32,23,-80,-127,111,30,32,111
DATA 0,32,67,-6,0,-44,85,64,18,-40,81,-56,-1,-4,65,-6
DATA 0,-61,34,8,116,0,118,0,78,-82,-1,34,78,-82,-1,-60
DATA 34,0,103,14,65,-7,0,0,0,-126,36,8,118,99,78,-82

REM 128
DATA -1,-48,65,-6,0,-115,34,8,116,0,118,0,78,-82,-1,34
DATA 34,78,44,120,0,4,78,-82,-2,98,76,-33,127,-1,112,0
DATA 78,117,10,82,101,115,116,97,114,116,67,108,111,99,107,32
DATA 86,49,46,50,32,98,121,32,84,111,109,10,10,67,108,101

REM 192
DATA 97,114,105,110,103,32,99,108,111,99,107,32,114,101,103,105
DATA 115,116,101,114,115,46,10,73,102,32,99,108,111,99,107,32
DATA 105,115,32,97,108,108,32,114,105,103,104,116,32,105,116,32
DATA 119,105,108,108,32,114,117,110,32,97,103,97,105,110,32,110

REM 256
DATA 111,119,46,10,10,100,111,115,46,108,105,98,114,97,114,121
DATA 0,115,101,116,99,108,111,99,107,32,111,112,116,32,115,97
DATA 118,101,0,100,97,116,101,32,0,0,0,0,0,0,0,0
DATA 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

REM 320
DATA 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
DATA 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
DATA 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
DATA 0,0,0,0,0,0,0,0,0,0,3,-20,0,0,0,1

REM 384
DATA 0,0,0,0,0,0,0,86,0,0,0,0,0,0,3,-14
DATA 1000

The DATA statements at the bottom contain the dumped bytes of the RestartClock executable. The hex dump was created with

hexdump -e'"%07.8_ad " 8/1 "%03d " " " 8/1 "%03d " " |"' -e'16/1 "%_p" "|\n"' RestartClock

on the Mac. It took me only about 5 passes of double checking them all after the initial entry. And boy, had I forgotten how slow and unwieldy AmigaBASIC is! I figure that the roundabout two hours I spent on this were evenly split between reading up on the Amiga BASIC syntax and functions, finding and fixing mistakes in the hex dump, and waiting for the painfully slow scrolling in listing window. That’s why with my original Amiga back in the day I gave up on the thing, as I recalled. If memory serves, I moved on to "GFA Basic" back then, which I remember as way more responsive.

Anyway, when run, the program reads the bytes from the data area one by one, and adds them to a new file in the RAM disk, outputting some progress along the way. You can see how long that takes for a mere 400 bytes. The first attempts were way slower still, because they contained more on-screen output.

I crossed my fingers and ran the newly created command in a shell:

It looked promising, so I then set the date and time in Preferences, saved, and powered off the computer for a good 2 minutes. I then booted into Workbench again, and what do you know:

It worked! I was lucky enough to have a Workbench disk "fresh" enough to not barf at the year 2018. Evidently there are different versions of software and hardware around, exhibiting different more or less annoying bugs related to date and time. I found this “Workbench (Issue 139) [PDF]” magazine from 1998 which has few interesting details on this.

Final Remarks

I certainly could have waited for the new RS232-USB-dongle (which has arrived by now, of course). But I really wanted to solve this right then and there, and in retrospect I am glad I did. The whole procedure reminded me, how something that seems trivial – especially by today’s standards – can require some creative thinking. Still, I wouldn't want to go back to regularly transcribing pages and pages of listings from magazines anymore.

Should you go through the same procedure, I highly recommend saving the generated RestartClock program on the Workbench disk (or somewhere other than just RAM disk). When I had to disconnect the battery from the A501 again for some other repairs, the clock was corrupted and needed to be restarted. At that point I was very happy not to have to go through the hex-dump again 😁.

Amiga 500 Restoration: Retrobrighting I

2018-01-05T00:21:00.001+01:00

In part one I described how I got and disassembled an Amiga 500 for a thorough cleaning. This part is about my first attempts to restore the grey/beige color the case had originally had, but over time had turned it an ugly yellow.

This is the second post in a series about restoring an Amiga 500 back to its former glory. Here are all of them so far. I’ll try to remember to update this in all related entry.

2017-12-24: Amiga 500 Restoration
2018-01-05: Retrobrighting I
2018-02-05: A501 Memory Expansion
2018-02-05: Mouse and Mainboard Maintenance

First Things First

Disclaimer 1: It has been quite a while since my chemistry lessons in school, and even though reading up on the details, combined with what I still remember, left me with some confidence of having roughly understood what’s going on, what follows might be woefully wrong, at is guaranteed to be imprecise. So by no means should you use this as the basis for any upcoming exams 😉. Also, I understand the links provided are not scientific publications, so they themselves might be wrong. If you know better (and can point me to the resources to prove it), I would be happy to hear from you.

Disclaimer 2: Hydrogen-peroxide and products based on it need to be handled with great care. Always wear rubber gloves and, even more important, protective glasses when handling it. I know this might sound like an exaggeration, but I am serious: H₂O₂ is acidic! Getting it on your skin will cause discoloration and burns. Here’s a picture of my arm where some of the stuff got stuck without me noticing.

After what could only have been a very few minutes, I felt a stinging pain and could see two burnt spots. It took quite a while for the pain to subside even after washing off the peroxide. It goes through your skin and starts to make gas bubbles underneath. So if by accident you get some on your skin, quickly rinse if off with clear water!

Getting this stuff in your eyes can cause irreparable damage and even blindness! You have been warned!

Why does plastic turn yellow?

There are quite a few theories out there why the plastic many older electronic devices — including the Amiga — were made of turn yellow over time. Not all of them do, some keep their color well, while others look quite grotesque. The one I bought from eBay looked like this when I got it (and yes, the photo is rather close to what it looked like in person).

As far as I could figure it out, external influences like heat and UV light gradually break up molecular bonds in the polymers comprising the plastic, leaving free radicals. The presence of bromide flame retardants, often cited as the main culprit, may or may not play a role in this process, but if my layman’s reading of this paper is correct, plastic can change its color regardless. In any case, the changed molecular structure changes the physical properties in several ways. For one, the material can become more brittle, but also, the wavelengths of the light it reflects shift. It seems, free radicals like yellow best, so that’s what they tend to reflect most 😉 (and yes, that smiley is there on purpose).

Fortunately, these chemicals processes can apparently be at least partially reversed by re-adding hydrogen for the free radicals to bond with. Unfortunately just soaking the plastic in water won’t help, because the hydrogen in water is very happily bonded (with oxygen) already. It’s not as simple as one might expect, but in the end, there are always two hydrogen atoms, and one oxygen atom, sticking together; hence: H₂O). What's needed is “bachelor” hydrogen, ready to enter a bond with the yellow-loving free radicals.

A rather cheap transport vessel for extra hydrogen is hydrogen-peroxide (H₂O₂). While it looks similar to regular water, it is less stable and — if pure — usually decomposes into regular water over time. Given the chance, however, the additional hydrogen may also decide to connect with the free radicals in the plastic, bringing it closer to its original structure, and thereby color.

So put in very simple terms, getting plastic de-yellowed should work by just soaking it in hydrogen-peroxide, ideally adding some energy to encourage the chemical to split off the extra hydrogen to facilitate the reaction.

A Bucket full of H₂O₂?

Turns out, an Amiga’s case is surprisingly big, meaning that if I wanted to submerge it in hydrogen-peroxide, I would need a large enough container to put the top and bottom cases in, and also quit a bit of hydrogen-peroxide. This would be the ideal solution, because it would ensure the whole surface being in contact with the chemical, hopefully leading to a very even discoloration.

It certainly can be done (see this video on YouTube), but for my first attempts it didn’t seem very practical. Not only did I not have a suitable container at hand, but (in contrast to The 8-Bit Guy whose video it is) I also don’t live in Texas with an abundance of sunlight. Instead, live in somewhat cloudy Germany. Trying this shortly before Christmas also wasn’t exactly the ideal time of the year in terms of daylight hours.

So I postponed the liquid hydrogen-peroxide plan for a little while.

First tests: Bleaching the power supply with a standard hair bleaching product

I decided to perform the first bleaching experiments on a test object that is typically not the focus of a lot of attention: The power brick. I figured that if something went wrong and the results weren’t good, it would be the part I would least be annoyed by if it didn’t look perfect. It’s usually hidden under the table anyway.

So first of all, I took it apart (turns out, it was quite dirty on the inside, so it was also a welcome chance to clean it) to get the plastic parts ready.

The underside was considerably less yellow than the top, supporting the theory that exposure to light (or lack thereof) plays an important role in the chemical reactions described above.

I bought the strongest hair bleaching product I could find in a local store. Even though the brick would have fit in a large pot and could have been submerged, I decided to try out this equivalent of the “Salon Creme” used in the 8-Bit Guy video.

I don’t have the packaging anymore, but as far as I remember it did not specify the exact concentration of hydrogen-peroxide anyway. I figured that even the strongest one would probably not exceed the product shown in the video. I was a little concerned, because the list of ingredients contained some additional stuff, including ammonia, perfume and others, but that’s exactly why I picked the power supply as a “guinea pig”. One box of this product sells for around 3€ or 4€ , so it wasn’t a big investment either.

I mixed the ingredients as per the instructions, producing a white creme that didn’t even smell too bad. I then laid out the case parts on plastic wrap and started applying the creme generously. Once done, I wrapped the plastic film around to prevent the mixture from drying out.

For the very first attempt, I just let it sit over night, without any light or heat added. I wanted to find out, how much of a reaction I would get without any additional energy. After about 12 hours I unwrapped and rinsed both parts to see… nothing. At least there was no obviously discernible difference between before and after. I won’t rule out that letting this sit for much longer would have produced some change, but I was not patient enough to try. So instead, I repeated the whole thing the next day — with a fresh batch of the white creme.

This time, once both parts were covered and wrapped, I put them into the oven, heated to around 50°C. I deemed this a safe temperature, because I figured a power supply could reach it by itself on a summer day. Apparently my oven is not designed to maintain such a low temperature constantly. I had put in a thermometer next to the plastic parts. Turns out, the actual temperature and the one displayed by the oven itself were quite different. It only reached 50°C on average when the knob was dialed to around 65°C, oscillating by about 10°C in either direction.

The part in the middle is the trapdoor cover for the memory expansion port. It was put in for comparison. It showed almost no yellowing in the first place, and I wanted to see what effect the bleaching would have on original color plastic.

I left it in there for a few hours, regularly checking the temperature and looking for obvious changes. Very quickly the creme increased in volume, getting foamy — similar to shaving foam. Over time, bigger gas bubbles formed. After about 4 hours the bubbles started to disappear. It looked as if the remainder of the creme was beginning to dry out, turning into a something I can only describe as “crisp looking". At that point I decided to take the parts out of the oven.

Even through the plastic film, I could feel that the creme had indeed begun to turn into tiny crystals. I assume, the plastic wrap was not a good enough seal against the constant stream of warm air. So the water in there eventually evaporated. It’s not easy to see in the photos, but I tried highlighting the effect:

I rinsed everything with warm water, using a brush to remove all sticky residue.

(Alert readers might have noticed that I am not wearing gloves here. This is because I had forgotten to take a photo earlier and posed again, but only after having thrown the gloves away already).

Even before the parts had completely dried, the effect was already obvious. I had put a small piece of scotch tape on the side of one of the pieces to make the before-and-after comparison easier.

So the bleaching had obviously worked, which can be seen even better in the next photo, with the mouse as a reference. However, the creme drying out had the ugly side effect of getting an uneven, quite blotchy overall appearance.

Lessons learned (so far)

After the two attempts with the hair bleaching creme, I came to the following conclusions:

There is obviously enough hydrogen-peroxide in the cheap hair product to counteract the yellowing.
Additional energy is needed to achieve an effect in a more reasonable amount of time.
UV light is not the only source of said energy — moderate heat works, too.
Letting the hair creme dry produces crystalline particles. That causes ugly spots and an overall uneven result. Some of that might also be attributed to uneven application of the creme.
The trap door cover hardly changed at all, so the effect on “original” color plastic appears negligible.

In general I'd call this first try a partial success, but there is clearly room for improvement. It was a good idea not to start top case right away. I would have considered a result like this a degradation, not an improvement. So more experimentation was needed. I decided the hair bleaching product was not very well suited for my needs. I don’t know if the same would happen with the all such products, but at least this one's formula seems to produce the dry crystals.

Bleaching the mouse — A bucket pan full of H₂O₂!

I decided to let the power supply alone for the time being. Instead I replicated the 8-Bit Guy’s setup with liquid hydrogen-peroxide solution on the stove top to “cook” the key caps and the mouse, which I had taken apart and cleaned in the meantime, too.

Some googling suggested hat hydrogen-peroxide solution could be bought in pharmacies in concentrations between 3% and 30%. Apparently most of the stronger hair bleaching products contain around 12%.

I went to three different pharmacies. In the first two, without only very vague explanations, they offered maximum concentrations of 3% and 6% respectively. Only in the third one did they explain to me, that around the beginning of 2017 there was a change in regulations, requiring sellers to document who bought the stuff and for what purpose, for anything 12% and higher. To avoid the paper work, most pharmacies just stopped selling these concentrations to anyone but business customers. I have no idea why they didn’t just tell me in the first two, but even if they had had it on sale, the prices would have ranged somewhere between outrageous and ridiculous (30€ per liter, at 6%)!

Fortunately I found an online shop that conveniently offered a “six-pack” of 1 liter bottles of 11,9% 😏 H₂O₂ solution for a very reasonable total price of 20€, including shipping.

I decided to start with the mouse, using the same temperature as for the power brick, just this time completely submerging the plastic in the solution on the stove top.

Controlling the temperature turned out to be even more challenging. To prevent the solution (and the plastic along with it) from overheating, I had to turn the stove to its lowest setting and move the pot way off-centre, so that only a small portion of it was actually receiving any heat from below.

With this arrangement — the extractor hood above set to full, and the kitchen window wide open — I waited, checking the temperature and the plastic color regularly. After the first hour, virtually nothing had happened, but little bubbles forming. However, by the time about two and a half hours had passed, the yellowing started to disappear visibly.

After 4 hours the plastic had changed its color enough for me to consider it “original” again, so I turned off the stove and took the mouse out of the hot liquid with some pliers. I rinsed all parts with lots of warm water.

Finally, see this before and after comparison. The first picture was taken right before the procedure began, second one right after rinsing. There is some moisture left between the mouse buttons, so it looks a little darker there in the photo — it actually isn’t.

The improvement was pretty exciting and got it very close to what I would consider original color. Turns out, though, that even after taking the parts out of the solution, rinsing and drying, the bleaching reaction did not stop immediately. When i looked the next morning, the mouse had become quite a bit lighter still, even lighter than ideally I would have wanted. It does not look bad, it is just not as beige as the Amiga originally was:

More lessons learned

With the mouse done, here are a few more take aways:

The submersion method yields very even effects — just as expected.
Pick as small a pot as you can — you’ll need less liquid to cover the parts.
You want really good ventilation. Standing right next to the pot for a while made my eyes burn. My wife complained about her throat getting sore.
Controlling the temperature is not trivial. This is a consequence of the small amount of liquid and the comparatively low desired temperature (in contrast to what the stove is designed for: cook food) Hence, a thermometer is a must have.
The bleaching continues for quite a bit, even when the plastic is taken out of the solution. Factor that in and take parts out sooner rather than later.
Don’t reach into the hot solution with your fingers 😉
Rinse off with warm, not cold, water. I am not sure this is really necessary, but I figured it would be better than exposing the plastic to a temperature shock.

Armed with this new knowledge, I was confident it would also work for the key caps.

Bleaching the key caps

As laid out in part one, the key caps had already undergone a session of soaking and scrubbing in warm soap water. So they were ready for their bleaching bath.

The setup was exactly the same as for the mouse. Just enough hydrogen-peroxide solution to cover them all. However, due their shape and size, the key caps tended to float, so at least those closer to the surface were not fully covered all the time. To ensure they would still get the most even treatment possible, I used kitchen pliers to turn them all upside down.

Notice that I removed the metal braces from the larger keys — I did not want to risk corroding them. Some keys would turn around on their own, especially with the little bubbles forming, so I needed to slightly shake the the pot every once in a while to get rid of them and then ensure all caps were face-down again.

With the experience gained from bleaching the mouse I took the keys out about 45 minutes earlier, after just a little more than three hours.

In the pictures you can clearly see the special keys having a nice contrast with the letters and numbers. Here are the before-and-after shots, In the top right corner you see the floppy drive eject button, which I threw in, too.

Interestingly, similar to what I observed with the trap door bay, plastic parts that did not suffer from yellowing before did not seem as receptive to the bleach. You can clearly see this in this detail shot of the space bar.

I let everything dry on a cloth over night, before putting the caps back into the keyboard. There are only very few things to look out for when doing this. First of all, remember that there are two special (smaller) springs that go under the space bar, in addition to the center one which is the same size all others.

When putting back the metal braces under the larger keys, I noticed that they would not move as easily as before. This is because the bath in the soap water had washed away the grease that makes sure there is no noticeable friction. So I added some synthetic fat to lubricate the points where the braces a hooked into the white receptacles under the keys. For this I used the stuff that came with my coffee machine, because it does not damage plastic over time. WD-40 would not be well suited here. If you go through this procedure, make sure you use such a non-aggressive lubricant.

Lastly, just as some keys had takes more force to pry off the keyboard base plate, some also took more pressure to go back in. At first I thought be springs were not equally sized after all, when I saw several keys stand out about 2 millimeters higher than their neighbors. But pushing them down just a little more decidedly made them audibly click back into place.

I started with the larger keys, because that way you have enough room to work with the metal braces. When all keys were back in place, I put they keyboard back into the case to see how it looked. At that two things became very obvious: First, even though they had spent almost an hour less in the solution than the mouse, the “after-bleaching” was still significant. The regular keys had become almost white, with the contrast to the darker keys significantly less pronounced. But more importantly, it was now very clear that I would now have to come up with a good way to treat the top and bottom case parts 😯.

A report of how that went will have to wait until next time 🙂.

Amiga 500 Restoration

2017-12-24T10:13:00.002+01:00

About 6 weeks ago I got the somewhat crazy idea to — just for fun — play some Amiga games. At first, my plan was to set up a Raspberry Pi 3 with an Amiga emulator, after stumbling across Dan Wood’s YouTube channel. Even though I even have a Pi 3 lying around unused at the moment, seeing Dan holding that Amiga 500 in his hands at the beginning of the video, I got all nostalgic and decided I could at least do a quick ebay search to see how much they go for these days.

Turns out, I could get my hands on one, including a memory expansion card, mouse and power brick (and a brick it is!) for just 60€. Turns out, I would end up spending quite a bit more in the end, but still it was (and still is) a fun experience.

The whole story is probably way too long for a single post, so I may end up splitting this into at least two parts, but I feel it is necessary to write this down if only to remind myself about it in the future :-)

This is the first post in a series about restoring an Amiga 500 back to its former glory. Here are all of them so far. I’ll try to remember to update this in all related entry.

2017-12-24: Amiga 500 Restoration
2018-01-05: Retrobrighting I
2018-02-05: A501 Memory Expansion
2018-02-05: Mouse and Mainboard Maintenance

The Amiga 500

There’s quite a few Amigas on ebay, especially 500s. Considering they were the cheapest and thereby most common model, that makes sense. I god hold of one for 60€ plus shipping. I could have gotten one in better condition for more money, but I wanted something to try the technique of retrobrighting on, so I was just fine with the yellowed case.

It arrived in a big box with lots of packing paper, covering the mouse, the power brick and the Amiga itself, plus some cable I couldn’t immediately identify. Only later did I remember it is an RGB video cable. I also did not remember the power brick to be so heavy. It was equally yellowed.

The picture above was taken under fluorescent light, so the color representation is not exactly accurate. The next photo was taken in daylight on an overcast winter day, with a white sheet of paper for reference. I then used Photos.app on the Mac to set the white point to that paper. This allows a better side-by-side comparison later.

Having neither a suitable Amiga monitor like the venerable Commodore 1084S, nor an adapter cable to hook the machine up to my Panasonic plasma TV via the SCART connector, I could only do a very superficial health check. I hooked the computer up to power and turned it on. After about three seconds the power LED hat come up to full brightness, and the disk drive began its expected regular soft clicking every two seconds or so, looking for a 3.5” floppy. So the machine seemed healthy for the moment.

Cleaning inside and out

While the yellowed case is a consequence of age and UV exposure and cannot be removed superficially, there was also quite a bit of dirt and grime on the case, the keyboard, the mouse and the power brick. So I decided to take everything apart and give it a thorough cleaning. What follows are the steps to disassemble and clean everything.

Taking off the top case

The top case can easily be removed by unscrewing 6 screws on the underside. On some Amigas these may be Philips heads, but the more common variant seems to be with Torx screw heads. With a little care you can open them with a flat head screw driver, without damaging the screws. If you have the appropriate Torx screw driver, even better, of course.

On left and right side there are plastic clips on the inside, holding the top and bottom case together. Be careful when taking off the top part, because they are easy to break. Carefully wiggle the top case left and right to get one of them to slip out.

Once open, you have the keyboard and the RF shield in front of you. Be very gentle when handling the top case. Even though is won’t break apart too easily, due to the big holes for the keyboards, it lacks a bit of structural integrity unless handled by holding it on the more massive part where the ventilation slits are. Also take care to put it down gently and on soft undergrounds. I learned the hard way and chipped the two rear corners when trying to lean it against a wall and hit the ground at a bad angle.

Removing the Keyboard

To clean the keyboard, I recommend first removing it from the case. It has to come out for the later steps anyway. To do so, disconnect the cable from the motherboard by pulling it straight up through the hole in the shield. It should be rather safe to pull on the cable — the connector isn’t that tight on the board, and trying to get your fingers or some tool through the hole is probably a bigger risk of damaging something.

Don’t worry, the cable is keyed, so you don’t have to write down the orientation: Looking at it from above, there are 4 wires on the left, and 3 on the right, separated by an empty slot. The connector on the board has a missing pin there, too, so it is easy to reattach later.

Once the cable is free, you can slide the keyboard slightly from under the plastic latches at the very front of the machine. Then just lift it up. Notice the small spongy tape pieces between the keyboard metal base plate and the plastic latches. Depending on the age and condition of the Amiga, those might come off. In my case, the outer two stayed in place, the middle latches didn’t have any. I am not sure, if there used to be four. If they detach, I recommend replacing them, because I suppose they are intended to keep the keyboard more silent and as a strain relief for the plastic latches.

On right hand side, just beneath the power / drive LEDs, the keyboard rests on a similar little sponge. This one came right off when I lifted the keyboard up. This one, too, should be replaced, even though, of course, none of them are exactly mission critical. I did that with two layers of Powerstrips, leaving the protective tape on on the upper side.

Please note, that I only applied this at the very end of the restoration process, because in the meantime the Amiga casing underwent several other steps, which would have removed or at least damaged that new cushion.

When putting the keyboard back in later, carefully slide it back under the front latches. The metal base plate has a notch indicating the middle. Align that with the screw hole in the bottom case.

Removing the Key Caps

Lots of grime and dirt accumulates on and especially under the keys. To clean the keyboard thoroughly, the caps must be removed. The regular sized keys (including the F-Keys, Del, Help and Ctrl) can be taken off more easily than the larger ones (Return, Shift, the Spacebar, etc). You will often find people recommending to use a flat head screw driver to slide under a key cap, using it as a lever to pop the key off. While this works, I do not recommend it. The reason is that screw drivers are metal, and the key caps are 30 year old plastic, which got somewhat brittled over time. I learned the hard way that you cannot always tell how much force you can apply, before something breaks. This meant I had to repair a cracked “J” key (Super glue from the inside of the key was used to put the broken piece back in place. Once it had dried, two additional layers of flexible glue were added to increase stability).

What I found worked way better than metal were wooden skewers. They are flexible and tend to break when you apply too much pressure. I managed to get all remaining keys off without any more damage using this method.

This picture shows the the little hill each key rests on, as it stands above the plastic base. Having that before beginning would have helped a lot to understand where to apply force, so I’ll post this here for posterity. To get a key off, I tried to get two skewers underneath as shown by the parallel lines, and then to gently lift them upwards a little bit one at a time, alternating between the two. Most keys came of after just a few nudges. Be patient, they will eventually come loose. Some particularly stubborn ones took a few broken skewers. If they don’t seem to move at all, try to put a skewer close to the middle and carefully lift there. The thing that I found to be most important was to get the skewers to rest on the elevated part.

Underneath each of the regular sized keys, there is one metal spring. Be careful not to lose any, they make the keys come back up while typing. I placed them in a bin with a lid for safekeeping.

The bigger keys are a little more difficult to remove. They have metal braces underneath them to give them more stability and prevent wobbling. They can be popped off using the skewers, too, but you cannot just lift them off the keyboard afterwards. Instead, the braces need to be carefully removed either from the black plastic keyboard base, of from the key cap themselves.

I went for what I now consider the worse option and unclipped them from the base plate. In retrospect I think this is too risky, because for once at least some of them were really hard to get unclipped and you risk breaking off pieces of the assembly. Second, because you must be very gentle and not bend the braces. So if I were to do this again, I would use tweezers and unhook them from the underside of the key caps, which might be a little more fiddly, but requires much less force.

The pictures show the braces for the Return key, and where they are attached to the base plate, and on the underside of the key.

The space bar has three springs. Notice that the middle one is the same size as all the other keys, but those on the left and right of it are slightly shorter. This is important when reassembling the keyboard later.

Cleaning the Keyboard Base Plate

Once all the keys were taken off, this is what my keyboard base plate looked like. All in all not too gross, mostly lost of dust and some sticky stuff.

The first round of cleaning was just a brush and a handheld vacuum cleaner. This got rid of most of the dust and loose dirt. In my case, there was nothing left on the keyboard that could have been sucked into the vacuum, so I was not all to careful when doing this. If you leave the metal braces on there, make sure those are not ripped off.

Finally I used paper towels and warm water to remove everything that more sticky, and finally went around all the key domes and the nooks and crannies of the metal brace holders with isopropyl alcohol and cotton swabs. The end result looked like this:

Cleaning the Keyboard Caps

There was no glory in cleaning the key caps. They very unceremoniously were all dropped into a small bucket with warm water and some dish cleaning liquid to soak for a few minutes. After that came the laborious manual part, rubbing them with a kitchen sponge. Make sure to only use the soft parts of the sponge, should yours have a more scratchy side. That one would most probably leave visible marks in the otherwise very smooth plastic.

Some of the key caps had some nasty stuff stuck on the bottom side, which I had to remove with a tooth pick. The whole cleaning easily lasted for 30 minutes, because I wanted to make sure all sides of the keys were thoroughly cleaned in preparation for bleaching them later. The photo above shows how much the keys had yellowed, especially when you look at the space bar. You can clearly make out where the adjacent keys had kept light away from the side of it. Their shape is clearly visible in the “whiter” parts. Well will come back to this later.

Cleaning the RF shield

With the keyboard out, the RF shield is the most visible part now. I gave it the same treatment with brush and vacuum cleaner from the outside, including the space between it and the bottom case. This removed most of the dirt already. Then, with it still in the case, I wiped it off with a moistened paper towel and some glass cleaner. The dark spots seen in the photo are rust, so they can't be removed easily.

Removing the RF shield

The get to the mainboard, next I removed the RF shield from the case. It is attached to the bottom case just a few screws that are easy to get to. On the left, there is a separate metal bracket across the expansion port. I carefully removed that, too, and put it away to prevent it from getting bent.

To actually take the shield out, a series of small metal latches need to be bent upwards. They connect the metal tray the mainboard sits on with the RF shield. I just followed the edges of the RF shield and carefully bent them upwards with a flat head screwdriver.

Once they are all bent up, the shield came off with a little wiggling. Once out of the case, the shield is rather wobbly and should be put away safely to prevent accidental bending and deformation.

Cleaning the mainboard

With the RF shield out, the mainboard lay before me, with fond memories from the 80s… and with lots of dirt, potentially also from the 80s…

Again, this was cleaned with a brush and the handheld vacuum cleaner. Even though with the perspective in the photo does not really show it, I took particular care to not get the vacuum too close to the board, because I did not want to risk it ripping anything off the board (even though it was set to low power), and also to prevent too much electrostatic buildup.

It took a while, but I was pleased with the result.

Somewhere along the way I removed the floppy drive, because it covered part of the board.

Removing the mainboard

With the mainboard now clean, I removed it from the case, too, to be able to clean the bottom case. The board sits on a metal tray, which makes removal quite simple. The only thing to be careful about is to pull the board a little forward to get the external connectors free from their openings in the back wall of the plastic case. Once they are clear, the whole tray can be taken out. I also took the mainboard out of the tray for a moment, to be able to clean out the dust from underneath it. Once that was done, I put it back immediately, because it serves as a good protection for the bottom side of the board.

Cleaning the case parts

With everything removed from the case, I scrubbed the top and bottom cases with warm water, soap, an old toothbrush, paper towels, isopropyl alcohol, and microfibre cloths. Only for a very few stubborn spots I had to rub a little harder with some mild abrasive. That’s the white stuff you can see on one of the photos. Once done, I rinsed everything off in the shower and let it dry over night. While there are pictures of the dirty state, for some reason I did not think of documenting the finished cleaned state 🤨

At this point, I could have have just reassembled everything in reverse order, and frankly, that would have been a much better state than before. However, there were a few more things I had in mind. But those will be the topic of another post.

DevOpsCon 2015: Interview

2015-09-01T17:34:00.000+02:00

Interview mit Lukas und mir auf der DevOpsCon 2015 in Berlin, kurz nach dem Talk über Private Cloud mit OpenSource.

FrOSCon 10: Private Cloud mit OpenSource

2015-09-01T17:29:00.001+02:00

Auf der FrOSCon 10 in St. Augustin habe ich kürzlich ein Update zu unseren Erfahrungen mit dem Thema "Private Cloud mit OpenSource" gegeben. Leider sind noch nicht alle Probleme, über die letztes Jahr berichtet wurde, behoben, aber wir sind schon ein gutes Stück weiter und haben neue Stolperfallen gefunden und z. T. auch überwunden.

Leider habe ich mich mit der Zeit ein wenig getäuscht, da ich den Talk vorher schon einmal in gekürzter Form in 40 Minuten unterbringen musste, aber in der Präsentation den Countdown für die FrOSCon wieder auf 60 Minuten zu stellen vergessen hatte. Zwischenzeitlich war ich deswegen der Meinung, ziemlich hinterherzuhängen... Hoffe, es macht trotzdem ein bisschen Spaß, so blieb am Ende mehr Zeit für Fragen und Gespräche :)

Hier noch die Folien auf Slideshare:

Private Cloud mit Ceph und OpenStack from Daniel Schneller

True KVM Live Migration with OpenStack Icehouse and Ceph based VM storage

2015-03-16T10:29:00.000+01:00

Over on the codecentric blog I just published a new post on True KVM Live Migration with OpenStack Icehouse and Ceph based VM storage, outlining the process it took me to get this actually working. There were several issues to work around, some of them bugs in OpenStack, some of them home-grown issues.

I provide a few patches to OpenStack classes as well as a description of what is actually going wrong and how to circumvent the problems. So head right over and have fun reading :)

Ceph Storage Cluster

2014-12-01T00:35:00.000+01:00

At Data2Day 2014 in Karlsruhe I talked about the Ceph Storage Cluster and us using it to store documents in CenterDevice. These are the slides (German) I used. If you are interested in Ceph and/or look for help implementing it, don't hesitate to contact me.

Ceph Object Store from Daniel Schneller

Localizing Mobile Apps

2014-08-28T14:39:00.001+02:00

What do the acronyms I18N or L10N stand for? What do they mean for developers of mobile applications in particular?

I hosted a session about localizing mobile applications at Developer Week 2014 in Nuremberg. It covers — among other things — text, numbers, date and time, images, and other localizable resources.

See the codecentric blog for slides and some more details.

The post and the slides are also available in German.

Jinja2 for better Ansible playbooks and templates

2014-08-25T19:47:00.000+02:00

Another post on Ansible over on the codecentric blog: Jinja2 for better Ansible playbooks and templates linked here for your convenience :)

Ansible: Simple, yet powerful automation

2014-06-23T17:43:00.000+02:00

On the company blog I published a post about our experience with Ansible today.

It is no shoot out between different automation tools, but rather a collection of Ansible basics and our experience with it so far. Soon another post will follow about dynamically generated inventories for OpenStack virtual environments.

You can find it here: codecentric blog: Ansible: Simple, yet powerful automation.

SSH Two-Factor Authentication with Duo Security

2014-03-10T09:50:00.001+01:00

Over on the codecentric blog I published an article on SSH Two-Factor Authentication with Duo Security. You are welcome to check it out.

iPhone 5 display replacement

2013-11-15T08:58:00.000+01:00

The problem

About two weeks ago I noticed my iPhone 5 had a faint, but ugly pink hue in the center of the screen. At first I suspected some software issue, because it looked as if the hue was exactly in the area an iOS7 table view uses for its cells to be displayed (i. e. full screen, but with a few points of inset on the left and right edges). Apparently someone must have left some kind of view with a red-ish color behind the table view that was now shining through, because of all the translucency effects iOS7 comes with.

Turns out though, that this was going on in all kinds of apps, including Instapaper, Pocket, Chrome, Safari Calendar etc. All those certainly would not put any views behind the actual content. Getting more suspicious I showed the problem to several colleagues who all did not see it at first, but once I had pointed it out to them (most visible on a white background) none of them could "unsee" it, either.

Warranty Check

I checked the warranty status online using Apple's Self-Solve Page and realized that I was the second-to-last day of the 1-year warranty for the device.

First order of business was to go to a nearby Authorized Apple Partner to ask for a warranty replacement or repair. Though upon comparison with the manager's iPhone 5 he could see that he had the same issue (now also not being able to unsee it, you are welcome ;)), he said that it would be easier for me (no time without a phone) if I contacted Apple while within the warranty period.

So I followed the advice and called AppleCare the next day. The representative on the phone suggested to visit a nearby Apple Retail Store if I would like a replacement unit or immediate repair, if I didn't mind driving there (about 50km from where I live). Because the problem had been reported while within the first year, it would be ok if they did not have an appointment right that day.

So next thing I did was make an appointment for the Genius bar the the Apple Store CentrO which was exactly one week past the original warranty.

Genius Bar

Arriving there at the bar, the Genius could immediately confirm the color issue and started checking out my warranty status. From there the — what I thought would be a 20 minute procedure — journey began.

Because the Apple Care agent I had called a week ago had apparently forgot to change my warranty status (their term, no idea what it exactly means), they could not offer me a free exchange or repair. So I had to call Apple Care yet again to have them do that. Anyone who has had contact with them knows, that this will take a while. While I was on the phone my Genius finished his working day and handed my case over to a colleague.

After about 10 minutes waiting I got someone whom I told about the story again and asked him to fix the warranty status for the colleagues at the store to see. He told me he was not authorized to do so, but would now check with his supervisor. After another 15 minutes of waiting he was back, telling me all would be good and that he would now pass me on the supervisor.

She — a nice lady this time — told me she would not extend my warranty for 7 days, enough to cover me for this appointment at the store, to that they would be able to offer a free exchange or repair. According to her, the store employees would be able to see the change immediately, having access to the same database. She also left me with her email address and phone number, so I could contact her directly should anything be left clear or to just provide some quick feedback once my problem had been resolved.

Back to my Genius — who was apologizing for the long wait I had already had so far — he could not see the change to the warranty status yet. After refreshing my case file in his app, he finally said he would now proceed on his own authority to not keep me waiting much longer. I was already expecting to be able to leave really soon™, because I was expected elsewhere.

However, once I had taken my phone out of its case, he put it into a bag and said that because it was a screen related issue, they would now replace the screen. He would make sure that I got an expedited repair and that the guys backstage would hurry, but he could not make it much shorter than another 45 to 60 minutes of waiting. So much for my dinner plans with the wife… Instead I went to Starbucks first and then spent some 30 minutes playing with iPads and MacBooks in the store.

Finally, after what totalled to about 2 and a quarter hours, I had my phone back, with a new screen and without the pink tint.

While in the end everything turned out satisfactorily for me, I must say that there is room for improvement here (which I also sent by email to the 2nd level support agent)...

Lesson learned

Whenever contacting Apple Care close to the end of the warranty period, make sure to have them immediately extend your coverage for a week or so to give you time to get an appointment at the Genius Bar. Had I known that before, the whole procedure would probably have taken not longer than an hour, including the repair.

One more thing

PS: Is it just me, or is the waiting music on the AppleCare hotline just horribly bad quality? Seems whenever the music got quieter, it was more or less replaced with all static and garbled sound. Had the voice quality not been great before, I could have believed the connection failed somehow.

Update: See AppleInsider for an update regarding the music quality :)

Pseudolocalization for Cocoa Apps

2013-10-24T18:01:00.001+02:00

Over on the codecentric blog I published an article about localizing iOS and OS X applications called "Pseudolocalization for Cocoa Apps". It is probably the first of a few, because it turned out rather long already.

Coding Serbia: iOS for Java Devs

2013-10-24T17:54:00.000+02:00

At the first ever CodingSerbia conference in Novi Sad, Serbia, I did an introductory talk about how iOS development works in general, with a focus on Java developers who did not have any experience with either the tools, frameworks or even Objective-C as a language.

The slides can be viewed here:

A recording has been made and published on YouTube:

Man in the Middle? - No, thank you!

2013-06-28T18:29:00.000+02:00

After speaking about the topic the Developer Week 2013 in Nürnberg this week, due to some scheduling coincide I repeated it today for our codecentric "Dev-Friday" in which internal or external speakers present some topic to the whole company.

For a while we have been recording these for colleagues on vacation or otherwise occupied during the talk to watch it later. Several of them are available on codecentric's YouTube channel publicly. As of a few moments ago, so is my "Man in the Middle? – No, thank you!" talk on the possibility of – and countermeasures against – man in the middle attacks against SSL connections.

For your convenience, here is the video:

The slides can be found on Slideshare, the iOS sample application is on my GitHub page.

Feedback is welcome and appreciated.

Time Machine password not working?

2013-02-26T01:15:00.000+01:00

I have been meaning to write this down for quite some time, but it always eluded me. When you are using Time Machine to back up your Mac, you get the chance of password-protecting your backups.

Whenever the machine is restarted you will have to unlock the disk by entering the password, unless you store the password for the backup disk in your keychain. For paranoia's sake (and to keep the password fresh in my memory, just in case) I do not store the password in the keychain.

Now, what happens quite regularly to me is this: I reboot the machine for some reason or other, and while it is doing that, I leave the room and do something else. Before I know it, maybe an hour has passed before I come back. In the meantime, the external Time Machine drive has gone to sleep, because it was not used for an extended period of time. On the screen, there is the password dialog dutifully waiting for me to unlock the protected volume.

As soon as I do so (being very sure the password I type is correct) I hear the external drive spin up again. Because I use a dual-drive RAID enclosure it takes a bit longer to get ready than most drives, because it powers up the drives with a slight delay to go easy on the power supply. All in all I estimate it takes about 10 seconds before the drive is ready. This, however, seems to be longer than the OS is willing to wait for the drive to report back, making it believe that the password was wrong. It will ask for the password again and again, and no matter how often you make sure you typed it correctly, there is no chance of convincing it to accept it.

When this first happened to me, I was getting a little panicky, because I thought that either I was losing my mind, not remembering the very same password I had been entering for months, or that something might be wrong with the drive. Turns out, everything is fine, the drive is mounted with the first attempt, it is just the dialog that remains open and drives you crazy - which, of course, you will not realize if you have a bunch of windows open, preventing you from noticing the icon on the desktop. Watch this short video for of demonstration of what I am talking about:

As you can see, the backup volume is mounted and the dialog is still up. So if you run into the same situation, don't worry. Just cancel the dialog and the backup will run normally.

Artikel in JavaSPEKTRUM 03/12

2012-05-26T11:49:00.000+02:00

In Ausgabe 3/2012 der Fachzeitschrift JavaSPEKTRUM wurde kürzlich ein Artikel mit dem Titel "SOA-basierte NoSQL-Lösung im Mobile-Umfeld" veröffentlicht, dessen Co-Autor ich bin. Er beschreibt, wie eine mobile Java-Applikation mittels kreativer Ansätze und einem Mix aus moderner und altbewährter Technik zum Erfolg gebracht wurde.

Der Volltext kann entweder im Browser auf der codecentric Homepage unter der Rubrik Kompetenzen/Publikationen gelesen werden, steht aber auch als PDF zum Download bereit.

Removing Xcode 3 shared build settings from Xcode 4

2012-01-11T07:00:00.000+01:00

This is about me getting a substantial amount of grey hair over the past couple of days, trying to hunt down a setting that would cause the current version of Xcode 4 to build my iOS projects to an unexpected, but not unfamiliar, taken over from Xcode 3, location, but not presenting any obvious way to revert that.

A little history

In Xcode3 you could use the preferences dialog to configure custom build output folders. This was necessary when you wanted to organize a somewhat more complex software into several cross-referencing Xcode projects and at the same time retain some sanity when linking and packaging it. Clint Harris Tutorial on shared libraries describes it in more detail.

The preferences dialog looked like this (image copied from Clint’s site, because I didn’t have any Xcode3 installation lying around anymore):

In my venerable Xcode 3 setup I configured the shared build output to /Users/ds/Documents/cc/SharedBuildOutput.

Introducing Xcode 4

In March of 2011 Apple released Xcode4, a major overhaul of the IDE with many new features and, of course, new configuration. At the time of me writing this in January 2012 the latest Xcode release is 4.2.1 and I installed most releases as upgrades on my MacBook Pro. The settings dialog for build locations looks like this in my current installation:

As you can see, there is no trace of the previously configured shared build output setting, let alone my custom directory.
Ok, so apparently this is the new way of doing things, and starting with new projects will surely apply.

Not so quick…

Despite what (I for) one would expect, nevertheless, this is what a brand new (iOS) project’s actual build setting look like (I filtered to just show the relevant parts):

Switching from the Combined to the Levels view shows that the setting is clearly not coming from the project itself, which explains why even a freshly created project could know about this old folder:

This clearly goes against the current Xcode standard of placing build products into so-called “Derived Data” subfolder folders with (partly) random names. Build scripts can use these by referring to them using the environment variables, but more often than not, leaving the (now already) trodden path of the new defaults will cause more trouble than it’s usually worth.

“How do I fix this?”, you might ask. Well, that’s what I asked myself, too, and it took me a few days to finally figure it out. Remember that Xcode 4 no longer shows this path in its Build Locations preferences, so this is obviously not getting us any further.

Circumventing the problem…

Changing the folder at the project level works, overriding the default. As soon as you have created a new project, you can change the “Build projects path” and “Intermediate Build Files Path” to simply build. This should be the same value that’s the default in a fresh Xcode 4 installation.

I like to keep my build settings in a separate .xcconfig file that makes it easier to share and change settings with other project contributors using version control. If you do that, you could also use that to override the old default by putting these lines it it:

SYMROOT = build
OBJROOT = build

However, that, too, requires you to remember making the change for each and every new project. Surely it would be better to get rid of that now-unwanted setup.

…or solving it

Albeit there is no UI preference setting to modify the SYMROOT and OBJROOT settings in Xcode 4 anymore, apparently it still honors them from the previous Xcode 3 installation. So in order to reset them, we need to know where they are stored. I did not know anything more than that it must be a user-specific setting, because a newly created account did not use it. So – after deleting everything from ~/Library/Developer/Xcode/DerivedData – I tried (in this order):

$ grep -r SYMROOT ~/Library/Developer 2>/dev/null
$ grep -r SYMROOT ~/Library/Application\ Support/Developer 2>/dev/null
$ grep -r SYMROOT ~/Library/Preferences 2>/dev/null

Well, actually I tried searching for Documents/cc/SharedBuildOutput first, but that also matched several archived applications. The last command revealed this:

Binary file ./com.apple.dt.Xcode.plist matches

Converting the first match to XML with plutil -convert xml1 -o tmp.xml com.apple.dt.Xcode.plist and searching inside it I found this:

<key>IDEApplicationwideBuildSettings</key>
<dict>
    ...
    <key>SYMROOT</key>
    <string>/Users/ds/Documents/cc/SharedBuildOutput</string>
    ...
</dict>

Instead of removing these two lines and converting the file back to its binary format, I deleted that entry with the handy little PrefSetter application by navigating to the com.apple.dt.Xcode domain and searching for SYMROOT in there. That way there is no risk of making any typos, damaging the file.

Do not forget to save the change!

Success!

Restarting Xcode and looking at the build settings of the very same “Test” project created earlier proves that the change had the desired effect:

Of course, as a last resort (maybe there are more problems with your Xcode settings?), you could also just delete – or rename – the com.apple.dt.Xcode.plist file and have Xcode start afresh, even though I noticed when I tried this, that several settings were left unchanged, e. g. Source Trees. These are apparently stored somewhere else…

SOAP web services with iOS

2012-01-02T09:00:00.000+01:00

Fresh on the codecentric blog is my new post about using SOAP web services from an iOS client application.

It features a short comparison of the current state of frameworks and tools with the Java world, and then focusses on the sudzc open source library that takes a very interesting approach in generating web service client artifacts by transforming the service's WSDL into Objective-C classes using XSL transformations.

The post is available in German as well.

Why good metrics do not equal good quality

2011-10-17T21:43:00.000+02:00

A short while ago I posted an article on the codecentric blog about why good metrics can be, but need not be equal to good software quality. As I wrote earlier, I will add links to this blog whenever I post something of interest to the company site.

The post is available in both English and German at http://blog.codecentric.de/en/2011/10/why-good-metrics-values-do-not-equal-good-quality.

List all open Safari tabs across windows

2011-08-02T17:50:00.000+02:00

Over the course of a workday I tend to accumulate lots of browser windows, and even more tabs inside them. Up to now, I would often lose track of what which tabs were open in which window and in which space. In the end, I would often just open a page again in a new tab of the window I happened to be in at the moment, increasing the overall clutter.
With the advent of persistent application state across reboots or application restarts as well as fullscreen apps in Mac OS X Lion that situation has gotten even worse.

The "Window" menu in Safari does not help too much, because it only shows the tabs of the currently focussed window. Today, while wondering why a website was not displaying correctly, I accidentally found a remarkably simple (and built-in!) way of showing all open tabs across all open Safari windows.

Just hit Cmd-Alt-A or pick "Activity" from the Window menu in any Safari window to open or focus the Activity overlay window.

It is usually used to determine what servers different parts of any given website are loaded from. However, even if you are not interested in that, this little popup contains a list of all currently open tabs, regardless of the window they are in.

Double clicking any entry in there will take you to the correct window and focus the desired tab. Nice and easy, not even an extension needs to be installed :) The only drawback I see is that you cannot sort that list, clicking the "Address" column header has no effect.

A final tip: When you open the window, it might have one or more of the entries expanded, making the list overly long. Even though there is no collapse-all feature I could find, you can rather quickly do so manually by selecting the top entry in the list and then repeatedly hit the left and down arrow keys. Left arrow will close the currently selected item, down arrow move to the next entry. Even with lots of tabs listed, within a few seconds you should make your way all the way down, leaving a nice clean list of tabs.