Category Archives: Computing

BBC micro:bit – Lunar Lander Project (part 1)

With my godson’s eleventh birthday coming up, I was wondering what would be an interesting gift. A few months ago, J, his little brother N, and I had been talking about passwords. They’d been told at school that it helped to misspell words – so ‘werdz’, say, rather than ‘words’ – and to insert punctuation marks. But why are you being given this advice, I pressed them. This led to some discussion about how a person – or more likely a computer program – might try and guess a password. And this, in turn, led to us writing some code in Scratch, a programming language for kids, that would actually guess passwords. The boys enjoyed themselves hugely. And they were just awestruck by how many brute force guesses were required to crack passwords.

So for J’s birthday, I thought something with coding might be fun. But I also liked the idea of him having something of his own, something not virtual. And so I got to wondering if we could code a game on one of these new breed of tiny computers, such as the BBC micro:bit.

What I had in mind was the sort of game that I had coded up back in the early 1980s using machines such as the ZX80 (my big brother’s), Commodore Pet (at school), Acorn Atom (at John Cupitt‘s), Oric-1 (mine!), and BBC Micro (at JC’s again). This was when I was first learning about programming and you either used BASIC – which was often too slow or couldn’t let you control the screen with sufficient precision – or more likely machine code. Tricky, but rewarding when you finally got things to work.


So I started doing some research on-line. It turns out that you can buy tiny displays and it looked, in theory, as if I could connect one of these to the micro:bit and make it work. I reckoned that if I could hook up a 128 x 128 pixel display to the micro:bit that would be large enough to make a playable Lunar Lander game.

Before I committed to ordering any parts, I thought I’d do some sort of proof of concept. These days, when I program it is mostly for the iPhone using Apple’s Swift language. So I knocked up the vary bare bones of a Lunar Lander program as an iPhone app, scaling the display size to 128 x 128 pixels. And all seemed OK.

Is 128 x 128 pixels enough for a playable Lunar Lander game? Doing a “proof of concept” on the iPhone.

There remained some uncertainty though. I couldn’t find any definite instructions or a worked example of connecting a micro:bit to any of the displays I’d been looking at. There were things written about doing this for other tiny computers, such as the Raspberry Pi, but not so much for the micro:bit. So I couldn’t yet be sure whether I could actually get the micro:bit to “talk” to a display. But I was getting to the end of what I could realistically do with desk bound research. And so, I ordered two micro:bits and two Inventor’s Kits, one each for me and for J. I also ordered one display to test out. If I couldn’t make it work, then I’d have to come up with a plan B.

Microbits and Inventor’s Kits. One for J and one for me.

Before I wrapped up J’s micro:bit I wanted to try things out and get a sense of how it worked, so I could tell his mum a little bit about it and write a decent note for him in his birthday card. I encouraged J to try out the hardware and follow the instructions on his own. But I also know that what he loves more than anything is doing things with other people. For him, that’s at least three quarters of the fun. And, so it turned out, he chose to wait for my visit – scheduled for a couple of weeks’ time – before breaking the seals on his new toys.

The actual micro:bit really is micro. I was expecting it to be small from the size of the box, but even so I was surprised at how tiny it is.

Back at home, I was figuring out how the micro:bit worked. You write code on your computer, using a special web page. And even without connecting the micro:bit you can see the effects as the page has a “simulator” – an animated picture of the micro:bit that performs, more or less, in the same way as the real hardware. The main thing the micro:bit does is let your create patterns on a 5×5 grid of LEDs, to respond to two buttons and, if you connect some headphones or a small speaker, make noises and play tunes. The simulator lets your try out all these things. And then, if you connect the computer to the micro:bit you can transfer the program to the tiny computer.

There are a few different choices of programming language for the micro:bit. Because I wanted J to be able to do some of the coding himself, I went for the option called the JavaScript blocks editor. The JavaScript language is one I know something about. It’s the language that can be run inside a web browsers and is used to make web pages do all sorts of clever things. And the “blocks editor’ bit means that kids can drag chunks of code around rather than having to type things in word by word.

Great, I thought. What I can do is to develop some code in my web browser using JavaScript and I can simulate the pixel display there. That way, I can write and test code before my display arrives. I went ahead and did this, getting some basic code to paint a lunar lander on the screen and move it about. (If you are reading this on a Mac or a PC, you can see a bare bones JavaScript proof of concept version of the game running in your browser. And you can click through to JSFiddle to the see the code.)

I was greatly encouraged to have my proof of concept up and running, but there was still the question of whether I could successfully connect micro:bit and display.

When the display arrived in the post, the first task was to do some soldering so I could plug it in the “breadboard” and, through that, wire it up to the micro:bit.

Working with hardware is different from working with software. There are fewer second chances and my soldering skills were pretty rusty. But I seemed to get on OK. The most anxious part of the soldering operation was that the ‘connector’ part that came with the display had more pins than there were holes in the display board. I needed to clip off a few of the pins. I’m glad I was cautious and did an experimental clip first, as it turned out it was very easy to overshoot with the clipping.

The next phase of the project was the most challenging. The display is designed to talk to a computer using something called a Serial Peripheral Interface Bus (SPI). I was learning about this for the first time and was not finding many examples on-line of making practical use of the SPI with the micro:bit. Not for the first time, I wondered if I had bitten off more than I could chew.

At root there needs to be some wires between the display and the computer, and signals get sent down these wires to tell the display what to do. At the level of the hardware, I needed to connect some power and then four wires for communication. By following the published data sheet for the display and the micro:bit documentation, I wired everything up. And, at this point, the display actually lit up. This wasn’t telling me anything much, because I wasn’t yet sending any messages to the display to tell it what to do. But it was at least an encouraging sign.

The next phase was to start sending messages – in the form of a series of numbers – to the display to get it to do what I wanted. The people who provided the display provided lots of useful documentation and also some sample code that lets people with computers that are not micro:bits talk to the display. So I had to look at the code and convert it into the JavaScript language that the micro:bit could understand.

Writing about it now, it sounds straightforward enough. And by the time I’d gone through their code line by line, I suppose it was. But it took time and patience. For example, I had to identify what code was essential and what I could set aside. I couldn’t run or test this code, so it was a matter of reading through and making sense of it step by step. To even start the display up at all, required sending a series of numbers. And if any one of them was wrong it was entirely possible nothing would work. And then to get coloured dots to appear meant sending more carefully crafted numbers. Some hours later, I had checked and re-checked the code I had written. It all looked OK, so it was time to transfer the code to micro:bit and see what happened.

And what happened was… precisely nothing at all. The same white screen – yes, I already know the power is working – stared back at me as I stared at it.

Carefully checked code running, all wires attached and no change on the screen. Oh dear.

There was a real moment – indeed an extended stretch – of doubt here. Because at this point I wasn’t sure how many moves I had to make. I’m used to working in software, but perhaps there was some hardware thing that I’d failed to understand. Perhaps my soldering had been shockingly poor. Perhaps, I wondered, I just won’t be able to fix this.

Still, it’s engineering, right. So it’s a matter of coming up with hypotheses as to why it’s not working and testing each one. I checked which wires I’d connected between the micro:bit and the display. Everything was checking out. I got back to the original software provided by display supplier and compared key sequences between it and my code. And then, I spotted something.

One bit of code controls the signal sent down a particular wire that, basically, asks the display to sit up and pay attention. Surely, the pay attention signal would be positive three volts and not zero volts? That is a one instead of a zero. Well, I must have thought this without really thinking, because that’s what the code I’d written assumed to be the case. But as the display supplier’s code made clear, the “sit up and pay attention” signal was a 0 and the “ignore everything, it’s not for you” signal was a 1.

The code change took less than half a minute. Transferring the software to the micro:bit took about the same time again. By this time, I’d also wired up a speaker so the setup made some sounds when the software had transferred. And now, as the beep sounded, so the display transformed into hundreds of random coloured dots. Not quite what I was expecting, but a clear sign that the signals I was sending were getting through. And, amongst the random coloured dots, in red, was the just discernible outline of a lunar lander. I pressed one of the buttons on micro:bit that I had programmed to move the lander a pixel to the right. And again. And, yes, the lander was moving, leaving a trail of blackness behind it. Time for a picture, I thought.

Game On! My code is working and I have something that looks like a lunar lander on screen.

The multi-coloured background is just what happens when the display starts up. I needed to ask it, explicitly, to clear the screen. But I already had code, adapted from the display supplier’s, to paint rectangles of an arbitrary size. Although, even that code didn’t quite work the first time.

An almost clear screen with the lander

At this point I was optimistic about making rapid progress. The plan was to take chunks of the code I’d written for my proof of concept in the web browser and use it on the micro:bit. After all, they both say they use JavaScript.

However, as it turns out, the JavaScript for the micro:bit is a severely stripped down version of the language that runs in a web browser. Just how stripped down became apparent slowly and painfully. So, for example, inside the web browser the JavaScript language understands decimal numbers. And my code relied on the use of decimals all over the place. For example, it relied on decimals in working out how to draw a straight line or how to apply gravity or the force of a rocket booster to the lander. This particular problem was one of the more straightforward ones that I encountered. Instead of relying on fractions, I was able to just multiply everything up and then, when it came to calculating the real pixel position, divide down and round up.

Slowly, the game started to come together. There were plenty of wrong turnings, as there always are with programming, such as the landscape appearing at the top rather than the bottom of the screen.

Landscape in the sky. Classic computing error. The machine, of course, was doing exactly what I’d asked it to do.

The not so solid surface of the moon. Not so much a bug this time, just a case of not having got to the point where I’d added a test for the lander hitting the surface.

Next Steps

So I had most of a working game. I didn’t want to polish it up too much. Rather, I wanted to take the basic building blocks and ideas and get my godson to, first, put together his own hardware and, second, code up the game. Knowing that I had the really tricky code to talk to the display, to put pixels – and also little patterns of pixels, such as the lander – on screen, made it a viable plan. Although it still seemed pretty ambitious. I was only visiting for a weekend. But I very much hoped, J would both have fun and, at the end of the visit, have a viable – if basic – Lunar Lander game.

I’ll add a link to part 2 when it’s written… watch this space. If you want to try this project yourself check out Connecting a micro:bit and an AdaFruit 1.44 inch display.

Questions and Comments

Comments are not enabled on this site, but if there are interesting comments or useful tips submitted then I’ll append them to this or one of the other Lunar Landed related posts.



    Question or comment

    Tag Me – a Paragraft update

    I really like the tag lozenges in Paragraft.

    Their creation began with having an idea of how they might look, how they might be dragged between an ‘available’ to a ‘selected’ bucket, and  how, with a bit of animation, they might neatly re-order themselves after every disruption.

    The idea was quickly formed. Then there was the long process of initial implementation followed by the even longer process of debugging and refining the operation of the feature.

    What looks great in the mind’s eye can all too easily lose its lustre when it’s realised in pixels and code. But I found that months on I was still enjoying tagging my Paragraft documents. Often, I would idly re-order the tags just to watch them do their little dance as they shuffled themselves into their right places.

    But for all that I liked tagging my documents, over time it began to dawn on me that I just wasn’t making use of the tags for finding my documents. The process felt too fiddly. And so I just didn’t use it.

    Oh dear.

    The problem was that although the process of applying tags to a given document was a delight, the process of selecting tags in order to filter the document list was awkward. Of course, describing the problem like this – a description only available in hindsight – immediately suggests a solution: adapt the process of applying tags to a document to the operation of applying tag filters to the document list.

    After a short burst of intense activity, I had a rough but working version of the new approach. And now I found that I was using tag filtering all the time. Applying tag filters and removing them was quick. And fun: I got to do more dragging of those lozenges and more watching them do their little shuffle dance.

    This shows all the documents tagged both Paragraft and coding, but excludes any documents tagged v05.

    As ever, the rough implementation required plenty of polish to get ready for release. And, along the way, many further developments to the user interface now seemed obvious, such as:

    • an indication of how many filtered documents were being shown
    • a tap or drag on the title of the document list to change what meta-data is shown, i.e. tags, edit date, creation date, or key date
    • an option to flip a tag over to make it exclude rather than include matching items (see the grey tag in the picture)
    • an overhaul of the iPad interface so a tag filtering pane was shown side by side with the document list.

    Of course, what people do and don’t like in a user interface varies a lot. And just because I now feel that the first shot at tag filtering was catastrophically clunky, doesn’t mean this iteration will suit everyone. But I think the odds of it suiting more people are definitely on the up.

    Paragraft v05 is available now.

    Review: Steve Jobs by Walter Isaacson

    Walter Isaacson’s biography of Steve Jobs makes some play of the fact that Jobs deliberately ceded control of the ‘product’. Aside from an intervention over the cover photographs, Jobs put his trust entirely in Isaacson, declining to set in train a relentless round of design iterations. It certainly shows.

    If Jobs had been in charge of this ‘product’ you can bet the quality of the paper, the presentation of the photographs, the typesetting, the binding, and many other details, would all have been remarkable. And you can bet there would be some aspect of the ‘product’ that would have been innovative, perhaps the first instance of a new technology beautifully perfected, made ready, attractive and accessible to a large audience. By contrast, Isaacson’s ‘product’, with the exception of its subject, is no more than run of the mill.

    It’s easy to make these bets, because that was how Jobs got things made. He didn’t repeat existing formulae – that held no interest for him. Rather, he pulled the future, kicking and screaming, out of the present. His gift was that he could see that future, a future in which technical products didn’t just do amazing things, but did so in a way that delighted rather than alienated. Technology’s good fortune was that he was reliably able to surround himself with people from which he could drag the technical and aesthetic solutions to make his vision of the future real.

    Clearly, Jobs wasn’t always easy to be around – he was rude, capricious and sometimes cruel. Isaacson’s biography is strong, if occasionally repetitive, when it comes to illustrating this. The book also demonstrates one reason why the best designers and engineers chose to hang around – Jobs’s vision and taste, along with his sheer drive, created an environment where people achieved more than they ever believed possible.

    The book is weaker in other areas. It barely addresses Jobs’s key role in creating the desktop publishing revolution, for example. And Isaacson rarely offers us intimate details – moments of humour, kindness or vulnerability – that would thicken the plot by providing counterpoint to the dominant narrative. This lack means that the Jobs shown here sometimes seems cartoon like, only abstractly drawn.

    Isaacson also does little to bring out what I suspect is a key reason for Jobs ceding control over the biography project, a key reason why this is not an iBiography. That reason is that Jobs was just not interested in looking back. He didn’t choose to deploy his energy and focus on the past, because he was so fixated on looking to the future.

    Consider that when Jobs returned to Apple in 1996, one of his early actions was to have dumped the company’s extensive historical archive. This was not some carefully weighed act of ‘decluttering’. To ‘declutter’ is to give up something you care about in the reasonable hope that it will bring renewed focus on the future. But, for Jobs, this archive was, literally, junk. It cost him nothing to give it up. It was simply taking up space. It had nothing to do with what lay ahead.

    A friend, whom I mildly annoy with my enthusiasm for Apple products, asked me, in all open curiosity, whether Jobs had an interesting story. He did. There’s all sorts of big drama in his personal life, in the big arc of his career and in the very many smaller arcs that made up each product development cycle. While it might not have been Jobs’s cup of tea, for those of us not single-mindedly inventing the future, his is a fascinating and edifying story. Isaacson’s book tells it well enough. But it left me wondering what a ‘product’ setting out to do this job might have been like if someone with Steve-like standards had been in control.

    References and Links

    Steve Jobs: The Exclusive Biography – Walter Isaacson
    –the book under review.

    Inside the Publishing Revolution: The Adobe Story – Pamela Pfiffner
    —includes coverage of Jobs’s role in the introduction of the LaserWriter printer. has a PDF extract.
    —transcript of a Steve Jobs and Bill Gates interview in 2007. It covers Jobs’s donation of Apple archive material to Stanford University on his return after ten years away.

    Inside Steve’s Brain: Business Lessons from Steve Jobs, the Man Who Saved Apple – Leander Kahney
    —an excellent book on Jobs which, no doubt, will soon be updated to cover the iPhone and iPad era.

    What is Narrative Therapy? An Easy to Read Introduction – Alice Morgan
    –a great read if you are interested in the battle between dominant narrative (‘thin descriptions’) and thickened plots (‘rich descriptions’).

    Note: the links to books on Amazon generate a tiny kickback for me if you make a purchase.