Category Archives: computers suck
Ever heard the term “Appropriate Use of Technology”?
Well, this is not that: For He’s a Jolly Good Fellow [mp3], as played on this:

— an Arduino driving a stepper motor driving a Sankyo musical box. And yes, heat-shrink tubing ‘reinforced’ with dental floss doesn’t make a very robust flexible coupling.
Potentially handy Raspberry Pi power source
This looks handy; it’s the Globe Electric 2-Outlet Tap with Surge Protection and 2 USB Chargers (#46082). The USB outlets are rated at 1A. It was $12 at Loblaws. I’ll let you know how it works out for powering the Raspberry Pi.
Update: Yes! It works!
python + Arduino + Tk: Toggling an LED
Phil sent me a note last week asking how to turn an LED on or off using Python talking through Firmata to an Arduino. This was harder than it looked.
It turns out the hard part is getting the value from the Tkinter Checkbutton itself. It seems that some widgets don’t return values directly, so you must read the widget’s value with a get() method. This appears to work:
#!/usr/bin/python
# turn an LED on/off with a Tk Checkbutton - scruss 2012/11/13
# Connection:
# - small LED connected from D3, through a resistor, to GND
import pyfirmata
from Tkinter import *
# Create a new board, specifying serial port
# board = pyfirmata.Arduino('/dev/ttyACM0') # Raspberry Pi
board = pyfirmata.Arduino('/dev/tty.usbmodem411') # Mac
root = Tk()
var = BooleanVar()
# set up pins
pin3 = board.get_pin('d:3:o') # D3 On/Off Output (LED)
def set_led(): # set LED on/off
ledval = var.get()
print "Toggled", ledval
pin3.write(ledval)
# now set up GUI
b = Checkbutton(root, text = "LED", command = set_led,
variable = var)
b.pack(anchor = CENTER)
root.mainloop()
This is explained quite well here: Tkinter Checkbutton doesn’t change my variable – Stack Overflow. I also learnt a couple of things about my previous programs:
- You don’t really need to set up an Iterator unless you’re reading analogue inputs
- My “clever” cleanup-on-exit code actually made the script hang on Mac OS.
Power Cost Monitor signals — for reals!
After doing almost nothing with the Arduino and the elusive Power Cost Monitor signal, I’m finally getting something from it. Matt Colyer’s Power Monitor sketch does all the heavy lifting, for he managed to reverse engineer the protocol. His solution is a rather complex one, involving ethernet shields and Ruby. All I wanted was a simple serial logger, so I cut down Matt’s code, and modified the network output to simple print statements:
== Waiting (38464857ms, 1676 bytes) == == Sending (38467858ms, 1668 bytes) == sample[data]=0000000a sample[data]=0000015a == Waiting (38467863ms, 1676 bytes) == == Received (38592156ms, 1670 bytes) == == Waiting (38592157ms, 1676 bytes) == == Sending (38595158ms, 1668 bytes) == sample[data]=00000000 == Waiting (38595159ms, 1676 bytes) == == Received (38624334ms, 1670 bytes) == == Waiting (38624335ms, 1676 bytes) == == Sending (38627336ms, 1668 bytes) == sample[data]=ffffe746 == Waiting (38627337ms, 1676 bytes) == == Received (38688007ms, 1670 bytes) == == Waiting (38688009ms, 1676 bytes) == == Received (38688045ms, 1670 bytes) == == Waiting (38688046ms, 1676 bytes) == == Sending (38691047ms, 1668 bytes) == sample[data]=00001748 sample[data]=00000008 == Waiting (38691052ms, 1676 bytes) == == Received (38720026ms, 1670 bytes) == == Waiting (38720027ms, 1676 bytes) == == Sending (38723028ms, 1668 bytes) == sample[data]=00000000 == Waiting (38723030ms, 1676 bytes) == == Received (38783686ms, 1670 bytes) == == Waiting (38783687ms, 1676 bytes) == == Sending (38786688ms, 1668 bytes) == sample[data]=00000011 == Waiting (38786689ms, 1676 bytes) == == Received (38815636ms, 1670 bytes) == == Waiting (38815637ms, 1676 bytes) == == Sending (38818638ms, 1668 bytes) == sample[data]=fffff322 == Waiting (38818639ms, 1676 bytes) == == Received (38847547ms, 1670 bytes) == == Waiting (38847548ms, 1676 bytes) == == Sending (38850549ms, 1668 bytes) == sample[data]=00000001 == Waiting (38850550ms, 1676 bytes) == == Received (38879444ms, 1670 bytes) == == Waiting (38879446ms, 1676 bytes) == == Sending (38882445ms, 1668 bytes) == sample[data]=0000374f == Waiting (38882446ms, 1676 bytes) == == Received (38911210ms, 1670 bytes) == == Waiting (38911211ms, 1676 bytes) == == Sending (38914212ms, 1668 bytes) == sample[data]=00000043 == Waiting (38914213ms, 1676 bytes) == == Received (39006981ms, 1670 bytes) == == Waiting (39006982ms, 1676 bytes) == == Sending (39009982ms, 1668 bytes) == sample[data]=00000000 == Waiting (39009983ms, 1676 bytes) == == Received (39038895ms, 1670 bytes) == == Waiting (39038896ms, 1676 bytes) == == Sending (39041897ms, 1668 bytes) == sample[data]=00000001 == Waiting (39041898ms, 1676 bytes) == == Received (39102999ms, 1670 bytes) == == Waiting (39103000ms, 1676 bytes) == == Sending (39106001ms, 1668 bytes) == sample[data]=00000000 == Waiting (39106002ms, 1676 bytes) == == Received (39134880ms, 1670 bytes) == == Waiting (39134881ms, 1676 bytes) == == Sending (39137882ms, 1668 bytes) == sample[data]=00000001 == Waiting (39137883ms, 1676 bytes) ==
Now it’s just a small matter of programming to work out what Matt’s Ruby code does. Ruby always looks to me like two programmers started coding at different ends of the same line, and collided in the middle. I’m hoping there’s enough processing power in the Arduino to do the conversion in the chip, and output useful log data as a serial stream.
More later …
The MagPi
Yay! My article on Arduino and Raspberry Pi is this month’s cover of The MagPi! Read it on Issuu, or download the PDF.
Thanks to Ash and the rest of the team at the magazine.
Servo Control from pyfirmata + arduino
pyFirmata‘s documentation is, to be charitable, sparse. After writing Raspberry Pi, Python & Arduino *and* a GUI (which should be making an appearance in The MagPi soon, w00t w00t!), I looked at pyFirmata again to see what it could do. That pretty much meant digging through the source.
Firmata can drive hobby servos, and if you’re not driving too many, you can run them straight from the Arduino with no additional power. I used a standard cheapo-but-decent Futaba S3003, which gives you about 180° of motion. The particular one I tried started to make little growly noises past 175°, so in the example below, that’s hardcoded as the limit.
#!/usr/bin/python
# -*- coding: utf-8 -*-
# move a servo from a Tk slider - scruss 2012-10-28
import pyfirmata
from Tkinter import *
# don't forget to change the serial port to suit
board = pyfirmata.Arduino('/dev/tty.usbmodem26271')
# start an iterator thread so
# serial buffer doesn't overflow
iter8 = pyfirmata.util.Iterator(board)
iter8.start()
# set up pin D9 as Servo Output
pin9 = board.get_pin('d:9:s')
def move_servo(a):
pin9.write(a)
# set up GUI
root = Tk()
# draw a nice big slider for servo position
scale = Scale(root,
command = move_servo,
to = 175,
orient = HORIZONTAL,
length = 400,
label = 'Angle')
scale.pack(anchor = CENTER)
# run Tk event loop
root.mainloop()
The code above makes a slider (oh, okay, a Tkinter Scale widget) that moves the servo connected to Arduino pin D9 through its whole range. To set the servo position, you just need to write the angle value to the pin.
I haven’t tried this with the Raspberry Pi yet. It wouldn’t surprise me if it needed external power to drive the Arduino and the servo. This might be a good excuse to use my Omega-328U board — it’s Arduino code compatible, runs from an external power supply, and has Signal-Voltage-Ground (SVG) connectors that the servo cable would just plug straight into.
a paucity of pi posts
I would have been posting more Raspberry Pi posts, but my latest Made-in-UK 512MB board seems to have a raft of problems. Left to its own devices, it will happily corrupt any SD card I put in it. This is some fairly typical dmesg output:
[36218.109865] mmc0: final write to SD card still running
[36228.126345] mmc0: Timeout waiting for hardware interrupt - cmd12.
[36228.127534] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
[36248.152121] mmc0: final write to SD card still running
[36258.163655] mmc0: Timeout waiting for hardware interrupt - cmd12.
[36258.164865] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
[36269.084446] mmc0: final write to SD card still running
[36279.101766] mmc0: Timeout waiting for hardware interrupt - cmd12.
[36279.102953] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
[36309.899006] mmc0: Timeout waiting for hardware interrupt - cmd25.
[36309.899047] mmc0: resetting ongoing cmd 25DMA before 4096/4096 [84]/[96] complete
[36309.902774] mmcblk0: error -110 transferring data, sector 1721928, nr 848, cmd response 0x900, card status 0xc00
[36309.902964] mmc0: DMA IRQ 6 ignored - results were reset
[36309.903200] end_request: I/O error, dev mmcblk0, sector 1722649
[36309.903227] end_request: I/O error, dev mmcblk0, sector 1722656
...
[36309.903462] end_request: I/O error, dev mmcblk0, sector 1722768
[36309.903823] Aborting journal on device mmcblk0p2-8.
[36310.460263] journal commit I/O error
[36310.653420] EXT4-fs error (device mmcblk0p2): ext4_journal_start_sb:327: Detected aborted journal
[36310.667118] EXT4-fs (mmcblk0p2): Remounting filesystem read-only
I’m not alone in having this problem; it’s reported by other people at Raspberry Pi • PI freezes and Filesystem corruption on the SD card – Stack Exchange. I don’t see any solutions or responses from the Foundation yet.
Update: for no reason I can explain, setting over_voltage=2 in the /boot/config.txt file seems to make this problem go away. For me, at least.
LaunchPad MSP430 pomodoro timer using Energia
I know a lot of people who bought the Texas Instruments MSP430 LaunchPad development kit but never really got into it. I’m one of them; the $4.30 purchase price was compelling, but the requirement to install a huge proprietary IDE (with its own embedded C dialect) was just too much.
For this reason, Energia is great. It’s a fork of the Wiring/Arduino development environment for the MSP430. Looks just like Arduino, but quite red:

The basics of the language are the same, although the pin names and functions are different from the Arduino. The basic board also has a red and a green LED, a user button, and the obligatory reset button.
Just to try out Energia, I wanted a useful project that only used the onboard hardware. I came up with a version of a pomodoro timer, similar to the one used in The Pomodoro Technique® time management method. The one I made has the following features:
- 25 minute “green light” work period
- 5 minute “red light” rest period
- At the end of the rest period, the green and red lights flash. You can choose to restart the timer (with the reset button), or turn the lights off with the user button.
- You can turn the timer off at any time with the user button, and restart it from zero with the reset button.
For me, this electronic version has several advantages over the wind-up official timer:
- it doesn’t tick or ring distractingly
- it’s cheaper than the real thing
- it always resets to the same time.
It does have a couple of possible disadvantages, though:
- it doesn’t give an indication of time left
- it’s not very accurate, since it uses the MSP430′s internal oscillator. Mine seems to give an approximately 26 minute work period, with a rest time that’s proportionally longer.
Here’s the code (tested on a MSP-EXP430G2 board, version 1.4):
/*
launchpomodoro - simple task/rest timer for TMS430/Energia
On reset: Green LED on for 25 minutes
After 25 minutes: Red LED
After 30 minutes: Flashing Red/Green LED (until reset)
On button press: all lights off.
scruss - 2012-10-15
*/
// 25 minutes
#define ENDWORKTIME 1500000
// 30 minutes
#define ENDRESTTIME 1800000
unsigned long start=0;
int red=1; // for light flashing state at end of rest time
int green=0;
void setup() {
pinMode(GREEN_LED, OUTPUT);
pinMode(RED_LED, OUTPUT);
pinMode(PUSH2, INPUT);
digitalWrite(GREEN_LED, HIGH); // start work
digitalWrite(RED_LED, LOW); // stop rest
start=millis();
}
void loop () {
if ((millis()-start)>ENDWORKTIME) {
digitalWrite(GREEN_LED, LOW); // stop work
digitalWrite(RED_LED, HIGH); // start rest
}
if ((millis()-start)>ENDRESTTIME) {
flicker(); // warn that we've overrun
}
if (digitalRead(PUSH2) == LOW) { // push quiet/off switch
off();
}
}
void flicker() { // toggle LEDs and wait a bit
red=1-red;
green=1-green;
digitalWrite(GREEN_LED, green);
digitalWrite(RED_LED, red);
delay(333);
}
void off() { // appear to be off
digitalWrite(GREEN_LED, LOW); // lights off
digitalWrite(RED_LED, LOW);
while (1) { // loop until reset
delay(50);
}
}
(or if you’d rather have the archived sketch: launchpomodoro-121015a.zip.)
It would be trivial to port this to Arduino, but you would need some external LEDs, resistors and a pushbutton.
optar: paper-based archiving

I’ve spent most of the day messing around with Twibright Optar, a way of creating printed archives of binary data that can be scanned back in and restored. It looks like it was written as a proof-of-concept, as the only way to change options is to modify the code and recompile. Eppur si muove.
To compile the code on OS X, I found I had to change this line in the Makefile from:
LDFLAGS=-lm
to
LDFLAGS=-lm `libpng-config --L_opts`
After trying to print some samples at the default resolution, I had no luck, so for reliability I halved the data density settings in the file optar.h:
#define XCROSSES 33 /* Number of crosses horizontally */ #define YCROSSES 43 /* Number of crosses vertically */
It’s quite important that your image prints and scans with a whole number of printer dots to image pixels. This used to be quite easy to do, before the advent of PDF’s “Scale to fit” misfeature, and also printer drivers that do a tonne of work in the background to “improve” the image. Add the mismatch between laser printer resolutions (300, 600, 1200 dpi …) and inkjets (360, 720, 1440 dpi …), and you’ve got lots of ways that this can go wrong.
Thankfully, there’s one common resolution that works across both types of printers. If you output the image at 120 dpi, that’s 5 laser printer dots at 600 dpi, or six inkjet dots at 720 dpi. And there was peace in the kingdom.
Here’s a demo, based on this:
So I took this track (which I used to have as a 7″, got at a jumble sale in the mid-70s) and converted it to a really low quality MPEG-2.5: MichelinJingle8kbit — that’s 175KB for just shy of three minutes of music (which, at this bitrate, sounds like it’s played through a layer of socks at the bottom of the Marianas Trench, but still).
Passing it through optar (which I wish wouldn’t produce PGM files; its output is mono) and bundling the pages into a PDF, I get this: optar_mj.pdf (760KB). Scanning that printout at 600dpi and running the pages through unoptar, I got this: optar1_mj.mp3. It’s the same as the input file, except padded with zeros at the end.
Sometimes, the scanning and conversion doesn’t do so well:
- mjoptar300dpi.mp3 — this is what happens when you scan at too low a resolution.
- mjx.mp3 — I have no idea what went wrong here, but: glitchtastic!
ATTiny programming board
It’s amazing what you can do when you raid your parts bin …

Featuring fully configurable M-F jumpers so I can program (pretty much) any Atmel ATTiny microcontroller up to 28 pins. Might be able to do some ATMegas too.
Painfully Slow Amstrad CPC Emulation on the Raspberry Pi
Yeah, you can do it, but whether you should, I don’t know. Download the latest Arnold/Linux source, then (according to this post) after installing the dependencies, you just need to change
TARGET_FMT=elf32-i386
to
TARGET_FMT=elf32-littlearm
in src/Makefile.in.
It works, for very slow values of “works”. Mind you, I was running it through a remote X session, so 2 fps is all I could have hoped for …
Sometimes, things do not go exactly as planned … C development for Amstrad CPC on Raspberry Pi

If you crash an Amstrad CPC, you often got some pretty patterns. Like the one above, which was supposed to print the alphabet, but got about as far as R, then started making coloured spots on the screen. My alphabet doesn’t (usually) contain coloured spots, so something went wrong.
This post is only about the Raspberry Pi in that it’s the nearest always-on Linux system that I have. This would likely work fine on any Linux machine. While the Z80 cross compiler I use (z88dk) is available in the repos, I can’t get it to build anything, so I just pulled down the latest version. To build the compiler:
wget http://nightly.z88dk.org/z88dk-latest.tgz
tar xvzf z88dk-latest.tgz
cd z88dk
export Z80_OZFILES=$(pwd)/lib/
export ZCCCFG=${Z80_OZFILES}config/
export PATH=${PATH}:$(pwd)/bin
./build.sh
This should result in a working environment. We can test it with a simple C program:
/* alfa.c - print the alphabet */
#include
int main(void) {
char a='A';
char b=26;
while (b>0) {
putchar(a);
a++;
b--;
}
}
You can build it with:
zcc +cpc -create-app -make-app -O3 -unsigned -o alfa.bin alfa.c -lcpcfs -zorg=16384
You should end up with a file alpha.bin of approximately 4749 (!) bytes. You can copy it to a disc image using iDSK:
iDSK blank.dsk -i alfa.bin -c 4000 -e 4000 -t 1
It runs like this:

You can do the same with Z80 assembly language (shown here in the most gratuitously pretty Amstrad assembler, Maxam):
Although this results in only 11 bytes of code, it’s not portable; the C code above compiled and ran on both my Raspberry Pi and my Mac. It wouldn’t even run properly on a different Z80 system, as only the Amstrad CPC knows that call #bb5a prints the character in the A register. On the ZX Spectrum, for example, it was the completely different instruction rst 16 to print a character.
(There’s a lot more on z88dk on the CPCWiki.)
Wireless, Cordless Raspberry Pi
Yay! I found a wireless adapter that the Raspberry Pi is able to power without an external hub. It’s a Belkin N150 Micro Wireless USB Adapter. Not sure of the range, but it works well enough, and is cheap.
Just to show you how hard-core I am, that’s a screenshot of a browser (showing a picture of the Raspberry Pi + LSTech Solar charger) running on that Raspberry Pi with an X session tunnelled to the laptop you can see in the background. My head hurts now.
#swagfail
Put me out to pasture, my conference swag skills are failing.
I picked this up at Solar Power International:

I thought I was picking up a USB memory stick, as I’d nabbed one in the same form factor before. Break off the backing card at the hinge, and you’ve got a nice tiny data store like the Kingmax ones I used to use.
On plugging it into my Mac, a couple of icons bipped on my dock, then Skype opened. Wat? More importantly, there was no storage to be seen, so once my virus fears had subsided a bit, I was determined to find out what this pointless piece of plastic was doing.
The stick identified itself to the system as an Apple keyboard (USB ID 05ac:020b), and spits out the following characters (captured by cat and xxd on my Raspberry Pi):
0000000: 1b72 1b5b 317e 1b5b 3477 7777 2e62 757a .r.[1~.[4www.buz 0000010: 7a63 6172 642e 7573 2f73 6365 2d32 3230 zcard.us/sce-220 0000020: 0a .
After reading about evil USB dongles, it seems that the Ctrl-R keypress it's sending is the Windows "Open Browser" command, and then opens the url www.buzzcard.us/sce-220. This link redirects to www.plugyourbrand.com/gosolar_sce/index.html?u=220, which appears to do some Flash/JS stuff which I don't want to understand.
The funny thing is, the card has the perfectly respectable www.GoSolarCalifornia.ca.gov (well, respectable if you consider a US .gov website as such) link printed on it. Even printing a card with a QR code linking to that address would be less opaque.
As is, a bunch of plastic was wasted in vain just to save people typing an URL. We're all going to die, and it really is your fault ...
(sort-of) Solar Powered Raspberry Pi
One day, I’d like to power a small remote server from solar power. Today is not yet that day. But I’m closer …
At the Solar Power International show (big modules! cheap modules! AC modules!!) last week in Orlando (squee-able minilizards! cuban food!!) there were a few vendors selling solar USB chargers. Most were folding thin-film units similar to this, but what caught my eye (and was actually for sale at the show) was the LSTech “Smart one“:
The unit features:
- 2× 3.5 Ah 3.7 V Li-Poly batteries
- a 4W 5V solar panel inside the clamshell case
- a 1A USB output
- a USB Micro-B charging input and auxiliary solar panel input
- two ah-oww, make-it-stop bright LED
interrogationreading lights.
It comes with a couple of USB cables, and like seemingly all Korean semi-luxe electronic devices, comes in a soft brown velour bag. I’m not sure if the soft velour bag is the universal sign of quality in Korea, but I’ve noticed it enough that it might be A Thing.
I’ve run a Raspberry Pi for a couple of hours off this thing without making too much of a dent in the charge. I might be able to run it in full sun from the 4W solar charger, but I’m under no illusion that the Raspberry Pi’s ~3.5W continuous draw is going to keep running from such a small panel. That’s expecting an 88% capacity factor from a solar panel, which would be well if there wasn’t this small thing called night (or rotation of the earth, or cloud cover, or …)
2D Star Dodge flies again!
There’s rather more nostalgia in this post than I’d want to deal with. If you want to just play the game, go here here and skip this blurb.
About 25 years ago, I was a smallish computer nerd obsessed with programming his Amstrad CPC464. I had got a BCPL rom-based compiler for cheap and was looking for things to do with it. “Why not write a game?” I asked myself.
There were two minor hurdles. I had no imagination, and I certainly wasn’t focused enough to write anything big. Fortunately, it was still the 80s, so we knew how to rip stuff off without being called out for it. I merrily copied a game my friend Alan Cook had written for the Dragon 32, and called it 2D Star Dodge.
2D Star Dodge was the perfect rip off. Not merely had I ripped off the idea from Alan, but he had ripped off the idea in turn from a BBC Basic one-liner game called (as verified by Graeme Smith) “One Line”. The name 2D Star Dodge was an, um, homage to Realtime Games’ 3D Starstrike, which itself was “strongly influenced” by the Star Wars arcade game. Originality? Pfft.
So I wrote the game. Well, okay, I wrote a mockup in Locomotive BASIC, which ran a bit slowly, but gave me something to work from. Here it is, if you want to play it in you (Java-enabled) browser: 2D Star Dodge – BASIC. I then meticulously translated it into BCPL, and ended up with something that looked liked this:
(if you click on that image, you can play the BCPL version in your browser.)




The gameplay — press a key to go up, stop pressing a key to go down — is a bit like SFCave (obligatory Java version: Lab6 SFCave) or even my current favourite Tiny Wings.
Once I’d finished the BCPL version, I had bought the MAXAM assembler ROM, and got learning the Z80 opcodes. Soon, a third port was complete, now needing hardcoded delays to be playable as it would kill you off in about one screen refresh without them.
So, now I had three versions of the same game. There was only a limited number of local folks I could give it to, so I decided to send all three versions to Amstrad Computer User magazine to print as a type-in. Thankfully, it arrived on the desk of the freshly minted (yet still beardy) assistant editor Jeff Walker, who had founded the jam econo CPC magazine/club WACCI. Jeff had the idea for me to turn the simple game into a comparison of programming in three languages.
Thanks to the CPCWiki forum, you can now read the articles I wrote in Amstrad Computer User in 1988 that went with the code. Writing style best described as “typing”:
- Amstrad Computer User 1988/09 – Star Dodger 1 – BASIC
- Amstrad Computer User 1988/10 – Star Dodger 2 – BCPL
- Amstrad Computer User 1988/11 – Star Dodger 3 – Assembler
To play the game in an astonishing JavaScript emulator:
- Download this disc image file: stardoj
- Unzip it
- Go to CPCBox
- “Choose configuration …” of Boot CPC464 (or 664, or 6128)
- Select your downloaded stardoj.dsk as Drive A:
- Annoyingly, it seems to be stuck with an AZERTY keymap, so to catalogue the disc (
cat) you have to typecqt - To run the BASIC version, type
run"stardoj2(on my American keyboard, that becomesrun@stqrdoj2; quotes are Shift+2). Hitting Escape twice will quit back to the prompt. - To run the BCPL version, type
run"2dstardo. The only way to quit is to reset the emulator.
The BASIC version is based on the published type-in. The BCPL version I found as a disk image (2dstardo.dsk) on a download site — it’s exactly as I submitted it to the magazine, dubious copyright message and all. I’m not sure how it got out there; I suspect either my network of, ahem, software protection experts I knew through Colin Harris of Nemesis, or it went via my CPC-owning French penpal (Hi Benoit Hébert, formerly of Le Havre).
I had to modify the BCPL binary to run on modern emulators, as the real Amstrad CPC did a thing with its keymapping that is really hard to get right on modern systems. Originally, the game used the Shift key, but I modified it to use Space, which is easier to emulate as it’s a printing character. Can I just say that I remembered how to read and modify Z80 binaries after a quarter century? Old school, literally. I used iDsk‘s disassembler/hex dumper and emacs’s hexl mode to do the deed.
I recently discovered that someone created a Flash game based on my type-in: Star Dodger. Mind = Blown.
Amstrad CPC INKEY codes

Ganked from the CPC 6128 manual. You’re welcome …
Note that non-printing keys (like SHIFT) are really hard to emulate on modern machines. The CPC scanned them as if they were any printing key, but modern machines handle them like key modifiers.
Pibow; it’s official – normal USB cables don’t fit
I’d noted previously that a standard USB micro-b power plug doesn’t fit into a Pibow. I’ve measured the opening in the case at 10.4 mm. This is what the USB.org spec says for the Micro-B plug:

A conforming cable can be up to 0.2mm larger than would fit into the Pibow. The rather weak excuse given by the designer is:
My Micro-USB cable doesn’t fit!
The Pibow supports a wide range of svelte, stylish micro USB cables, we recommend on [sic] of these. We may be able to slightly widen the aperture to include more cable. We don’t intend to support cables with large sleeves though, they just look naff
While I had the vernier calipers out, I measured all the USB connectors I could find. Not one was under 11 mm, way out of spec, and completely unlikely to fit in the Pibow.
the russian peasants are multiplying!
Via this post, I found out about Russian Peasant Multiplication, a rather clever method of multiplication that only requires, doubling, halving and adding. So I wrote some code to display it:
#!/usr/bin/python
# -*- coding: utf-8 -*-
import sys
results=[]
indicator=' '
left=int(sys.argv[1])
right=int(sys.argv[2])
while right >= 1:
indicator='X'
if right % 2:
indicator=' ' # right number is odd,
results.append(left) # so add left number to results
print (" %s %16d \t %16d %s") % (indicator, left, right, indicator)
left *= 2
right /= 2
print("%s × %s = %s = %d")%(sys.argv[1], sys.argv[2],
' + '.join(map(str,results)), sum(results))
So to multiply 571 × 293:
$ ./rpmult.py 571 293 571 293 X 1142 146 X 2284 73 X 4568 36 X X 9136 18 X 18272 9 X 36544 4 X X 73088 2 X 146176 1 571 × 293 = 571 + 2284 + 18272 + 146176 = 167303
Python’s still got some weirdness compared to Perl; where I’d join the list of sum terms in Perl with join(' + ', @results), in Python you have to convert the integer values to strings, then call the join method of the separator string: ' + '.join(map(str,results)). Still, I’ll give Python props for having a built-in list sum() function, which Perl lacks.






