TwitBeeb on test at Bristol Hackspace, photo by John Honniball.

TwitBeeb is a BBC B microcomputer (vintage 1981) from which you can Tweet.

The Beeb itself was my main computer until 1994, I taught myself to program on it. A few years ago I pulled a rather scuffed up BBC out of a skip at Sussex University and took it home. Inside it had an add-on ROM board with several programs in ROM chips including a serial terminal emulator called Termulator. This allows it to connect to other computers via its serial port and for everything typed on the BBC's keyboard to be sent to the other computer which sends responses back to be displayed on the BBC's screen. It acts as what used to be called a "dumb terminal", just handling the input and output while a more powerful computer does the actual work. This was quite a common way of doing things back when computers were room-sized. Several terminals would connect to a large shared computer, possibly over phone lines using modems.

My first tests with the Beeb terminal involved connecting it to a Linux server using a cable I made from this recipe. It was a bit tricky to find 5 pin domino DIN plugs and note the warning about marking the top because you can plug them in either way up. I ran a text-based web browser called Lynx on the server via the BBC terminal and pointed it at Twitter. Termulator was not very good at handling the full Linux terminal and browser, it tended to crash and you can't use the arrow keys which makes using Lynx awkward. I did manage to send one tweet.

More recently, I got my hands on a Raspberry Pi. While considering what to do with it I remembered my BBC terminal experiments. Given that the Pi is cast from the same mould as the BBC, in terms of their educational intentions, they seem like an obvious pairing. They share a common heritage, in that the Raspberry Pi's ARM processor was designed by some of the same team who worked on the BBC Micro. I also enjoy the fact that in this case the terminal is physically far bigger than the vastly more powerful computer it connects to.

Some spec comparisons:

The first experiment with the BBC B and Twitter via Lynx.

So due to Termulator's problems handling a full text-mode browser and because that would have been too complicated for use on the stand at an event like a Makerfaire I wrote my own specialised kind of Twitter client. The BBC's OS has a set of special bytes that you can send to control things like text colour and cursor position, I used these to make it pretty. It reminded me of the kind of programs that I used to write when I was 11, it was kind of odd to be doing that stuff in Ruby rather than BASIC.

Here is the code, on Github. It searches for a hashtag and displays some results on the screen below the title. At the bottom of the screen it shows a prompt very much like the BASIC one, you type your tweet there and press Return to send it. The hashtag is appended for you. The code stops you typing too many characters.

For TwitBeeb's first public outing at Derby Mini Makerfaire I had the Pi talking to the Internet using a USB Wifi dongle. I set up the network by connecting to the Pi's serial console from my laptop using a USB to serial converter and a Sparkfun level shifter. When the network was working I connected to the Pi with ssh and moved the USB to serial converter to the Pi and connected the serial end to the BBC (minus the level shifter). I then started Termulator on the Beeb, put it in BBC VDU mode and started the twitbeeb script on the Pi. I used the command line to redirect standard in and out for the script to the serial port device, having first set it to run at 4800 baud and several other parameters using stty.

It was quite popular at the Faire, mostly as a spectacle though. People were reluctant to come up with a witty tweet on the spot. It tweets from the @twitbeeb account, you can see people's tweets there. Most confusion came when there was a need to find the "delete" key, and also "@" hidden in plain view on a key of its own.

Today I did the Kubuntu Karmic to Lucid upgrade on my Thinkpad T60 with 2GHz Core Duo CPU, 3GB RAM and ATI Radeon Mobility X1400 GPU.

The upgrade itself went ahead flawlessly but I started to see problems after the desktop started. Things seemed generally sluggish, especially moving windows around and scrolling, and it seemed to get worse over time. Flash video was very teary and unwatchable fullscreen. When I tried to play a 3D game it caused a strange horizontal black line interference that didn't go away until I rebooted. Also, seemingly unrelated, the wireless network would lose connection after a while and refuse to reconnect until I switched the wireless kill switch off and on again.

The solution to all these problems seems to have been to switch off Kernel Mode-Setting. I did this by editing the file /etc/default/grub and changing the line:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

to

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash radeon.modeset=0"

Then running update-grub and rebooting. This has resulted in a much more stable desktop, but at the cost of making the boot splash screen look very ugly indeed. The wireless connection now works perfectly.

Now it's working properly the KDE desktop with compositing seems much more responsive than on Karmic. I might even leave effects turned on this time. Video is fine and 3D games work reasonably well, I've had trouble with 3D stuff before. I'm still seeing a fair bit of corruption on icons and window decorations, something I've seen ever since switching to the open source ATI driver.

So generally Lucid is looking good and I'm liking the new stuff in KDE 4.4. Perhaps it's still a bit early to be enabling the kernel stuff for the radeon driver though.