There has been a lot of excitement around the blogosphere following the announcement of a free version of the wildly popular game Minecraft for the Raspberry Pi. My teenagers and their friends are somewhat obsessed with the game, so the chance of drumming up a bit of interest in software and hardware development by joining the two worlds seemed too good to miss.

So as not to interfere with any of the other partially completed raspberry Pi projects I have on the go, I decided to use completely fresh Raspbian image. It looks like there is a new 2013-02-09 version available for download. I prefer torrents for this sort of thing, but there seemed to be no active seeders when I tried, so I ended up downloading the archive. I burned it to SD using Win Disk Imager as usual, then popped it into the Pi and booted it up. A quick ssh to run raspi-config, and I was ready to install Minecraft.

One of the characteristics of "Problem-Oriented Languages" (POL) is that they are tiny. The language run-time provides just enough to enable a programmer to extend the language into something appropriate to the needs and terminology of the domain. This "tininess" also extends to memory usage. On a single process system the complete language and operating system can easily fit in a few kilobytes of memory. Multi-user and multi-processing features can eat up another few kilobytes here and there, but we are still only looking at a few tens of kilobytes for a whole system.

I have just spent an annoying evening trying to get my little bluetooth keyboard working. Without success. Plenty of websites seem to offer instructions, but so far none of them have worked.

I'm pretty sure the bluetooth adapter is compatible. It certainly gets as far as showing the ids of my keyboard and a nearby laptop, but after, everything I can try I'm still net getting to the point where I can type keys and have them appear on the Raspberry Pi. I'm beginning to wonder if this is a reasonable thing to do at all.

That'll teach me to go away for a weekend. It seems my previous post "Automatic Raspberry Pi board revision detection: model A, B1 and B2" was surprisingly popular. It was picked up by several important Raspberry Pi web sites and led to a significant spike in visitors. If you are someone who found their way here because of that post, welcome! I hope you find something of interest.

Traffic seems to have eased off now, so I hope to get back to my usual mix of Raspberry Pi hardware projects and reviews together with a journal of work on my own "bare metal" operating system and language development.

When the raspberry Pi model A was announced a few days ago, I ordered one straight away. With three different models of raspberry Pi now available (or four, if you count the red Chinese variant), working out the capabilities of the board is becoming increasingly important. It’s vital for anyone involved in making hardware or software for other people to use, and it’s even pretty important for personal projects – you never know when you might want to use your hardware and software with a different board.

This evening I presented a session on Raspberry Pi at The Ipswich Ruby User Group (IPRUG). I think the presentation went well, as dd the Q&A session which followed. Unfortunately, all my plans to demonstrate stuff fell through. Mainly this was due to my own lack of preparation rather than any problems with the hardware or software.

Lessons to learn from this:

• Connecting to a Raspberry Pi via ssh requires that both ends can get an IP address, so set up static IP in advance or provide DHCP
• If ssh is not available, either plug in and test a serial port adapter before the demo, or carry a pin diagram
• If relying on Wifi for DHCP, make sure that the Raspberry Pi has been set up with the SSID and password for the access point
• If you take a wifi access point or DHCP router to a demo, make sure you have the configuration login password
• If trying to connect a Raspberry Pi to a router to get an IP address, provide enough nearby power sockets so you can power both at once
• Just in case, always carry a USB keyboard and some display adapters, to get in and tweak settings
• As a final fallback, create an SD card which runs the demo software immediately on boot

Above all, prepare and test all the hardware, power and networking in advance.

I have spent a few days planning for my talk at IPRUG tomorrow evening. One of the things I was hoping to do was demonstrate a standalone Raspberry Pi controlling a USB missile launcher that I have had laying around unused for a few years.

In my continuing research for my bare-metal operating system and language, I have been looking at polyFORTH. This is a system language designed for use on the massively-parallel processor chips produced by GreenArrays, obviously from the same heritage as the Problem Oriented Language philosophy from Charles Moore's 1970 document.

One interesting thing about the polyFORTH reference manual is that it goes into detail about memory sizes and how the various parts of the system are mapped to physical memory. Each process gets its own data and return stacks, as well as an area for variables, per-process register storage and so on; processes with user input also get an input buffer and a dictionary to hold new words as they are defined.

A few days ago I got a bit cross with myself while trying unsuccessfully to get a wi-fi network connection working with Raspbian Wheezy. I guess I must have rushed into it, because I obviously didn't look in the right places. However, in my defence it seems that sometimes changes to the configuration don't always take effect straight away, even when I manually take the interface down and bring it back up.

A few weeks ago I bought some interface adapter boards, including a Slice of PI/O, which came as a kit of parts in a little zip-lock bag.

I had a day off work today. Not for a good reason, unfortunately - it was my aunt's funeral in the afternoon. But it did give me an hour or so to do some raspberry Pi stuff in the daylight. As well as having a go at tidying up all the wires, SD cards and expansion bits I had lying around my desk, I fetched my soldering iron to assemble the Slice of PI/O.