A Trip to Norway

Our cruise ship, the Havila Castor

We wanted to go away for a week in August. Going south just means more crowds, so we wanted to go north. Neither of us has spent much time in Norway - I’d never been there at all. So that’s where we decided to go. After a lot of research, we worked with a travel organizer who set up a couple of nights in Oslo, then the classic “Norway in a Nutshell” journey to Bergen by train and ferry, stopping one night in the fjord at Flåm. Finally we would take a cruise along the coast from Bergen to the Arctic Circle.

It was a very enjoyable trip. Norway reminded us of Japan - very clean and correct, and it works. There seems to be a similar sense of shared social responsibility, putting society before the individual. We loved the dramatic scenery of the fjords and later the barren Arctic landscapes, with their occasional villages and hamlets. The cruise, on the Hurtigruten (coastal express) was really enjoyable and relaxing. We were incredibly lucky with the weather, with only one rainy afternoon. On our one night in the Arctic it was warm enough to sit outside without a coat even at midnight.

The only downside is that Norway is eye-wateringly expensive. A restaurant meal is two or three times more than it would be in France, and that goes for the other things we did too. Our French guidebook (Le Routard) warned us to have low expectations of food, but we ate great food throughout the trip.

Arrival in Oslo

To our surprise, there are direct flights from Nice to Oslo - lots of them, about six per day. Goodness knows who uses them. On our arrival in Oslo we ran into our first problem, which was a bit disconcerting, but it turned out to be the only one. The frequent express train into the city wasn’t running, due to a technical problem. But it was handled extremely well, with numerous guides ushering people onto a frequent bus replacement - electric, of course - which took us to the train station. We were impressed with how quickly this must all have been organized and how well it worked.

We made it into the city late in the afternoon, and set out to explore. I was a bit handicapped by a knee problem, which makes walking a long way difficult. Luckily we discovered the electric scooters which are ubiquitous there. A couple of minutes to install the necessary app on my phone and I was off, driving very slowly partly so Isabelle could keep up with me on foot, and partly because at any speed much higher than a walking pace, they are terrifying.

The Scooter Experience

My scooter took me to the harbour area, with Isabelle following on foot. The seafront was full of people strolling, eating, drinking and watching the constant stream of ferries coming and going. It was warm enough that even the tiny beach was filled with scantily-clad people.

I’d had a couple of beers with dinner and didn’t fancy braving the scooter again, so we got a taxi. That was our introduction to Norwegian prices. The short ride, equivalent to about four stops on the bus, cost over €30.

Our hotel, the Clarion, was business-like, modern, and right by the station. The most striking feature was the breakfast, a giant room, packed with people, and a huge buffet. There was every kind of food, lots of fish, charcuterie and cheese, fruits and vegetables, all kinds of bread, pastries, cereals, etc. It was hard to choose.

Our package included a 24-hour “Oslo Pass”, which gives unlimited public transport, entrance to museums, and various other things. We activated that the next morning and used it to take a tram to the harbour so we could take a ferry to Bygdøy, an island (almost) with several museums. Public transport in Oslo is really excellent, there are trams that run every few minutes and a comprehensive bus system that is nearly as frequent, plus of course the ubiquitous scooters. The short ferry journey was very pleasant, admiring the city from the water, and the many, many boats including a couple of the giant cruise ships that we had studiously avoided.

The closest museum to the ferry terminal is the Fram Museum, which is all about Amundsen’s successful 1911 expedition to the South Pole. To our surprise we spent over three hours there. The centrepiece, literally and metaphorically, is the eponymous ship, around which the museum is built. The striking thing about the expedition is the amount of organization it took. If you got to the South Pole and discovered you didn’t have enough trouser buttons (the actual example Amundsen used), you were stuck. He spent two years organizing the trip before setting out, primarily making sure they had enough supplies.

The story of their journey to the pole is truly an astounding one, including the essential return journey. He was in a race with the British explorer Scott, who did get there a few days after him but famously failed to return, dying just 100 km from his ship.

Amundsen didn’t stop there though. He became fascinated by aviation, and in 1925 made an effort to reach the North Pole by plane. They set out with two Dornier Wal aircraft, N24 and N25, incredibly crude by modern standards with open cockpits - to fly in the Arctic! N24 had an engine failure and N25 managed an emergency landing close by. It took nearly four weeks to hack out of the ice a runway long enough to take off, the crews of both planes living in N25 and surviving on rations that were intended for a much shorter journey. Finally they took off, massively overloaded, barely managing to climb over the surrounding terrain.

You don’t have to imagine this, because the museum has a simulator that re-enacts it, including the takeoff. The seats are animated and bounce around as you careen down the improvised runway then fly terrifyingly close to the hostile terrain.

Sadly Amundsen died in 1928, at the age of 55, when his plane disappeared on a rescue mission trying to find some other explorers. His whole life story is extraordinary and truly amazing.

In the evening we visited my friend Ole at his house in a chic suburb, where he and his family fed us some excellent roast moose and generally entertained us. It was a very pleasant evening. Horrified by the price of taxis, we took the bus both ways, which worked very well and didn’t even cost anything thanks to our Oslo Pass.

To The Fjords

The next morning saw us on a Bergen-bound train at 0812. Early mornings seemed to be a feature of this trip. For five hours we had magnificent views of the green countryside, with lakes, mountains, pine forests and everywhere red houses surrounded by mauve flowers.

At a station high in the mountains we changed onto the Flåmsbana, a separate train which drops dramatically from nearly 900 metres to sea level at its terminus, in just 20 km. It is the steepest adhesion (i.e. not rack) railway in Europe. The views as it descends are spectacular, with numerous waterfalls, and complicated spiral tunnels dug by hand in the 1930s. It feels strange to start so high in the mountains, and finish at sea level after such a short distance.

The town of Flåm sits at the end of Aurlandfjord, which is a branch of one of the most famous of all of them, Sognefjord. There isn’t a lot there: a handful of small hotels, the train station and an associated museum, and several tourist-oriented gift shops. While the big cruise ships are in port they are packed - mostly with Chinese tourists while we were there. Then the hordes return to their ships, the shops are deserted, and soon after they are shuttered closed. Our trip included a bus ride up the side of the fjord to Steingasten, an improbable giant concrete platform with magnificent views across the whole area. We saw a small boat carrying a bunch of survival-suited passengers, and found its origin, a company called Fjord Safari - and became two of the survival-suited passengers ourselves. We spent a couple of hours admiring the fjord from water level, which was fascinating. Flat land is rare in most of Norway, so when people found some, they made the most of it. We were shown one farm, high up on the cliffside of the fjord with a little flat, but steep, land around it. The guide explained that it is called “stigen”, Norwegian for ladder, because the only access from the water involved climbing a ladder up a sheer cliff. The latest owner has blasted a steep, narrow path to replace the ladder, but it is still a couple of hundred metres up the side of a cliff, with the only access being from the water. Amazingly, the property is still in use, and has even been used for a wedding. It’s really hard to imagine, nowadays, the life of the farmer, carrying all his supplies up the ladder, including presumably the building materials that the house and barn are made of. Apparently they paid no taxes, because whenever the tax inspector came round, they just pulled up the ladder. Later on we saw several more farms like this, perched precariously half way up a cliff, with no apparent means of reaching them either from above or from below. Many of them look in good shape and are probably still in use, though maybe no longer as active farms. The following afternoon we embarked on the ferry ride from Flåm to Bergen, out along the Sognefjord and then southwards down the coast. There are ferries everywhere - the fjords are wide and penetrate a long way inland, so bridges are rarely practical. The coastal roads involve frequent ferry crossings, and there are many islands which at least until recently could only be reached that way. Now, many of them are linked by a series of bridges, made possible by Norway’s new-found wealth as an oil exporter. Our ferry was fast, cruising at 30 knots. Even so the journey took five hours, initially through the spectacular fjords - Sognefjord is a UNESCO world heritage site. Eventually it reaches the sea, threading its way between tiny islands, sometimes via passages that are barely wider than the boat. We were very lucky to spot some people leaving the boat at one of its early stops, vacating the very best seats at the front. Some quick footwork gave us a magnificent view of all this in the beautiful evening light. Five hours sounds a long time but I never even opened the book I had with me. Seen from the ferry on our way into Bergen

View from the Flåmsbana looking up nearly 1000m to its starting point Arrival in Flåm, complete with giant cruise ship and its passengers The Fjord Safari, complete with survival suits The view down Aurlandfjord from the Steingasten

Bergen

Bergen is renowned as the wettest town in Europe. Miraculously, during our two days there it was sunny - I even got a touch of sunburn. For centuries it was one of the principal towns of the Hanseatic League, the international trading organisation that dominated marine commerce in northern Europe. The waterfront consists entirely of buildings from that epoch, painted in bright colours and also a UNESCO world heritage site. Our hotel was nestled among these, an old and very characterful wooden building. Before we even got there, we passed through an incredible fish market, packed with every kind of fish imaginable including some crabs that put the Alaskan king crabs to shame, with enormous legs over 60 cm long. It’s the kind of place that makes you want to buy everything you can see, though sadly there wouldn’t be much point for us. The Hanseatic area is entirely given over to tourism. We visited the cathedral there, and did a guided tour which explained the daily life of the young apprentices to the League. Summary: it wasn't much fun. The old town of Bergen is in a narrow, steep valley. Later development has gone up the valley slopes, and there is a funicular that goes from a few yards behind our hotel, to the top of the ridge. We even had a ticket for it in our collections of vouchers and whatnot, so up we went. The cafe and bar at the top was packed, as people enjoyed the spectacular view over the harbour and the city. We joined them, and Isabelle even walked down the twisty path back to town, wandering through narrow streets that haven’t changed in centuries. Diner that night was at the Enshjørningen (Unicorn) fish restaurant, reputed to be one of the best in Bergen. It was very good, but like all eating in Norway, eye-wateringly expensive. Most of the time in Norway we drank beer, but at such a chic restaurant we felt obliged to drink Chablis - which was very good, though didn’t help at all with the bill. The next day was our departure on the cruise, but that didn’t leave until the evening. We walked - well, I scootered - to the Kode Museum, which contains many works by Norwegian artists, including a section dedicated to Edward Munch, of “The Scream” fame. It showed his progression from enjoyable, strictly pictorial work through to his more surreal works, called “expressionism”, leading via some enjoyable pictures to the universally-known but challenging “The Scream”. There were many other works showing Norwegian life, which we really enjoyed. Isabelle particularly liked Nikolai Astrup, which she found full of poetry. We’d noticed a seaplane flying very low over the town, and a bit of Googling showed that there is a seaplane doing “trips round the bay” from the harbour. We managed to get a booking, and spent an interesting half hour flying into the fjords and then a tour of Bergen itself, in a Cessna 206 on floats. From there a taxi took us directly to the cruise terminal. Heyerdahl's "Old Man", a whole lifetime shown in his face A giant cruise ship from an unusual angle

Bergen's Hanseatic Quay Bergen from the summit of the Funicular One of Munch's earlier works A painting by Nikolai Astrup The Hanseatic Quay from the Seaplane

The Cruise

What I thought our ship would be like

We have never done any kind of cruise before. We see the giant 5000 passenger cruise ships at Nice and Cannes all the time, and they terrify us. Our ship was just 300 passengers, but even so we didn’t know what to expect.

The cruise route is still called Hurtigruten, which translates roughly as “coastal express”. It has been running since 1893, when it was launched as a way to connect all the remote coastal towns and villages with rest of Norway. It runs from Bergen in the south all the way up and round the Norwegian coast to Kirkenes, a few kilometres from the Russian border, taking 6 days and making about 30 stops. I envisaged a kind of coastal tramp steamer with half a dozen cabins for the intrepid, a bit like the picture on the right - the MS Salten which indeed did operate the Hurtigruten during the 1950s.

I was wrong. Our boat, the Havila Castor, was very modern and very luxurious. Our cabin was like a decent-sized hotel room, with its own bathroom, a good sized bed and a window giving us a view of the passing coastline. A restaurant served three meals a day, with table service rather than the buffet which seems to be universal on cruises. The food was excellent. At the front of the topmost level was a bar with huge windows looking forward and sideways. For the intrepid, a terrace ran all round the outside of the boat, perfect for taking pictures or just enjoying the sea air. We were incredibly lucky with the weather - it was never too cold or wet to stand or sit outside, though sometimes it was a bit windy.

I’d expected much of the journey to be quite boring, and had brought several books. I was quite wrong. Our departure from Bergen, passing through narrow channels between islands, was beautiful. The boat generally stays as close to the mainland as it can, meaning that there is nearly always something to see on both sides.

As we sailed away through the night we couldn’t help noticing the navigation lights. Seen in daylight these are like miniature lighthouses, a couple of metres tall and perched on rocky outcrops or the tips of islands. What struck us was the way they change colour at night, going from red to green to white and back to red as we progressed. Thanks to openseamap.org and some googling, we understood. They don’t actually change colour, they shine in different colours at different angles, a bit like a water-borne VOR (aerial navigation beacon). The picture shows the first one that got our attention. The dashed blue line is the boat’s course, so the lights shows red, green. white, green red as the boat sails along.

Even at midnight it wasn’t dark. Finally we persuaded ourselves to go to bed. When we awoke in the morning, it was delightful to watch the coast passing by the window. Later, the boat passed into Geiranger Fjord, very narrow and steep and another UNESCO world heritage site. The sides are near vertical, yet once again there are farms with their white houses and red barns perched way up on the cliffside, often with no visible means of approach from either above or below. While few of them are still active farms, they are mostly still in use as second homes. They must be very fit, the Norwegians. At Geiranger we had elected to take an excursion. We were duly herded off the ship and onto a bus. This was the only time when it got a bit claustrophobic, all packed into a small space in the bowels of the ship waiting for a tender to join up with it and take us ashore. The goal was to see the magnificent views from the mountain roads, including the famous Trollstigen (Troll road - the Norwegians are very fond of trolls) with its eleven hairpin bends, pretty challenging in a bus. Unfortunately though, this was the one day when we had bad weather - really bad. As soon as we got high enough to have a view of anything, we were inside the cloud. We spent the afternoon being told about the magnificent views we would have - if only we could see anything at all - by a very friendly Italian guide whose French was as badly mangled as his English. We would rejoin the ship later in the day after it had made its way northwards to Molde, the city of roses. The mild climate means that roses grow readily, and every building in the town is surrounded by thousands of them, and even the roof of the city hall. We stopped at the town of Åndalsnes on the way for dinner. A brand new funicular took us to the top of a mountain, where a very light meal was served in the restaurant. As you may have guessed, we could see absolutely nothing at all. The bus ride was interesting though, enjoying the Norway coastal road experience, with a couple of ferries and a huge new bridge and tunnel in the 140 km drive. Our next excursion was at Trondheim, where the ship stopped for three hours. The city used to have a tram system, but in 1980, like many places, they abandoned it. The longest line, which is more like a suburban railway, was taken over by enthusiasts. They did such a good job that later, it was bought out by a private company and now runs a regular tram service. In cooperation with the tram museum half way along the line, they also operate vintage trams as private charters, which is what we did. Our tram was built in 1958 and steadily rattled its way along the line, showing us the suburbs that rise on the hills above Trondheim. Back in the city, we stopped at the cathedral. Unlike southern Europe, Norwegian churches are very austere, with very little decoration. This is the most famous cathedral in Norway, huge and built from grey stone in an elaborate Gothic style. Among the numerous altars, there is one to the Sami people, the eskimo-like natives of northern Norway.  The organ is absolutely amazing, I would love to hear it played, with pipes long enough to make your bones rattle. That one is quite recent, but there is one from 1793 as well. It’s beautiful, but it’s not clear whether it ever gets played. North of Trondheim the boat wiggles its way through a tiny passage between the islands near Stokkøya. It’s an amazing feat of precise navigation - they only do it in perfect weather. At times the passage is barely wider than the boat, and the navigable channel surely even narrower. The boat has a relatively shallow draft, about 5 metres, but you have to know where that depth is. I had the chance of a brief conversation with the captain. The boat has an autopilot, every bit as capable as on a plane. But he explained to me that where things are delicate, everything is done by hand.

Leaving Bergen at Sunset A Typical Coastal Village Mysterious Inaccessible Cliffside Farms Navigating the Fjords

The Arctic Circle

Crossing the Arctic Circle at 66° 33' N

The big thing after Trondheim was entering the Arctic Circle. The mountains, which were so far rather round, become quite pointy, and we could see a couple of glaciers in the distance.The boat ran a sweepstake to see who could guess the time most accurately. It might be possible to work it out but you would need a very detailed knowledge of the exact course and speeds, so it isn’t really worth trying. But we knew that it would be between 0630 and 0730 local, and at 0630 we were dutifully on deck to see it go past. There is a globe on an island that marks the spot, although I think from my phone’s GPS that it’s not quite the exact latitude - but there is no handy island a little further north where it really is.

Nothing dramatic happens when you cross it, of course. The sun doesn’t suddenly spring out. In fact, we were a couple of weeks late for “midnight sun” as these relatively southerly latitudes, but the night never gets dark. In winter it’s the opposite, and for several weeks the sun is never seen and it never really gets light. This doesn’t deter the courageous Hurtigruten - our boat and its ten companions make the journey day in, day out, summer and winter, light or dark and regardless of rough seas and storms.

By then it was time for breakfast, celebrated with champagne. Afterwards there was a deck celebration for the winner of the sweepstake, and then an ancient tradition (recently invented, we suspect) of having ice poured down your back by a mythical snow monster. We didn’t volunteer.

Our next call was at the arctic town of Bodø. We’d discovered that it is home to Norway’s principal aviation museum, so we arranged for a freelance excursion to see it.

Surprisingly, that was not one of the tours offered by the ship. It seems odd for the museum to be there rather than Oslo, but there is history behind it. During the Cold War, Bodø was a forward base for the U2 spy planes that flew at extreme altitudes over Russia. Bodø was Gary Powers’ destination when his U2 was shot down over Russia in 1962, creating a major diplomatic incident.

The museum has lots of aircraft, military in one wing, including a U2, and civilian in the other. The civilian part also includes the history of civil aviation in Norway, including a huge-looking Junkers three-engine floatplane - though in reality it is tiny compared to modern airliners.

From Bodø we set sail for the Lofoten Islands. This was the only part of the voyage that was how I’d imagined it, cutting an angle across the open sea with little to see on either side. I even managed to read a few pages of the book which I had been carrying round unopened since our arrival at Oslo airport. Our first stop was at the tiny port of Stamsund, where we got to see - one more time - the incredibly slick procedure at these ten-minute stopovers. First, a little door opens way up on the bow. As the ship approaches the quay, a sailor throws out a ball attached to a line, which in turn is attached to the thick mooring ropes. A quay-hand pulls the line and prepares to tie them up. Meanwhile the two ramps that will give access to the ship start to emerge through giant doors that have already opened. By the time the ship is close, they are fully extended. The movement of the boat is exquisitely controlled, so that 16,000 tons of boat come to a halt millimetres before touching the edge. Then the ramps are lowered to reach the ground. Instantly a little fork-lift appears from a corner somewhere to drive up and down the rear cargo ramp, loading and unloading a few palettes. Then the few disembarking passengers emerge, trundling suitcases. Often they are welcomed with big hugs by their friends and relations waiting on the quay. Meanwhile other little groups start to break up, with tearful farewells and waves as one or two people leave the others behind. And then, just a few minutes later, everything goes into reverse. The mooring ropes are released and pulled back into the boat, and the ramps are lifted clear of the ground. As soon as that is done, powerful thrusters move the boat away from the quayside and the ramps start to retract back into the boat. Often this is followed by a complex manouevre to extract the ship from the confines of the port and turn it around to leave in the opposite direction. At the smallest ports the whole process, from beginning to end, takes less than ten minutes. In nice weather it’s a pleasure to watch. In the depths of winter it may be nicer to stay inside in the bar. And all this happens a total of 34 times on the six-day voyage from Bergen to Kirkenes.

The Man with the Rope Preparing to Dock

Lofoten Islands and Svolvaer

The Lofoten Islands are famous for their beautiful rugged scenery. The final part of our journey was to Svolvaer, which isn’t very interesting, consisting mainly of hotels, but it is the capital and tourism centre of the islands. A taxi took us to our hotel on a tiny island. Unlike the modern structures close to the quay it was very charming, consisting of wooden cabins painted the dark red of the barns and fishermen’s cabins we had seen all along the journey. We’d eaten dinner on the boat, but there was a pub close by for a final drink. Although we had missed the midnight sun, it never got dark. At midnight the tables outside were packed with lightly-dressed visitors making the most of the exceptionally warm weather. The island was directly opposite the quay, with a great view of our ship - though it was no longer our home (sniff). It had to wait for a long time, because there were excursions that had started at the previous port so it had to wait for the small boats and the buses to arrive. Eventually we were able to watch it manouevre its way out of the very tight space in the harbour, simultaneously distancing itself from the quayside and turning through 180 degrees before departing even further north, eventually to arrive at Kirkenes three days later. In fact our itinerary didn’t really show us anything of the Lofoten Islands. We’d considered trying to extend by a day and disembark at Tromsø, the next major stop. But it would have been too complicated as a last minute change. That will be for next time - we already have it worked out. Fly to Svolvaer, rent a car and explore Lofoten by road, take a boat ride to yet another exceptional fjord, Trollfjord, then take the Hurtigruten to its northern terminus. Next year, maybe. All that was left was to fly home. A taxi took us to the tiny Svolvaer airport the next morning, where a 39-seat DHC8 turboprop showed up to take us to Oslo. With them, the company Widerøe runs a complex network of short flights to tiny airports on islands and in isolated towns all over Norway, the modern equivalent of the Hurtigruten's mission in 1893. But Widerøe's origins were very different. Mr Widerøe started his aviation career in the 1930s taking pictures of Norway's numerous isolated farms and homesteads, and selling them to the proud owners. Only after the war, he moved into carrying people. Our flight was mostly over the centre of the country, and while clouds obscured a lot of the view, there really isn't much there except mountains, more mountains and the occasional glacier - certainly no farms or people. At Oslo our connecting flight too us back home.  Good bye Norway, we liked you a lot. We'll be back. Our Ride Home

The Northern Coast Another Coastal Village A Midnight Beer in Svolvaer, with our Ship The Anker Brygge Hotel, Svolvaer

Vibe Coding with Cursor

Recently we hear all the time about how AI is going to replace nearly all jobs, and in particular how nobody will need software engineers any more because AI can write all the code. I don’t believe that for a moment, any more than I believed the same thing of ICL’s much-hyped “The Last One” in 1981.

People talk a lot of about “vibe coding”, which means getting AI to write code that you have absolutely no idea how to do yourself. When it inevitably doesn’t work, you tell the AI thing what’s wrong, and it fixes it. It sounds too good to be true - and I suspect is. But AI can certainly simplify and accelerate a lot of routine coding for things like web interfaces, which probably make up well over half of all the software out there. For sure there will be job losses. 

A few weeks ago I downloaded the new AI-focussed editor and IDE, Cursor. I’d heard a lot about it from a friend of mine who in addition to being a high-powered investment banker and private pilot, also spends a lot of time writing code just for fun.

I’d just been finally getting my head around the finer points of Shor’s algorithm for factoring huge numbers using quantum computing, including an optimized implementation of all the underlying non-quantum math. I asked Cursor to write the same thing, in Kotlin. It did a respectable job, though for production use, even pre-quantum, it would have taken a lot more work. Just for fun I also got it to write what must surely be the only implementation of a quantum algorithm in Cobol, too. I’ve thankfully never written any Cobol in my life, but I remember it from the Danial McCracken book that I read when I was about 16. The code looked convincing.

Then my friend wrote to me in amazement at the latest thing he had got Cursor to do. There is some pretty amazing stuff in there. His program scrapes PDF documents describing airports and other aviation stuff. It’s all completely unstructured, and varies greatly between countries. Yet with a lot of help from Cursor he has built a complete, structured database of this information and - his latest effort that amazed him - a powerful web front-end to access it.

It was time for me to do something myself. A while back I wrote a program to help solve and investigate Wordle puzzles. It started in Kotlin, but I rewrote it in C++, taking advantage of the highly parallel AVX instructions available on the latest CPUs. The user interface is a classic CLI, just as it would have been 50 years ago.

I’d often thought it would be nice to have a web front-end, that would look like the Wordle phone app plus a bunch of extra features. But I have no idea how to write a modern web GUI, using the current tools like React, and no enthusiasm at all to spend weeks getting my head around them. So nothing happened.

But this was the perfect opportunity to see what Cursor could really do. Could I just tell it to write a web front-end to my existing 25,000 or so lines of highly optimized C++?

Before I dive into the details, here’s a summary of how it went. Sometimes you tell it to create something which seems pretty complicated, and it writes a bunch of code that works first or maybe second time. That really is amazing. Other times it just goes round in circles, generating something that doesn’t work, and the correcting it based on feedback - into something that doesn’t work for a completely different reason. One item took me a whole afternoon of going round in circles like this before it finally worked.

After a couple of days of not very intensive work, I have a working front-end and the necessary back-end support. If I’d done it myself, the actual coding might not have taken much longer than that, but it would have taken weeks to learn enough about React, even with the usual help from Google and StackOverflow. And I would have gone mad with frustration trying to find a working package to interface a Rest API to C++. (Ironically, I created a very powerful interface that does exactly that for my day-job software, but the solution is way too heavyweight for what I had in mind here).

It’s surprising how often Cursor creates something which doesn’t work, then when you tell it what hasn’t worked, it says, “oh yes, to make that work you need to do such-and-such - would you like me to do it?” Typing “yes” does the trick, and then it runs into another thing that doesn’t work but which it knows how to fix. And so on and so on, until eventually you get something that does work. But you can’t help wondering, if it knew all that, why it didn’t get it right in the first place.

When I had got it all working I asked my son, who works with React all day long, to take a look at the React code it had generated. His verdict: “It's sort of the right shape for React but quite brutally ugly”.

Now for the Details

I started by running Cursor in the directory containing all my C++ code, which it obligingly listed in a pane on the left side of the screen. Then I said something like “create a web front-end that accesses the functionality of my Wordle program here”.

It hummed and whirred for a bit and then produced some React code for the front-end. Then it said, “would you like me to create the back-end too?” Well, yes, that was the whole point. Over the next few days I got really good at typing “yes”.

The result was a bit of a surprise. It used a package called Crow to build a Rest API to its very own, very basic Wordle implementation, completely ignoring my code. That didn’t bother me too much - I expected to have to figure out an interface to the real back-end code that understands Wordle and all the complex algorithms involved. It took a couple of hours of refactoring my C++ code and inserting appropriate hooks in my new Cursor-created web_server.cpp file.

Then followed a seriously frustrating session. From the browser I could create a new game, but every attempt to interact with it just completely blocked at the browser end. It took a while to figure out that this was due to an arcanity called Cross-Object Resource Scripting (CORS). I confess to not fully understanding what this is, but the way Cursor had used React meant that it had to work. And it didn’t.

I spent ages googling, and trying to get Cursor to understand the problem and fix it. But it just kept going round in circles, telling about all kinds of completely irrelevant possible solutions. When a browser sees that a CORS interaction is about to happen, it sends a special OPTIONS request to find out whether the target is willing to support it. It’s just a question of adding a couple of text lines to the HTTP header. But whatever I did, these magic lines absolutely would not appear in my server’s HTTP response.

Finally, after a couple of hours, I discovered why, in the Crow documentation (which of course I hadn’t read before). Turns out that Crow refuses to let you modify the response to an OPTION request. I’ve no idea what the logic behind this is, but it makes it useless for this particular use case.

So… I said to Cursor, “generate the server for me using a package other than Crow”. It hit upon another package called Pistache, and generated the code to use that instead. The next hour or so gave me my best “typing yes” practice. The initial implementation wouldn’t build. Cursor identified an incompatibility between the code it had written and the version of Pistache it had installed. It then alternated between fixing its own code, and trying different versions and builds of Pistache. We went round that loop about 20 times before finally getting Pistache to work.

It turns out that Pistache is perpetually at version 0.99.xx, with the 'xx' varying on a daily basis and with an advertised total absence of backward compatibility. But in the end, it did work. I have absolutely no idea what I would have to do if I wanted to re-create the build environment.

Very quickly after that I had a rudimentary Wordle page that worked the way I expected it to, which was a pleasant surprise. I had spent maybe four hours of actual work, including the frustrating session with the useless Crow library.

Extensions

Now it was time to add all the extra functionality I wanted. The first things I added were how many possible words remain, and some suggestions for the best next word to try. Both can be turned on or off via respective checkboxes. Cursor did a great job here. It generated both the front-end and the back-end code and it took only a couple of iterations to get it to work properly. I was duly impressed.

The next item went much less well. The Wordle guesses are shown in a grid, with one word on each line, each cell coloured appropriately based on whether the letter is in the right place, the wrong place, or doesn’t appear at all. On the New York Times phone app, you type directly into the next, empty line in the grid. But Cursor had created a separate text box where you type, which then gets copied into the grid based on the result delivered by the back-end.

That’s functional, but not very pretty. I told it to make letters appear directly in the grid. It thought for a while, and generated a bunch of code. Nothing worked. You typed, and nothing appeared anywhere. It had explained that the text box was still there, and you’re still typing into it, but it’s hidden, and there’s code to move the letters into the right place as they are typed. Fair enough, if it works - but it didn’t.

It took a lot of iterations to get this to work as it should. But still, the letters weren’t being coloured based on the result, which defeats the whole purpose. And in the middle of trying to fix this, Cursor got stuck, running at 100% CPU and doing nothing. It often takes a while to figure stuff out, but this lasted for over an hour. I terminated it and restarted it. Coincidentally or not, soon afterwards it said that the log was too long and I would have to delete it to continue.

Left with no choice I did exactly that. But it wasn’t a good move. All the prior context of what it had done was lost. When I now said that the colouring wasn’t happening. it went off on several tangents to do with the code that colours CLI output, which is completely irrelevant to the web version. That was a very frustrating 10 minutes of saying “it’s your code that’s broken, nothing to do with this other class.”

Finally, in an oops moment, it realised it had changed the front-end code to expect a vector of guess results, but hadn’t changed the back-end accordingly. Once discovered, it was easy to fix. But it had taken most of an afternoon to get that far.

I once had a colleague a bit like that. He was a smart engineer and most of his work was good, but he would invariably break something, somewhere. When I pointed that out, he was very apologetic and rushed off to fix it - promptly breaking something completely unrelated. After he had left our company, his legacy included the most subtle, complex Heisen-bug I have ever experienced. It took over a week to find, finally done by reading every single line of every commit he had made in his final year with us. And even then it wasn’t obvious. Working with Cursor gives me a similar feeling.

After that unpleasant interval, though, things went amazingly well. I wanted to add a picture of a keyboard, with letters known to be inapplicable greyed out. I told it exactly that, no more, and it got it right first time. Even the aesthetics were good. Then I asked it to make the keyboard clickable, as a way to enter letters instead of typing them on the keyboard. That also worked perfectly first time.

Having got that far, I decided to pause and write about what I’d down, before I forgot it all. There is still plenty left to do. My first experience of vibe coding has been pretty positive. In a couple of days I’ve done something that would have taken weeks, and which in practice I would just never have done.

The Kingdom of Two Sicilies

We were recently in and around Naples. Inevitably you learn about local history, and not only Pompei and Herculaneum. And so you learn that in the first part of the 19th century, Naples was the capital of the Kingdom of Two Sicilies.

A quick look at the map will confirm two facts you probably already knew: Naples isn't in Sicily (either of them), and there is only one Sicily. So, why was there a Kingdom of Two Sicilies, and why was Naples the capital?

And thus begins a long descent into Wikipedia and Italian history - although Italy, as a country, didn't exist until 1861. Which, not by coincidence, was the end of the Kingdom, whose existence lasted just 34 years from 1816.

It all started in the year 999, when Norman pilgrims returning from Jerusalem happened to be staying with Prince Guaimar III in Salerno, south of Naples. While they were there, the city was attacked by Saracens. The Normans, who were made of tougher stuff than the locals, ridiculed and attacked the besiegers, in an episode reminiscent of John Cleese in Monty Python and the Holy Grail.

Yes, this is the same Normans who a few years later invaded England, winning the Battle of Hastings in 1066 and placing England under Norman control for the next couple of centuries. They were evidently a pretty convincing bunch in battle. It's a long way from Normandy to Sicily, but they got about a lot.

After their help to the Prince of Salerno, the Normans were welcome back any time. Comparing Sicily - lovely weather, great food - to Normandy, it's understandable that plenty of Normans fancied a visit to see for themselves. Mediterranean tourism is nothing new, even before Ryanair.

The history of the period immediately following is very confused. There were a lot of battles, during which the Normans gradually accumulated more power and territory. What is certain is that in 1061, Robert and Roger Guiscard took control of Sicily from a bunch of feuding fiefdoms. With Sicily as a base, they gradually moved the boundaries of their local empire eastwards and northwards. In 1077 they reached Naples and took control of it. In 1130, the Kingdom of Sicily was formally established with the blessing of Pope Innocent II. Its capital was Palermo, which is definitely in Sicily.

The Normans evidently got fed up with Sicily. In 1198 the throne passed to Frederick II of the House of Hohenstaufen. As you may guess, he wasn't Sicilian. Their base was in Swabia, their capital near present-day Stuttgart. They were in turn replaced by Charles I of Anjou in France in 1266.

Things came to a head in 1282, when the Sicilian population got fed up with all this remote rule and threw them all out in the War of the Sicilian Vespers (Lambrettas were still a few centuries away). The throne of Sicily passed to Frederick III of Barcelona. Remote working is nothing new.

It took a while for the dust to settle, at the Peace of Caltabelotta in 1302. The Kingdom of Sicily was divided into two parts, the island itself and the mainland part. But the subsequent naming was surreal. The island part became officially the Kingdom of Trinacria, though still generally referred to as the Kingdom of Sicily. The mainland part was officially called... the Kingdom of Sicily, though generally referred to as the Kingdom of Naples. Makes perfect sense, n'est-ce pas?

This odd state of affairs had a very long life. In 1759, the King of Sicily (meaning Naples not including Sicily) was Charles VII of the House of Bourbon, which is to say French. But then he got king-hunted, and decided to take the offered new job as King of Spain. That left a vacancy in Naples, which Charles filled with his son Ferdinand. One of Charles' last acts as King of Naples was to start the construction of the largest monument to megalomania in Europe, the Palace of Caserta, just north of Naples. The building itself is vast, with over 1200 rooms, while the Versailles-like garden stretches over 3 kilometres.

In 1799, Napoleon attacked Naples and briefly took control of it. Ferdinand was forced to flee to Sicily (the island), which was protected by the British under Nelson. Sicily was a British protectorate from 1806 to 1814, which I suspect not many people in Britain know.

In 1815 Napoleon was defeated and the British lost interest in Sicily. Ferdinand took control again. His stay on the island evidently hadn't endeared it to him, because he took the opportunity to wipe out the other Kingdom of Sicily and to take control of both of them. The resulting joint venture he renamed (as you may have guessed) the Kingdom of the Two Sicilies. The islanders understandably weren't keen on this and revolted, but this and subsequent rebellions were brutally suppressed by Ferdinand and again by his son, Ferdinand II with support from Austria.

The Kingdom of the Two Sicilies only had a short life, though. In 1860 Garibaldi, as the head of the new united country of Italy, attacked and conquered Sicily. In 1861, everything became part of the Kingdom of Italy. If you'd like to know more, I suggest starting with the Wikipedia article. You will soon find yourself drawn into the complete history, as I was.

Quantum Computing and Navigation - the State of the Art

I was fortunate to get tickets to the Economist's "Commercialising Quantum" conference on 13/14th May 2025. Over two days there were presentations and panels from people from manufacturers, researchers and other industry figures. Like all conferences, it was a bit of a mixed bag. But here are the main points that struck me.

When Will it be Useful?

Realistically, "quantum superiority" for a limited class of applications is probably 3-5 years away. IBM said 3, they're probably being optimistic though. "Q-Moore's Law" seems to hold - the number of qubits roughly doubles each year.

Strong consensus that the likely first application is chemistry and materials science (which is just a special case of chemistry anyway). For this you don't need anything spectacular, as soon as you have enough reliable ("logical") qubits to do more than conventional computers can (say 30-40), you have something you can use.

Error Correction

Raw physical qubits are extremely unreliable - error rates of 10^-2 or worse. To make it useful, you need very powerful error correction. Masses of effort in this right now. The problem is that first, it takes a lot of physical qubits to create a single usefully-reliable logical qubit, and second, error correction is (relatively) slow. That matters, because for some technologies you only have microseconds before the whole thing turns to mush due to decoherence.

People talked about "logical qubits" without saying what they meant in terms of physical per logical. You can build a logical qubit (lqubit) with nine physical qubits, but it won't get you anywhere close to the reliability you need. Current estimates are that it will take 100-1000 physical qubits to make one useful logical qubit. So if your problem needs 100 logical qubits, you need at least 10,000 physical qubits. It's worse than that. To achieve an overall say 10^-2 reliability, the reliability you need from each logical qubit increases with the number of them. So the number of physical qubits you need increases with the square of the complexity of the problem.

One company (Riverlane) has built an off-line error correction box, a 1U package using lots of FPGAs for speed. It sounds improbable, but they claim it works. You still have to program all the guard-bits in your quantum program, which is non-trivial, but they take care of the decoding.

How - Quantum Technologies

There are several competing raw physics approaches to building a quantum computer: superconducting, neutral atom, photonic, topological, trapped ion, quantum dot. There is a good survey article here . They all have been made to work at "toy" scale, and they all have $Bs of investment and serious companies (MS, Google, IBM, ...) behind them. They all have serious drawbacks, and none have been made to work at useful scale.

Clearly there will eventually be a winner, maybe two. I think it's fair to say that at this point nobody (who doesn't have a dog in the race) has the faintest idea which. It's not even certain that ANY of them can be made to work at scale, though given the $$$ and sheer number of quantum physics PhDs being thrown at them, something will probably emerge.

Crypto

THE talked-about QC application is cryptography, or rather breaking it. The nirvana is (relatively) rapid factorization of 2048-bit RSA public keys. It's still a long way off. Right now the estimate is that it will take about 10 million physical qubits. Assuming Q-Moore's Law, that is 15 years away. Supposing improvements in algorithms and error correction reduce that by a factor 10, call it 10 years. Still a long way off. (And "rapid" means in several hours, not seconds or microseconds).

Even so, there has been a lot of work on "post quantum cryptography" (PQC), i.e. cryptography which is resilient to attack using quantum techniques. NIST in the US has blessed several techniques. My guess is that the world will move fairly rapidly to using these, say within the next 3 years. That matters because for really critical stuff (like defence designs), state actors are already storing encrypted data hoping they'll be able to decode it "one day".

QC and AI

There were several sessions claiming to talk about this, but all the ones I attended were content free. Everyone agrees that QC will be part of the AI toolbox, but beyond that nobody had much to say.

Deployment

There were several companies proposing different kinds of "make QC usable for you" services and techniques. I'm 100% sure that this is the only way any "normal" software engineers will ever be able to use it, so this will be a big market. One day. 

Non-Computing Stuff - Quantum Navigation

Several sessions were about quantum-based navigation, i.e. getting GPS-like benefits without needing external radio signals. This is a huge deal because there are large parts of the world where GPS is unusable due to jamming and spoofing. There are two techniques, both dependent on fairly miraculous quantum technology. One is quantum INS - building accelerometers and gyroscopes that are orders of magnitude more stable than you get with classical techniques. The other is quantum gravimetry - measuring the local strength of the earth's magnetic field. Using that, you can relate your position to a map (which are available) and have a position accurate to within a few hundred metres.

The technology of quantum gravimetry is really mind-boggling, but a bit long to fit in the margin here. Basically it involves measuring the difference in position between two superposed quantum states of the same atom. If that seems reasonable to you, you have your head around quantum stuff a lot better than I do.

Rediscovering the PDP-8

During my second summer at university, when I was 20, I worked for a local company that owned a DEC PDP-8 computer - in fact, two of them. The PDP-8 was the original minicomputer, sitting in just a single 19-inch rack as opposed to the whole building that our university ICL 1905 mainframe required. By today’s standards it was unimaginably constrained, with just 12K bytes of memory. Yet the company produced complex documents such as bills of materials on their PDP-8, for the architecture outfit that owned them.

They had started with a PDP8/I, and when I was there they had just acquired a newer PDP8/E, primarily as a way to get high-capacity disk storage using the RK05 removable disk. High capacity is a relative term. The disks held 2.5 megabytes of data - about a millionth of a modern hard disk, on a huge removable cartridge about 45 cm across.

My first job was to rewrite their existing sort program to use these new disks, which improved performance by a factor of about 100 due also to some moderately clever programming. My second job was my first taste of system level programming. DEC had supplied an interface between the two machines, allowing data to be passed both ways, but it came with no software at all. I wrote drivers allowing each machine to see the other’s peripherals as if they were directly attached. This meant that a program could access the new disks as well as the older peripherals on the PDP8/I, such as the lineprinter and high speed paper tape reader and punch.

Back at university, there was another PDP8/I, with a graphics display built around a Tektronix storage tube (the KV8I). I took advantage of that to implement Conway’s Game of Life, squeezing as much functionality and capacity as I could into the machine’s 8K 12-bit words. That became my final year project for my Computer Science degree. It really pushed to the limit what could be done with such a tiny machine. Many years later I rewrote my program in C++ for Windows as Winlife32, still available on the web and downloaded from time to time.

A Career at DEC

My summer vacation job turned out to have a big influence on my career and the rest of my life. I really enjoyed working with the DEC machines, and when it came time to look for a job a year later I applied to them. I had no idea what jobs might be available, so I pretty much said, “Do you have any jobs for a new graduate?”. As it turned out, the senior programmer at the vacation job had moved to DEC in the meantime, and gave me (I suppose) a glowing reference. DEC offered me a job, in their small European software development in Reading. It had the highest salary of the various jobs I’d applied for, and on that basis I went to work for them. I spent the following 20 years working at DEC, on the IAS operating system and several network products, and enjoyed nearly every day I worked there.

But the PDP-8 was at the end of its life. It had been replaced by the larger and much more capable PDP-11, and all my work was for that until it was in turn replaced by the VAX a few years later. We didn’t even have a PDP-8 in Reading. So that was the last I saw of it.

The PDP-8 had a very clever architecture. With a 12-bit word it could only find space for 6 different memory-access instructions. The two most basic memory-access instructions, from the 1950s until now, are LOAD and STORE, to move a value between memory and a register. The PDP-8 had neither. LOAD was replaced by ADD, which added the memory value to the accumulator. To load a value, you first had to make sure the accumulator was already zero. There was an instruction to do that, but the STORE instruction was replaced by DCA (Deposit and Clear Accumulator), which also left the accumulator clear. This substantially reduced the number of instructions which would otherwise be needed to clear it explicitly, though it can catch you out.

In addition to the 6 memory-access instructions, it had a bewildering variety of “microcoded” instructions, where setting various bits would do things in a well defined sequence. For example the sequence “CLA CLL CMA RAL” would clear the accumulator, complement it, and rotate it left without introducing a low order bit, leaving the octal value 7776, or -2. Others would skip the next instruction based on some condition, so for example to jump somewhere if the accumulator is zero, you would write SNA (skip if non zero) followed by an unconditional jump.

My project to connect the two PDP-8s led to an interesting discovery. The hardware involved wasn’t a standard product. It had been specially built for us by DEC’s custom hardware group (CSS) in Reading. Sometimes my code worked perfectly. Other times it would hang in mysterious ways. Finally I attacked the hardware itself, with the only equipment we had - an old-fashioned, huge Avo multimeter. Carefully following the schematics that had been supplied with it, I attached a probe to a pin to see whether it was on (5V) or off (0V). It showed about 3.5V, halfway in between. In a digital circuit, this is impossible. Further probing showed that the “5V” power supply rail was in fact at 3.5V. With a bit more tracing, I discovered that the unit had been built for 220V, but had been connected to the internal 110V transformer.

That explained why it worked sometimes and not others. If the mains voltage was high, for example mid-afternoon, then the “5V” supply reached just high enough to make things work. But at lunchtime or late afternoon, when the power demand was higher and the voltage was a bit lower, the poor thing just couldn’t quite get its logic circuits to work.

A call to DEC, and a visit from their very apologetic engineer, fixed things. After that my software worked perfectly.

A New PDP-8

My PDP-8 knowledge remained lurking in a back corner of my mind for 50 years. A few years ago someone produced the PiDP8, emulating the PDP-8 hardware on a Raspberry Pi and completing that with a 2/3 scale replica of a real PDP-8/I front panel, all 92 lamps and 21 switches of it. Later they did the same for the PDP-11/70, and just recently for the 36-bit PDP-10. A friend of mine has a PiDP11 running the IAS operating system that I worked on soon after joining DEC.

The emulation uses Bob Supnik’s SIMH system. He has been maintaining and extending this ever since long before demise of DEC in around 2000. It can emulate every system ever made by DEC, and dozens of others too. It also understands all the common peripherals, so you can connect simulated disks, tapes and paper tape.

And then a week ago, completely unexpectedly, a friend gave me a PiDP8. The panel comes in kit form, so every one of those 92 lamps and 21 switches has to be soldered into a board, along with a few auxiliary components. That took a couple of days to complete. Meanwhile, I already had a Raspberry Pi4 left over from another project. Amazingly, after 4 years in a cardboard box, it booted up and after a couple of hours was updated with all the latest software.

Installing the PiDP8 software package on the Pi was straightforward, and I got it running - without the unfinished front panel - with no difficulties. Later, though, when I did connect the panel, I ran into a problem. All the lights worked perfectly, but the switches showed a bogus value. This is mentioned in the instructions, which explain that a patch needs to be applied when using the Pi4. So far, so good.

However finding the patch was another story. A quick search found the instructions, but they involved a mysterious source management package called Fossil. Trying to run it showed that the PiDP8 software distribution includes all the sources, but not structured as a Fossil repository - so Fossil won’t run. I have no idea how to use Fossil, and zero interest in learning yet another alternative to Git. Luckily, more searching found the one file that needs to be updated, and it was easy enough to rebuild with the new file.

That done, I had a working PiDP8. The package includes not only the emulator, but also the OS/8 operating system and all associated utilities. Everything worked. But now the question was, what to do with it?  It comes with a few simple games written in Basic. They’re fun for a few minutes but the retro-novelty quickly wears off. The PDP-11 operating systems I worked on all rotated lights on the front panel to make a familiar pattern when the machine was idle, so in a bout of PDP-11 nostalgia I decided to make my PDP-8 do the same thing. (OS/8’s null job is a two-instruction loop that does nothing at all. Memory was much too precious to waste on frivolities).

Rediscovering PDP-8 Assembler

It has been a long time - well over 20 years - since I have written more than the odd line of assembler, for any machine, though I’m familiar with reading it for the x86. The first step was to figure out the logistics of programming the machine. Full nostalgia would have required me to use OS/8’s very primitive text editor. In the 1960s that was an enormous improvement on editing paper type using the ASR33, as we did for the computer I used at school. But that was a step too far

I would create code on the host Raspberry Pi using my regular editor, Emacs - itself pretty retro but I’m used to it and haven’t yet found anything significantly better. I could also assemble it there, using the Palabert port of the PDP-8 assembler. But then I had to move the binary file to the PiDP-8.

A bit of searching showed that the simulator allows you to turn a host file into a simulated paper tape. The PDP-8 PIP program can be used then to read the “paper tape” into a file. (PIP was the standard file management utility on all the DEC systems until VAX). But, as I quickly discovered, it will only transfer text files, not binary. The obvious solution was to transfer the text file, then assemble it with the native PAL assembler.

That still left one problem. In an age when Unicode can represent every known alphabet, thousands of emojis and other weird stuff like ⨔, it’s easy to forget that not so long ago even lower case letters were a rare luxury. The PDP-8’s 12-bit word could hold two 6-bit characters, permitting only upper-case letters. Writing code in upper case is painful, so instead I wrote a little Python program to convert to from lower case, and also to change the line ending to CR-LF. In the days of ASR33 teletypes, these characters physically instructed the machine to move the carriage and roll the paper up, and the PDP-8 utilities expect them.

Finally I could try my code out. It was surprisingly hard to get it to work correctly. Programming the PDP-8 requires a special mindset, which in my case had evaporated over the last 50 years. Numerous times I forgot to clear the accumulator before loading it with TAD, or tried to reuse it after a DCA. I had to re-learn use of the so-called microcoded instructions. For example, to negate the accumulator (often needed since there is no subtract instruction) requires CMA IAC - complement and then increment the accumulator, forming the twos-complement. The CLA element clears the accumulator at the start of one group, but at the end of another group. There’s a good reason for this - the PDP-8 instruction set is truly ingenious. But you have to get your head round it.

Surprisingly, I found my 1970 Small Computer Handbook, which was helpful. Despite the very generic name, it was a complete manual for the PDP-8, describing not only the instruction set in great detail, but also every single one of the numerous available peripherals.

Modern debuggers and IDEs are extremely powerful. The PDP-8 just had ODT (for Octal Debugging Technique), a simplification of the PDP-10's symbolic debugger DDT (a backronym for Decimal Debugging Technique, but really named after the then-universal insecticide, for getting rid of bugs). ODT lets you set a single breakpoint, and requires you to do everything using octal addresses, with an assembler listing in front of you. But for my simple light-twirler it was perfectly adequate.

There was one bug that took me a long time to track down, which turned out to be a function that returned to the wrong place. I’d completely forgotten that there are 8 memory locations (0010-0017) that autoincrement when you use them as index registers for an indirect memory access.  And I was using one to store the return address from a complicated function. So when it executed the usual return instruction - JMP I XXX - it first incremented the return address, then returned, thereby skipping the first instruction after the call. The fix was simple enough, don’t use those autoincrement locations for anything else. They’re there to reduce the amount of code needed to do, for example, a block memory copy - another ingenuity of the PDP-8.

A Working PiDP8/I

I couldn’t stop myself tweaking the program, to twirl the lights in various randomly chosen ways. That done, all I had to do was finish the assembly of the physical machine. Normally the Raspberry Pi is accessed through SSH or, if graphics are required, VNC. But it seems a good idea to be able to access it directly - networks are never to be trusted! So I added tails to the USB, HDMI and power connectors, bringing them out through a slot in the base of the case.

Indispensible tools: Panavise board vice, Antex
temperature controlled soldering iron, desoldering tool

I should add that the PiDP8 kit is really excellent. The instructions are very comprehensive, all the parts were present with even some spares, and everything is very high quality. It's a lot of soldering, 92 LEDs, 21 switches, and various other bits. It is much easier if you have a suitable board vice, and a powerful temperature-controlled soldering iron.

Now my PiDP8 sits on the corner of my desk, next to my 1950s-vintage Olivetti Divisumma and my Nixie tube clock. Its simulated incandescent light bulbs twirl gently in a constant reminder of a nearly-forgotten era of computing.

If you have a PiDP8 and want to see your own lights twirling, the program is available on github.

A retro-collection: my Nixie tube clock, the PiDP8, and my Olivetti Divisumma