Computer Lib / Dream Machines at 50

From time to time, Coloured version of the cover art of Computer Lib - a fist over a punched card. Looks like an agitprop poster, I’ve posted snippets from Ted Nelson’s 1974 book(s) Computer Lib / Dream Machines on various social networks but, now it’s fifty years old, it seems like a good moment to pull together some of the eye-catching quotations and reflect on the book(s) a little.

Who is Ted Nelson, and why does a fifty-year-old book on computing matter today? Ted Nelson is probably best-known as the man behind Xanadu, a wildly ambitious hypertext system he first described in the 1960s and has been tinkering with ever since. In a 1995 article, Wired magazine called it ‘the longest-running vapourware project in the history of computing.’ As far as I know, almost thirty years later, it still hasn’t shipped (although Ted Nelson is still alive.)

Magazine spread THE CURSE OF XANADU from Wired, 1995

Computer Lib / Dream Machines is, even by the standards of its age, an odd book. Self-published by Nelson in 1974, its appearance is shambolic but oddly charming, like a samizdat political pamphlet or fanzine. Its hand-drawn headlines, type-written text at odd angles is reminiscent of early editions of the British satirical magazine Private Eye. It is, in fact, two books in one. Which book you started reading depending on which way you picked it up, as they were printed back to back.
a 2 page spread from the book showing its chaotic layout
Computer Lib is more of a political or social manifesto, a treatise on what computing had become whereas Dream Machines looks ahead to what computing could become, focusing on computers as machines for manipulating and creating visual arts and writing.

Both books are fascinating, partly as a snapshot of computing history immediately before the microcomputer revolution (which Nelson saw coming), but also because so much of it still seems relevant today. Much of what he says about the social impact of computing is relevant to today’s AI mania, and he even explicitly discusses AI, then in its infancy, in ways that I think we would do well to be mindful of.

Here’s Ted on ‘cybercrud’ – using computing as a ‘smoke and mirrors’ term to hide ulterior motives. Replace ‘computer’ or ‘cyber’ with ‘AI’ as you read it:

CYBERCRUD.
A number of people have gotten mad at me for coining the term “cybercrud,” which I define as “putting things over on people using computers.”
But as long as it goes on we’ll need the word. At every corner of our society, people are issuing pronouncements and making other people do things and saying it’s because of the computer. The function of cybercrud is thus to confuse, intimidate or pressure. We have all got to get wise to this if it is going to be curtailed.
Cybercrud lakes numerous forms. All of them, however, share the patina of “science” that computers have for the layman.
1a) COMPUTER AS MAGIC WORD
The most delicate, and seemingly innocent, technique is the practice of naming things so as spuriously to suggest that they involve computers. Thus there ls a manufacturer of pot-pipes with “Data” in its name, and apparently a pornography house with a “Cyber-”

2) WHITE LIES: THE COMPUTER MADE ME DO IT
Next come all the leetle white Lies about how such-and-such is the computer’s fault and not your decision. Thus the computer is made a General Scapegoat at the same time it’s covering up for what somebody wants to do anyway.
“It has to be this way.”
“There’s nothing we can do; this is all handled by computer.”
“The computer will not allow this.”
“The computer won’t let us.”
The translation is, of course, THE STINKY LOUSY PROGRAM DOES NOT PERMIT IT. Which means in turn: WE DO NOT CHOOSE TO PROVIDE, IN OUR PROGRAMS AND EQUIPMENT, ANY ALTERNATIVES.
Now, it is often the case that good and sufficient reason exist for the way things are done. But it is also often the case that companies and the public are inconvenienced, or worse, by decisions the computer people make and then hide with their claim of technical necessity.
(Computer Lib, p8)

Sometimes the stand-out anecdotes are just sweet. This story about children interacting with computing resonates with me deeply:

I know a high-school boy (not a computer expert) who programmed a computer to type out a love story, using the BASIC “print” command, the only one he knew. He could not bring himself to write the love story on paper.
The best example I can think of, though, look place at the kids’ booth at a computer conference. One of the more withdrawn girls was sitting at an off-line video terminal, idly typing things onto the screen. When she had gone a sentence remained. It said:
I love you all. but at a distance.
|—————————————————|
(Computer Lib, p9)

This next idea is also intriguing – that computers need not have been named after humans who carried out mathematical operations. They could have been called something else:

THE ALL-PURPOSE MACHINE
Computers are COMPLETELY GENERAL, with no fixed purpose or style of operation. In spite of this, the strange myth has evolved that computers are somehow “mathematical.” Actually von Neumann, who got the general idea about as soon as anybody (1940s), called the computer THE ALL-PURPOSE MACHINE. (Indeed, the first backer of computers after World War II was a maker of multi-lightbulb signs. It is an interesting possibility that if he had not been killed in an airplane crash, computers would have been seen first as text-handling and picture-making machines, and only later developed for mathematics and business.)
We would call it the All-Purpose Machine here, except that for historical reasons it has been slapped with the other name.
But that doesn’t mean it has a fixed way of operating. On the contrary, COMPUTERS HAVE NO NATURE AND NO CHARACTER, save that which has been put into them by whoever is creating the program for a particular purpose. Computers are, unlike any other piece of equipment, perfectly BLANK. And that is how we have projected on it so many different faces.
(Computer Lib, p10)

Perhaps we would do well to remember that AI systems, even generative AI systems, are also perfectly BLANK until trained – by humans.

Nelson offers this ‘helpful comparison’:

A HELPFUL COMPARISON.
It helps sometimes to compare computers with typewriters.
Both handle information according to somebody’s own viewpoint
Nervous Question: “Can a Computer Write a Poem?”
Helpful Parallel: “Can a Typewriter Write a Poem?”
(Sure. Your poem.)

“Can’t Computers Only Behave Mechanistically?”
“Can’t Typewriters Only Behave Mechanistically?”
(Yes, but carrying out your intent.)

“Aren’t Computers Completely Impersonal?”
“Aren’t Typewriters Completely Impersonal?”
(Well, it’s not like handwriting, but it’s still what you say.)
(Computer Lib, p10)

What might a helpful comparison for AI look like?

Nervous Question: “Can AI Write a Poem?”
Helpful Parallel: “Can a computer Write a Poem?”
(Sure. A poem trained on poetry written by the programmer or other internet-connected humans.)

Nervous Question: “Can’t AI Only Behave Mechanistically?”
Helpful Parallel: “Can’t Computers Only Behave Mechanistically?”
(Yes, but carrying out the designer’s intent.)

Nervous Question: “Isn’t AI Completely Impersonal?”
Helpful Parallel: “Aren’t Computers Completely Impersonal?”
(Well, it’s not your thoughts, but it’s still what other humans might say.)

In Dream Machines Nelson tackles AI head on. I think this stands up pretty well for something written fifty years ago.

THE GOD-BUILDERS!
ARTIFICIAL INTELLIGENCE… sort of
“Artificial Intelligence” is at once the sexiest and most ominous term in the world. It chills and impresses at the same time. In principle it means the simulation of processes of mind, by any means at all; but it generally turn out to be some form or another of computer simulation.
Actually, “artificial intelligence” has generally become an all-inclusive term for systems that amaze, astound, mystify, and do not operate according to principles which can be easily explained. In a way, “artificial Intelligence” is an ever-receding frontier: as technique become well-worked out and understood, their appearance of intelligence, to the sophisticated, continually recedes. It’s like the ocean: however much you take out of it, it still stretched on — as limitless as before.
Unfortunately laymen are so impressed by computers in general that they easily suppose computers can do anything Involving information. And public understanding is not fostered by certain types of stupid demonstration. One year I heard from numerous people about how “they’d seen on TV about how computers write TV scripts”- what had actually been shown was a hokey enactment of how the computer could randomly decide whether the Bad Man get shot or the Good Guy gets shot — both outcomes dutifully enacted by guys in cowboy outfits. Duh.
(Dream Machines, p12)

Computers don't actually think. You just think they think. (We think).

Computers don’t actually think.
You just think they think.
(We think).
(Dream Machines, p12)

Thinking about AI was not new in 1974, but the field was about to enter one of its ‘winters’ where innovation stalled, which makes Nelson’s timeline of AI past, present and future fascinating to read today. Can someone tell me, are we at ‘sexy unknown’ or ‘El Beyondo’ now?
a hand-drawn timeline of AI development showing 1974 as being in a phase of neural nets, and the future having flatworms, frogs, dogs and humans. In the far future, 'El Beyondo', there are gods and supergods.
Just as early 1970s computing magazines like People’s Computer Company / Dr Dobb’s Journal are full of things that are unexpectedly relevant today, Ted Nelson’s Computer Lib / Dream Machines is full of nuggets that make me wonder what the world would have been like if he’d been more listened-to, and indeed more successful.

In a similar vein, of paths not taken, I commend this 2013 video, imagining what a talk on the future of programming given in 1973 might have looked like:

Has Computer Lib / Dream Machines really aged well? Well, no. There’s plenty of sexism in there. There’s language that we would not tolerate today, although its context justifies at least reading it today, if not re-posting it. But I guarantee that if you have any interest in the social impact of digital technology, or just its history especially in the creative arts, if you scroll through it, you will find something to surprise or interest you. There’s a lot on cathode ray tubes, for example. CRTs are now obsolete technology, but I read Ted Nelson with a tinge of regret at what we’ve lost: light pens and vector graphics, purer than any blocky, pixellated bitmap rendition of a geometric shape.

A Ladybird book diagram of all the different spheres computing touches, such as space, weather and a similar hand-drawn diagram by Ted Nelson.

1971 Ladybird book on computers (left) and a diagram from Computer Lib (1974) that reminded me of it.

Useful links

Computer Lib / Dream Machines at the Internet Archive: https://archive.org/details/computer-lib-dream-machines/page/n93/mode/2up

The Curse of Xanadu, Wired magazine, 1 June 1995: https://www.wired.com/1995/06/xanadu/

How it Works: The Computer (Ladybird Books, 1971) at the Internet Archive: https://archive.org/details/How.It.Works.The.Computer.1971.Edition.David.Carey/page/n39/mode/2up

People’s Computer Company / Dr Dobb’s Journal magazines at the Internet Archive: https://archive.org/search?query=creator%3A%22People%27s+Computer+Company%22

Posted in computers, nostalgia | Tagged , , , , , | Comments Off

Surias – writing a program can be fun!

Me in 1981 using a Commodore PET to play Surias.

This is an unpublished article I wrote in around 1981 about a game my brother and I wrote for the Commodore PET. I am yet to find a program listing or cassette for the game, which I would love to spin up in a simulator! Incidentally, the Chris Howland mentioned in the article turns out to have quite an interesting life – born in Britain he became quite famous in Germany as a DJ, musician and actor.

After the initial novelty of having a computer in the house wore off, realising the limitations of the system (i.e. ‘IT’ wouldn’t wait on us hand and foot, answer the door, write best-selling war games) we thought about writing a good, solid, and maybe even an epic (-ette, -ish, sort of) program. Perhaps that was a mistake, but this is the story of our program, and how it was written. This is the story of SURIAS. A legend in its own FOR/NEXT loop.

Around the end of 1978 (yes, that long ago!), we (my brother Laurie, and myself) felt there was a lacking of interactive war games (except the infamous Star Trek) for the PET. This, of course, means the 2001 series (8k). We still have our old PET, and so this program runs in 8k, and was written in the old BASIC, although only two lines don’t work for new ROM PETs. A friend of Laurie, Andrew Shorney, who, by a meaningless coincidence, writes programs in COBOL for a supermarket chain, and himself, were in a pub getting rather drunk. (If there are any eligible Surias followers out there, it was the Naval Volunteer in Bristol). Andrew came up with the concept for the game. That was just the idea that you move armies from one county to another, and you have a stronghold, to which troops arrive by sea, and that the army of Surias has to defend its own country. You are, therefore, invading a country, in a time when the two opposing sides confronted each other on the battle field.

The name ‘Surias’ was invented, also, by Andrew (It’s an anagram of a certain large, well-known communist country). One evening Laurie told me the concept, but he couldn’t remember the name. “It’s an anagram of a large Communist country’: he said. A few minutes later I said “Surias?” I had re-discovered the name, and therefore claim a tiny fraction of the fame for the name. One Sunday, after lunch, Laurie took our PET over to Andrew’s house. By that evening the PET was back in our house with the map graphics on tape. Full credit for the graphics must go to Andrew, who before then, had never used a PET. Influenced by Chris Howland’s ‘Something Bit Me’ we began to try to write Surias.

That was a mistake.

A few days later: “We’re just being far too ambitious. It’s impossible”

Six months later. With the added knowledge of dimensioned variables (things like ?V(X) ) I decided it was possible to write Surias on our PET. Yes. Dimensioned variables, or as I call them, variable variables, they were the thing. In a few days time you could move troops, and it would print the numbers on the screen.

Now a few words to those thinking of writing a game on any computer, but especially the PET. A ‘Programmer’s Toolkit’ is very nice, and it makes life a lot easier, but it is not a necessity. To be honest, renumberers are necessary, but machine code versions on tape are just as good. Access to, or preferably ownership of, a printer is a huge help. We got our printer about halfway through the development. The toolkit came too late to be of much use.

Now back to the development. I put in the tests to check if there were enough armies in a particular county, and soon ‘Surias’ began to take shape.

Co-writing a program is a good idea. Many a time I would declare something impossible, returning a few minutes later only to find that Laurie had solved it.

Probably the biggest mistake we made, apart from starting on this whole venture in the first place:, was to structure the program badly. This is a direct result of not thinking how we would tackle each section of the program, in advance. I know that is the correct procedure, but those who are against letting a program take shape as it is written are probably the ones who stated a few years ago, that it was bad programming practice to use a ‘GOTO’ statement in a program. This may sound odd, but programming is more fun this way. Certainly, it is a lot less efficient, but programming becomes more of a pastime when done in this way. Heaven forbid, though, if people like Andrew wrote their COBOL programs that way!

There are many classics of space wasting in Surias. There are two different sections for winning and losing, with statements like “BATTLE IS UNDERWAY, SIR” being repeated. The table of POKE locations for the screen is repeated, but you need only enter it once, and change the line numbers for the second, or not at all, if you see the end of this article. These ‘faults’ are mainly due to the lack of a printer and toolkit when the main program was structured. The most useful toolkit function, apart from RENUMBER, we found to be FIND, which will find any variable, word, command, sentence, etc. in the whole program, and list it.

Soon the program was playable, and feeling pleased with ourselves, we showed it to my brother-in-law, saying we had just bought it from that PET orientated SOFTware house, for £5. He played a game, and remarked on what a bargain it had been. He now, of course, knows that we wrote it, and has a version running on his Nascom-1 under Xtal Basic. My other brother, Ashley, who has a KIM, has yet to implement Surias on his machine!

The July 1980 cover of Practical Computing magazineThe program was left alone for some time, but then we started making little additions. The random sundry assorted disasters, for instance, or the summer and winter messages. One day we took our big box of software over to a friend’s house, Ken Otway, who looks exactly like the Tuscan designer on the cover of July 1980 Practical Computing. We showed him our latest version of the game. He gave us two very good ideas to improve it, incorperated in this version. One was to have battle reports being printed at the bottom of the screen, instead of the screen clearing every time. The other was to have something flashing on the screen where a battle is taking place. Should you be embarking on the process of writing a game, get as many people as possible to play it, and make suggestions.

The program is in no way intended to be at all historically accurate, or geographically correct.

February 1981: Shock! Horror! Bug Time

“Here,”said Laurie. “Get this American Cream Soda down you…you’re going to need it.”

I needed it. He had just discovered that if you capture counties 1-6 in any order, you won the game instantly. (Well as quickly as it takes to get counties 1-6). Bye bye, good times. Hello headaches.

April 1981: What was wrong with the program, is really rather embarrassing.

Many moons ago, when you could only hike through the galaxy on radio, I had this ace little routine that stopped any enemy armies accumulating in county 6, if you surrounded it. There was, however, a little snag…it didn’t work! Ho-hum. What could we do when inquisitive hackers asked what the routine did? “Oh yes,”came the reply. “That’s our fingerprint routine:” And there it remained. Infact, it was that, combined with line 550 being where 3395 is now, that messed it all up. The line to check if county 6 was lost had always read:
IF N(6)=0 THEN 1870

Due to friendly negative numbers popping up, we changed it to:
IF N (6)<=THEN 1870
...only going to prove that we're human, I suppose.

I hope you enjoy the game, and to save you thinking them out, here are some suggested alterations:

a) Give yourself more armies. (Line 270)

b) Give the PET fewer armies. (Line 310)

c) Make a 'disaster' less likely to happen. It stands at 1 in 20 at the moment. To make it, for instance, 1 in 50, change line 2170 so:
2170 PY=1:M0=51

Other possible refinements, if you have the memory, and/or money, could be CB2 sound, light pen (we've got one, but not enough memory to add the facility!), levels of difficulty, colour graphics, hi-res, and so on. Perhaps you might prefer "'Ark at they soldiers, sire:" in line 1520. There's no accounting for taste...

Thanks once again to Andrew Shorney, for thinking up the concept at Gateway's expense, and doing the map, Ken Otway, for helpful advice, and to Roger Horsman, for making us feel like well-known Pet Pundits. Also to Chris Howland, another 'calcaholic' like myself, and for giving us the sheer nerve to write a program.

Posted in computers, nostalgia | Tagged , , , | Leave a comment

Noughts and crosses

The cover of 6502 games, a bitmap style picture of a cowboy being shot.I just inherited a load of books on programming the 6502 processor in assembly language (and a Kim-1 computer, more on that later!). Among them was an intriguing 1980 book by Rodnay Zaks called 6502 Games. Zaks wrote what, for many, is the default text book on programming the 6502, but this book is a bit more playful.

The Games Board for the Sym-1 computer

The games in this book are based around a hardware accessory for the Sym-1 computer. The Sym-1 was very much like a Kim-1, a 6502-based development board. (Intriguingly I read somewhere that it could use an oscilloscope as a VDU, I’d love to know more about that!) The Sym-1 Games Board consists of a bunch of LEDs and a number keypad, and even though I don’t have one of those, nor a Sym-1, the book itself is interesting.

A page from the book where Zaks discussed artificial intelligence

I just noticed that the Games Board seems to be made by Sybex, who published the games book. Maybe this book was just a ruse to sell hardware. Anyway…

The most complex game is in the final chapter: ‘tic tac toe’, or noughts and crosses as we call it in the UK. Artificial intelligence long pre-dates this book, of course, but it’s interesting to see the term used here to describe a computer playing a game. It got me thinking about two approaches to solving this problem, which he discusses:

1) A heuristic approach, where the computer learns from its mistakes. This is, I think, how LLMs work, by training on huge amounts of data. It’s also how the matchbox-based noughts and crosses engine, MENACE, works. Often these systems come up with models that the creators of the tools don’t themselves fully understand. This approach takes time and a lot of memory, something lacking on a 1980 home computer. (By the way, there’s a great video of Matt Parker demonstrating MENACE to Professor Hannah Fry in the 2019 Ri Christmas Lectures).

2) A human-programmed algorithmic approach. This requires much more thinking by a human programmer, who needs a deep knowledge, in this case, of how to play the game and all its possible strategies and outcomes. The human applies the usual skills of computational thinking to solve the problem of how to get a machine to play a game that normally humans play.

So which approach is best? Zaks’ hand was forced down the second path due to lack of computer memory, but it strikes me that – if the problem is simple enough – it’s best to take the human-programmed route. The designer learns more. The algorithm is not opaque, you can challenge it if you think it’s biased. It’s open to inspection, improvement in a way LLMs, for example, seem not to be.

I don’t think I’ve ever coded a noughts and crosses game, so inspired by Rodnay Zaks’ very thorough discussion of approaches to creating algorithms for the game, I thought I’d have a go at writing one in Python.

Broadly speaking, he suggests assigning a numerical value to each potential square depending on the threat from the human opponent and the machine’s chances of winning. Clever.

I know that what I’m doing here below is not original, it’s purely an exercise for relaxation in creating some simple programs to play a game, inspired by reading a chapter in a very old computer book.

Simplest version

I started by writing a version for two human players, just so I could set up a user interface and handle the board, detecting wins and draws. The code is here.

It just uses a list to store the board, with 9 elements. A dash is used to show an empty square, capital O and X for each player’s marks. It scans each row, column and diagonal to counts Os and Xs, and if there are 3 it knows someone has won. It also counts free squares, so if no-one has won and every square is filled, it must be a draw. You make your move by typing in the number of the square:

012
345
678

Shooting fish in a barrel

As a stepping-stone to a clever machine that can beat me, I created a laughably simple version. In this one, the human plays against the machine which always just picks the first available square. As the human always goes first, it’s incredibly easy to beat.

I have created you and now you will destroy me

Then I tried to implement something much cleverer, and closer to Zaks’ algorithm. I don’t doubt there are much more elegant and compact ways of doing this, but I wanted to code something a child (and I) could understand.

Zaks’ algorithm is impressively sophisticated, especially for a small 6502 assembly language program. It incorporates randomness and the machine varies its skill level depending on how well it’s doing, which makes for a much more entertaining opponent. I decided to do something much simpler.

This clever version has a new list called ‘move_weight’ which it uses to score how good a square might be. It scans rows, columns and diagonals. Squares already played get a score of 0, playable squares 1. An additional point is added if the human already has placed a O on that line. If the human has two Os on the line, it gets an extra 5 points, but if the computer has two Xs on the line and can win, it gets 6.

You can also choose who goes first, human or machine. The human always plays O, the machine X.

It’s a pretty boring opponent, always playing the first square suggested by the algorithm if there’s more than one choice, but it’s also pretty good. When I’m being dozy, it can beat me!

It also prints out the ‘move_weight’ list, so you can see how it made its choice and it also prints out when it thinks it’s in danger of losing or spots a winning square. A typical bit of game play might look like this:

0 1 2    - - -
3 4 5    - - -
6 7 8    - - -

Player O go:
0
0 1 2    O - -
3 4 5    - - -
6 7 8    - - -

Computer thinking...
[0, 1, 2, 1, 1, 1, 2, 1, 2]
0 1 2    O - X
3 4 5    - - -
6 7 8    - - -

Player O go:
4
0 1 2    O - X
3 4 5    - O -
6 7 8    - - -

Computer thinking...
danger at 8
[0, 1, 0, 1, 0, 2, 2, 2, 6]
0 1 2    O - X
3 4 5    - O -
6 7 8    - - X

Player O go:
6
0 1 2    O - X
3 4 5    - O -
6 7 8    O - X

Computer thinking...
danger at 3
winning move at 5
[0, 1, 0, 6, 0, 8, 0, 2, 0]
0 1 2    O - X
3 4 5    - O X
6 7 8    O - X

Game over!
Winner is X

micro:bit version

Using IDLE for the first time in ages made me miss the micro:bit Python Editor, so I made a version for the BBC micro:bit. It uses the serial console for entering moves and it even works in the simulator, as well as showing the board on the micro:bit’s LED display. Bright LEDs are the human’s Os, and dim LEDs are the computer’s Xs. I may see if I can create a version you can just play on the micro:bit itself with no computer attached, and maybe add a bit of randomness to make the computer a more interesting opponent. There’s also clearly scope to use functions to shorten some repetitive bits of code.

Self-contained micro:bit version

I also made a self-contained version that you can play just using a micro:bit V2, with no serial console or computer needed.

It works best with a headphones or speaker attached so you can clearly hear the speech instructions and who wins.

This version only works on a micro:bit V2 with built-in speaker which has more memory.

Press A to go first, B for micro:bit to go first.

Press B to step through possible play squares which blink.

Press A to choose a square to play.

Press reset button on back of the micro:bit to play a new game.

In conclusion

All in all, a nice, relaxing coding activity prompted by a 1980 book on programming the 6502!

Posted in computers, microbit | Tagged , , , , , , | Leave a comment

Raspberry Pi video art installation

My daughter makes video art and needed a simple solution for showing one of her pieces continually in a loop.

I used an old Raspberry Pi model B for this. I just realised that the only place I had documented this was on my now-deleted Twitter account, and I can’t recall where I learned about this method, so I just had a quick look at the machine in question to try and work out what I did to make it. I’m recording it here in case it’s useful to anyone else or, more likely, me.

The Pi has Raspbian Buster on it, no GUI/desktop, just the command line stuff. It needs omxplayer, which I think was installed by default.

I put the source video MP4 file in the default pi user’s home directory. (I may have transferred the file from a USB stick using fdisk to identify and

sudo mount /dev/sda1 /media/usb-drive/

to mount the drive, but you could also probably transfer the file using SFTP, FTP over SSH).

I also doubtless used raspi-config to force the audio to either HDMI or the 3.5mm audio jack, and maybe alsamixer to set the volume level.

The magic happened by editing rc.local:

sudo nano /etc/rc.local

Then I added some lines so it looked a bit like this:

# By default this script does nothing.
# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
  printf "My IP address is %s\n" "$_IP"
fi
omxplayer -o local --loop /home/pi/video-art.mp4 &
exit 0

Now when the Pi reboots, after quite a lot of boot-up text scrolling, the video plays and loops automatically. Connect to your monitor or projector and install in your art gallery!

Posted in Raspberry Pi | Tagged , , | Leave a comment

Why did 1973 matter to Classic Mac OS?

So I was clearing off an old 350MHz graphite Apple Macintosh G4 Server which had OS 10.4.9 on it, and decided to put Mac OS 9.2 on it for the lolz.

This was a mistake, as I had been intending to sell it, but now I am discovering old software, games and artwork I made many many years ago.

One thing that intrigued me was this dialogue box that popped up:

Mac OS 9 error message that the clock is set to a date before 1973

The motherboard’s battery long since died and I removed it, so the system clock goes back to its default setting. But why does Mac OS care if the clock is set to a date before 1973? Why 1973 specifically?

1970 is a significant date in computing – midnight UTC on 1 January 1970 is ‘the UNIX epoch‘ base. Time in Unix is measured from this point.

But 1970 is not 1973, and OS 9 is not Unix. (Its successor Mac OS X was, of course, built on Unix.)

I did a bit of digging into dates in HFS+, the Macintosh file system widely in use around the time this machine was made, around the turn of the millennium. Or Y2K if you prefer.

HFS Plus stores dates in several data structures, including the volume header and catalog records. These dates are stored in unsigned 32-bit integers (UInt32) containing the number of seconds since midnight, January 1, 1904, GMT. This is slightly different from HFS, where the value represents local time.

The maximum representable date is February 6, 2040 at 06:28:15 GMT.

The date values do not account for leap seconds. They do include a leap day in every year that is evenly divisible by four. This is sufficient given that the range of representable dates does not contain 1900 or 2100, neither of which have leap days.

So its timestamps start in 1904. And end in 2040. So, some more dates – but neither of them is 1973!

I tried searching the internet for anything about Mac OS and 1973, about the text of the dialogue box and found almost nothing. I did find a TikTok about an old clamshell iBook and this poem by Jeffrey Joe Nelson:

System Note

Your Macintosh’s clock is set to a year before 1973.

This may cause certain of your pomes to behave erratically.

So then I asked around at work, and after kicking around a few ideas, a colleague has, I think, probably solved it.

Look at the wording of that dialogue box very carefully…

Network time error

Your Macintosh’s clock is set to a year before 1973. This may cause certain applications to behave erratically.

[my bold]

Now my colleague reasoned thus:

Counting seconds in a 32 bit number gives you 136 years’ worth of counting.

If the classic Apple Mac OS epoch (zero time) is indeed 1904,  then 1973 would be precisely half way through that range.

If for reasons of temporary insanity, say, a third party developer held that as a signed 32 bit number, anything before 1973 would look negative. Negative time sounds like a dangerous concept. Certainly one that could cause applications to behave erratically.

No-one inside Apple would be so foolish.

But the developer of certain applications might!

I think he’s cracked it! What do you think?

David Tennant in Doctor Who saying wibbly wobbly timey wimey stuff

Updates!

@prozacchiwawa@functional.cafe on Mastodon adds this intriguing comment:

If an app cheaply checked whether subtracting two dates yielded a positive or negative result in signed space, moving the two dates farther apart than half the unsigned space could fool it. I’m wondering if that’s what they had in mind.

For example, 2023 (0xdfeb9580) – 1941 (0x4599a080) yields 0x9a51f500, which might mean to some apps that 2023 is before 1941.

 

 

Posted in Apple, lowendmac, operating systems | Tagged , , , | Leave a comment