Compression of the lyrics of the "12 Days Of Christmas"

Eleven years ago I blogged about a solution to the "Never Gonna Give You Up" compression code golf challenge: what's the smallest program that output the lyrics of Rick Astley's phenomenon? My solution was 589 bytes of Perl that looked like this:

$b=<<E;
 gÐngÑveÒe >ÓthÔouÕo Önd× yÕØÖloÙiÑ Út's Û(OohÜe'reÝ
YÕÞ knowß,ÐivàÚoá I'm â tÖsãtell ä a× åØ æeåçay it
è äértØêß ëÐonna ì oÔer íæupîmakeæïÛbeen ðëÔÓñÕ'rÓtoÖòeî)
óeÒrìô
We'Òßõ
NôöóÜ÷ôgiÒø howâfeeliÑ
ù
Nøú÷)ú, nø
(Givû
I just wannaéyÕùGotta ïu×ersta×
þü eachífor sÙÑÞr hearðachÚbut
YòshyãèInsidÓwÓboÔëwhaðgoán
WeñgamçwÝìplèýúîöletædownörun arÕ×ådeseêöïcryösayÐoodbyeöäa liçhuê
þWÝ nÖstraÑers tÙÒÞñrulesåsÖdÖI
A full commitmenÛwhatâÔinkáfÞ wÕldn'tÐet Ôis from anyíguyüõnýA× 
ifæask meùDon'témÓyòbli×ãee
þþ
Üà÷àûûóõýüþþ
E
map{($a,$b)=split($c=chr,$b,2);$b=~s/$c/$a/g}(208..254);print$b

The $b variable contains a dictionary where the index is made up of ASCII characters above 128 and the single line of Perl code at the end substitutes the dictionary entries until the full lyrics are output.

I wondered about using the same technique on the "12 Days Of Christmas" as there's a lot of repetition but the song is longer. "Never Gonna Give You Up" is 1,872 bytes and "12 Days Of Christmas" is 2,386. Using the same technique results in this 479 byte Perl program that outputs in the "12 Days Of Christmas":

$b=<<Z;
enÙ tÚ
TÛs,Üe ÝingÞÙ ßvÝgà druás a-âÞ,ãdâäevßåpãæmmãçOnÚhÝè.
èééfêéeëétìésí
NinÝladies dancãþî partridgÝin a pearÚreeïßloräleaæîð day of ChristmaÜ
myÚruÝloàavÝto meñdñòthñónóôóÛõeveôöÛwoÚurtlÝdoveÜ
And aï÷
Elåpipers piæÛðøÛhreÝFrÙch hÙÜ÷ù
Four callÞ birdÜùú
FiàoldßrÞÜúû
Six geesÝa-layãûü
Såswanâswiçüý
Eight maiämilkãýþèfirstñ
Aïíeconò÷ìhiròùêouróúêifóûíixóüíöýëighóþéniôîìÙõðëlöøìwelfõwelveámmersáçø!
Z
map{($a,$b)=split($c=chr,$b,2);$b=~s/$c/$a/g}(217..254);print$b

Complete restoration of an IBM "Butterfly" ThinkPad 701c

Just over a year ago there was a discussion on Hacker News about the IBM ThinkPad 701c (the one with the lovely folding "butterfly" keyboard). In particular, it was a discussion about the incredible web site 701c.org which gives very, very detailed instructions on how to dismantle, restore and preserve those lovely machines.

In the discussion a chap said: "I have two in non-working condition, pretty beat up. If I can make someone really happy and they want to restore them, feel free to send me an email. I wanted to do it myself for the last 10 years it so but realistically know I won’t. I’m based in NL." And I figured, he's not too far from me, maybe I could get them and create one restored machine from them.

A year later my fully restored (and memory upgraded!) IBM ThinkPad 701c is finished. Here it is:

It was a long journey to get here. I've written before about the painstaking operation to repair a damaged ribbon cable for the pointer. 

This blog post is a deeper dive into going from these two machines (see below for representative pictures of the mess they were in) to the picture above. Everything I know about restoring this machine came from the 701c.org website and a couple of emails with its creator. Without him this would not have happened. Thank you!

As you can see everything is a mess. The batteries have leaked and damaged the cases, screws are missing, parts are warped, covers are missing, the rubberized paint has become a sticky mess. But at least one of the keyboards seems to be OK (but see above about the ribbon cable!).

One of the machines would actually power on with nothing on the display. The other was totally dead. Time to dismantle the two and see what's salvageable.

Dismantling 

The 701c.org site and the IBM manual and video it links to have detailed instructions on how to take these machines apart. As I took them apart case pieces that had been soaked in battery goo just broke away in my hands. So taking them apart was a slow and delicate operation. Here are some internal pictures during that process.

One of the machines was an IBM ThinkPad 701cs (which has a less capable screen than the 701c). In addition, the screen frame just cracked apart as I was removing it. But it did have a working modem:

Both machines had extensive damage from the batteries having leaked:

The state of the batteries once I had managed to remove them from the cases:

This battery goo had damaged one bottom case to the point that it was crumbling in my hands. Luckily, the other case had survived:

Between the two machines I had enough pieces to make a single machine. The major case parts were there (they "just" needed stripping and repainting) and I had a complete set of screws as well. The screws matter because some of them are T1 torx screws (not something you want to mislay). 

Before trying to see if I could get the machine to boot into anything I first needed to clean up the battery mess.

Cleaning up battery leakage

As you can see above the batteries had leaked inside the laptops and made a mess. Via a very slow process of using 90% isopropyl alcohol (IPA) and a sharp tool and a toothbrush all that material was removed and with a multimeter I was able to verify that all the connections were good and there were no shorts.

In the end the terminals ended up looking something like this:

You can see how the metal has been damaged but luckily the connectors are still intact. I also washed all the circuit boards with 90% IPA and replaced the old Kapton tape. Since I was going to end up building a frankenmachine I stuck coloured stickers on parts. Throughout the photos you'll see little red and green stickers indicating which original machine the parts came from.

Why no screen?

One question that got immediately answered on dismantling the machines was "Why does one machine power on but have a blank screen?". Answer: because someone has completely removed the screen connector. I suspect one machine might have been used as a source of parts at some point.

Happily the other machine had a cable and so I was able to take multiple parts from different computers and create something that starts.

Finding a combination of parts that work

On first boot the frankenmachine complained about three things: memory, date and time and CMOS.

All of those things are actually symptoms of the same thing: the CMOS battery is dead and has lost settings and the machine has lost its way. But it's a simple fix! Hitting ESC allowed me to run diagnostics on the machine:

It had a lot to complain about but was bootable and even managed to get into Windows 95 (for a while). It would subsequently crash because there was a problem with the machine not knowing how much RAM it had (8MB!).

Fixing the CMOS battery

To stabilize the machine it was essential to replace the CMOS battery. It's pretty simple fix (see the 701c.org page for details).

Old battery before removal:

New battery installed:

(It was also around this time that I did the delicate ribbon cable repair for the keyboard) With the new CMOS battery in place the machine was no longer complaining about CMOS troubles.

And a run through the configuration utility and the machine was 100% stable and usable. Which brought me on to the most painful part of the operation: stripping the paint off the case. At was at this point that I began to question ever having started this project.

A total pain: stripping and repainting

Once again the 701c.org site will really take you through the process, but it's a lot of work. I couldn't get the same stripper and paint as I'm in Europe so I ended up using Tamiya TS-6 Matt Black Spray Matt and Tamiya TS-80 Flat Clear Spray Matt for the case. I stripped it using BRUTUS graffiti and paint remover.

I highly recommend having a pack of different grades of sandpaper and plastic razor blades.

Rubberized paint bubbling from the graffiti remover.

Scraping off rubberized and dissolved paint using a plastic razor blade.

Time for sanding after scraping and graffiti remover seems to have done its job.

Masking before spraying.

Mid-spraying. I put on three coats of the black paint.

Left to dry for at least 48 hours.

Once painted and dried the case needed the decals re-applied. But along the way there were little touchups like re-chroming and recolouring the IBM logo for the lid.

And repairing the cover for the memory slot by gluing in place a little piece of plastic to replace the broken latch. And so on and so on.

Decals

I bought a pack of decals from 701c.org and there make a huge difference. You just have to apply them very carefully. If you're old enough to have used Letraset you'll be fine here. But work slowly and carefully.

Final reassembly

On both machines the metal that connects the keyboard to the bottom case had broken off. Once the battery leaks and swells it applies pressure to this joint and destroys it. Here I glued it back into place with epoxy and carefully melted what little plastic dots I could to hold it into place.

The screen can be reassembled as a single unit.

You'll notice here a PCMCIA Ethernet adapter in place. I bought from eBay a complete set of accessories: docking station, cables, floppy disk drive and this PCMCIA card.

There are a whole load of small but important things that have to be done in re-assembly: glue the speaker back in place, reinsert the battery lock and its tiny spring, insert the spring and cover for the power button, don't break anything. But you can follow the 701c.org disassembly instructions in reverse.

A final boot test before final reassembly. Just complaining about the lack of keyboard.

Once fully reassembled I had a fully working Windows 95 machine. 

But who can resist an upgrade?

A memory upgrade

The machine came with 8MB of RAM but is upgradable to 40MB. Happily, it's possible to buy the needed 32MB SODIMM on eBay. Just a simple matter of slipping it into the slot on the motherboard that's accessible from the back.

The SODIMM in place.

Yes, 40MB!

What's next?

Well, I haven't replaced the sleep battery (apparently, there's a company in Hungary that makes a replacement but they won't ship outsider Hungary). And I can live without the sleep memory mode and I actually disabled hibernate in the BIOS.

And I haven't replaced the main battery. I have all the parts but need access to a large 3D printer to print the case. One day.

And the machine doesn't have access to the Internet with this version of Windows 95. It has a helpful file called Internet.Txt that tells you what the Internet is! But it does have a modem and PCMCIA Ethernet so should be doable.

But, I'm ready. 

So with this machine I'm ready.

So ready for 1995.

(If you really like retro computing I have a whole web site just for that: Two Stop Bits).

Using my Minitel 1B over the phone network in 2023

This is a story about connecting a Minitel 1B via the phone line as you would have done in the 1980s and 1990s. It's a story about enthusiastic nerds who've stood up Minitel servers that you can dial into. But it's really a story about how I hung onto French telephone adapters for more than 25 years just knowing, knowing that one day (one day!) I'd need them. 

That day was today.  

Aside: the French F-010 telephone plug is the Gallic-Telephonic equivalent of the British BS1363 three pin AC plug: when you plug it in there's no messing around.

I've written about the Minitel 1B before: using it with a fun little ESP32 gadget called the Minimit and using it as a serial terminal). But until today I had not used the internal modem to connect to a compatible server at the blinding speed of 1200/75 baud! (1200 baud down to receive data and 75 baud up to send your keystrokes).

Here's the Minitel 1B in question:

Instead of connecting it to that little Minimit box on the right I'm connecting it to my home phone line (which will for the first time in years be making a phone call!). To connect a Minitel to the phone line you need to plug it in along with a telephone. The telephone is first used to make a call to the appropriate server and then the Minitel takes over. 

So, I found my emergency telephone (and old handset I keep around for use if all I have left for communications is POTS), which for good measure has a British telephone plug on it for which I have an adapter to RJ11. 

I also have an RJ11 to F-010 adapter to I end up with this:

Amazingly, that works, and I can dial from Portugal into French Minitel servers. There are two in particular that seem to be online: one run by folks at IUT Auxerre and another run by enthusiast Jelora. The IUT Auxerre server is on 03 58 43 51 50 and Jelora's server is on 09 72 62 92 67. Just add 00 33 at the start and drop the 0 to dial from Portugal.

To operate Minitel you start it up and wait to see the F in the corner. Then you dial the server on the phone and wait for the modem sound. Then you press Connection/Fin and hang up. The Minitel does the rest.

Here's a warts-and-all video of me dialing in Jelora's server and then the one in IUT Auxerre. I had some difficulty with the connection with Jelora's server and given the flakiness of my cabling and the call to France I'm not super surprised.

The video should give you a good sense of the speed of operation of a Minitel in the 1980s and 1990s. And shows a typical use: getting train times (of course, you could also book train tickets). 

My primality testing code is 6x faster than Sir Roger Penrose's

But, I guess he did win the Nobel Prize for Physics in 2020 so I can't really brag.

However, it was a great surprise when looking at two pages from Penrose's notebooks that two columns of code for a Commodore P50 calculator leapt off the page at me. It's a UNIX system. I know this! And furthermore that the right hand column is code for testing whether a number is prime.

Here's the page from the notebook:

(If you weren't familiar with this code, Penrose has written what it does and the fact that it runs on the Commodore P50)

I have a great love for the Commodore P50 because I had one in the late 1970s and recently restored it. And Penrose's code was of great interest to me because I also wrote a primality testing program for it. This is quite hard to do because of the limited memory in the calculator. The maximum length of a program on the Commodore P50 is 24 steps, and register space is... well, read on.

There's a neat trick in Penrose's code that I couldn't use because of how I chose to test factors. It makes his code incredibly slow but doesn't require a kind of ugly mechanism for storing state that mine does.

Here's my code (on the left) and Penrose's (on the right) side by side.

   My code                      Sir Roger Penrose's

   lrn                          lrn
   00 RCL                       00 STO
   01 -                         01 √x
   02 INT                       02 INT
   03 *                         03 +/-
   04 4                         04 x<->y
   05 10^x                      05 RCL
   06 /                         06 x<->y
   07 RCL                       07 x<->M
   08 INT                       08 x<->M
   09 -                         09 M+
   10 INT                       10 x<->M
   11 =                         11 SKZ
   12 SKZ                       12 GOTO
   13 GOTO                      13 15
   14 18                        14 R/S
   15 RCL                       15 SKN
   16 INT                       16 GOTO
   17 R/S                       17 08
   18 1                         18 1
   19 +/-                       19 M+

   20 M+                        20 x<->y

   21 GOTO                      21 x<->M

   22 00                        22 GOTO

   lrn                          23 04

                                lrn

Both these programs work by doing trial division of factors starting from INT(√x) and working down to trying to find a factor. My code does this with actual division (step 06), Penrose does it using repeated subtraction (the M+ of the factor which is made negative by the +/- in step 03). His use of repeated subtraction makes his code slow, but it also means he isn't forced to store the number being tested (and the current factor being tried) in the weird encoding I had to use (see original blog post, but in short I use the memory to store a decimal number where the integer part is the number being tested and the decimal the current factor divided by 10,000).

Running my code testing if 199 is prime gives the result (it is!) in 1m44s; Penrose's code takes 10m37s. I'm six times faster than Mr. Nobel over there! But he gets to use a neat trick that I don't. 

The Commodore P50 has one register that the programmer can use: the memory. The memory is accessed through the STO (store in the memory), RCL (recall from memory), M+ (add to memory), and Mx (multiply memory) buttons. But there are two temporary registers called x and y. x is the value that's currently on screen and y is the other operand for a two operand operation like 6 + 7. 

For example, in 6 + 7 the 7 on screen will be in x and the 6 in y. It's actually possible to access y through the x <-> y button which swaps them. Penrose's trick is to never use an operation requiring two operands. By using M+ exclusively to do repeated subtraction (and increment the trial factor each time round the loop), the y register is never touched and therefore he gets to use it for storage.

So, he stores either the number being tested or the current factor in y. And by careful use of x <-> M (which swaps the on screen number and memory) he's able to keep both numbers he needs without resorting to my encoding trickery.

It's very elegant (if slow).

The other thing that's nice about his code is that it requires no set up (whereas mine requires first storing the number and INT(√x) in the encoded form).

(If you enjoyed this you might enjoy Double-checking Dawkins)

Reading the Lovelace Foundation's Nuclear Bomb Effects Computer

The April 1962 edition of The Effects of Nuclear Weapons (published the the US Department of the Army) is a strangely easily readable book about a hideous topic: the effects of a nuclear blast. It introduces different types of weapons, explains their operation and then goes into detail about the four effects: thermal radiation, blast and shock, the initial nuclear radiation and residual nuclear radiation. 

The book is 730 pages long and quite extensive. It covers information derived from United States nuclear weapons tests, as well as the direct experience of the bombing of Hiroshima and Nagasaki. Despite growing up through the Cold War I found reading it sobering; the book is full of technical detail of just how devastating a nuclear blast would be on people, buildings, vehicles, and so on.

It sold for $4.25, but for an additional $1.00 it was possible to buy a circular slide rule that used data from the book to enable quick calculations of the effect of a nuclear weapon. In this blog post I'll run through the sort of information available on the slide rule.

Here's what it looks like:

This is called the Nuclear Bomb Effects Computer.

Calculating the overpressure and wind speed

The yield of the a nuclear explosion (the equivalent number of tons of TNT that would be needed to generate the same explosive force) is set on the white outer ring. In the pictures, I have set this to 100 KT (100 kiloton). For comparison the Hiroshima bomb yield was about 16 KT and the Nagasaki explosion about 21 KT. During the Cold War bombs with megaton (MT) yields were tested and deployed. The computer allows calculations with yields up to 20 MT.

It's then possible to set the range (i.e. the distance from the explosion at which you take calculations). You do this by aligning the large blue circle with the hairline at the yield. In the example, I have yield at 100 KT and range at 1.6 miles.

Note that the computer dates to 1962 and is a US-designed device and thus uses US units. I usually use SI units on the blog, but for this I'll stick with the units on the computer itself for simplicity. The computer actually comes with a conversion chart for SI to US units.

With the yield and range set, you can read (at the top in my pictures) the pressures and wind speeds associated with the explosion at the selected range. There are two explosion types: surface burst (bomb goes off at the surface) and optimum burst height (the bomb goes off at the optimum height to maximize the overpressure at the selected range).

Overpressure is significant because it results in measurable damage and thus the damage effect of the weapon can be selected based on what's being targeted and at what range. In my selection above you can read off that at optimum burst height the overpressure would be about 7 psi, and for a surface burst about 3.4 psi. The same window shows that the associated wind speed would be about 215 mph for the optimum burst height and 120 mph for a surface burst. 

Those pressures would kill and injure people and destroy buildings at a range of 1.6 miles. The computer contains short reference guides to the effects of overpressure.

Note that this is only talking about the overpressure effects and is not taking into account the effects of nuclear or thermal radiation.

When the overpressure arrives and for how long

The second cream window from the centre shows the arrival time and duration of the maximum overpressure. It's read by finding the overpressure on the blue scale just outside the cream window (there are two scales for surface burst and optimum burst height) and finding the equivalent time in the cream window.

In my example, if the 100KT bomb went off at optimum burst height the maximum overpressure of 7 psi would occur just under 6 seconds after detonation and last for just under 1.4 seconds.

Fireball and flying people and glass

The computer also gives information about the velocity at which broken glass will be projected and for a human weighing 165 pounds standing in an open area and hit by the blast wave. The fireball size is significant because anything within the fireball will be vaporized.

For the 100 KT bomb size the fireball works out to be 0.28 miles in radius. 

To read the speeds of broken glass and a human it's necessary to find the range in the appropriate window and read off the speeds. With a 100 KT explosion and range of 1.6 miles, broken glass would be moving at 250 feet per second (to put that in more familiar figures: that's around 170 mph). The theoretical 165 pound human caught up in the blast would be projected at 30 feet per second (or 20 mph).

The computer has helpful scales so that we can interpret those speeds and their effects.

So, the hypothetical 165 pound human projected at 30 feet per second who then hit something hard would almost certainly be killed.  That's if the flying glass didn't kill them first:

Thermal and nuclear radiation

The reverse of the computer contains scales to calculate the thermal and nuclear radiation produced by the explosion. You first set the yield and range on the other side (as before) and then use red moveable line to find the thermal radiation in cal per cm^2 (oddly, this is the point in which the calculator uses metric).

Here we see the thermal radiation at 1.6 miles for 100 KT being about 35 calories per cm^2 (well above the levels that will cause third-degree burns and likely fatal).

The level of initial (pre-fallout) nuclear radiation is read on the black lines in a similar manner. Here is appears to be about 20 REM.

WarGames

In the 1983 film WarGames one of the central characters, Professor Stephen Falken, states that he's chosen to live three miles from a primary target so that in the event of a nuclear war there will be millisecond of brilliant light and then he (and his house guests) will be vaporized.

Using the Nuclear Bomb Effects Computer it's possible to see if that's accurate. By selecting a fireball radius of 3 miles we get a bomb yield of above what the computer can handle. So, I'm guessing Falken is too far from the target to get vaporized.

Nevertheless, using a more likely Cold War bomb yield of 10 MT we find that he'll experience overpressure of about 30 psi (which will completely destroy his house), winds of 700 mph, thermal radiation of 1000 cal per cm^2 and a radiation dose that's off the scale. He wasn't wrong about dying, just about how fast it would happen.

Conclusion

As I read through the book and worked with the calculator I was struck by how manipulating this simple device slowly revealed numbers that describe horrors: massive fireballs, pressure, winds, flying glass and people, nuclear radiation and burns.

It's chilling distillation of the horrific effects of nuclear weapons into a small, handheld and easy-to-use device.