One thing that’s been missing is a really good micro:bit driver or MakeCode extension for OLED displays.
The good folk at Kitronik have just released a new product, a micro:bit OLED display board. The good news is, their MakeCode extension also works with the cheap OLED displays I have lying around. (I’ve not tried the Python modules yet, but will do).
It’s possible some other displays will have different I2C addresses, so you may need to tweak the code of the extension, but I was pleased to find mine worked with no changes.
This means you can use them with an OLED connected to a micro:bit’s I2C pins via a breakout board and 4 female-female jumper wires.
A couple of things I really like about their extension:
The text is small so you can get a useful amount of stuff on the screen
The ‘plot’ block, which is more useful than it sounds – it’s a really simple way of drawing live graphs of sensor data with a number to show the current reading. The graph even scrolls when it gets to the end, a lovely touch.
Here’s just how simple the code is to put some text, a light reading number and plot a live graph using the Kitronik extension:
If you don’t already have a breakout board and OLED display to hand, the Kitronik accessory just snaps on to your micro:bit’s edge connector, and leaves other pins free for connecting more goodies, which is an excellent feature. It’s currently £13.80 including VAT, which seems like a very reasonable price point for a well-supported accessory – though I must say I’ve not actually tested the Kitronik board itself, just their MakeCode extension!
As a language, TinyBASIC may be ‘awful’ as someone told me, but it has an interesting history. It stemmed from a challenge made in the September 1975 issue of the People’s Computer Company magazine (later better known as Dr Dobb’s Journal) to write a simple, free version of BASIC. Around this time two dudes called Bill and Steve were getting annoyed at people illegally copying their new MicroSoft BASIC, and TinyBASIC was written to give people a free, legal, ‘copyleft’ alternative. I really recommend browsing old issues of PCC magazine, there are some great articles in there some of which are still relevant today. (I was also inspired by reading about the origins of TinyBASIC to create my own ultra-simple text-based language for the BBC micro:bit.)
You can run Tiny BASIC on a BBC micro:bit, but for this project I decided to make some Tiny BASIC computers using some Arduinos to see if I could make a standalone computer with keyboard and display.
I used this project from a few years ago by Rob Cai as the basis. Like the Wifi Sheep computer, it uses two Arduinos, one to handle keyboard input and run TinyBASIC, and the second to act as a kind of video card generating surprisingly hi-res video using the MRETV software. It turned out I had almost all the components I needed to build this, except some diodes. So while I was waiting for the diodes to arrive in the post, I pondered alternative output devices…
It occurred to me that I have a serial thermal printer, and I could maybe use that as an output device, a bit like the old Rockwell AIM-65 computer from 1978. And it sort of worked! I just changed the baud rate in the Arduino program running TinyBASIC to 19200 baud to match the printer, and connected the TX pin of the Arduino to the RX pin of the printer. As you can see from the video, I still needed a serial console on a laptop so I could see what I was typing, and the last line of text output was hidden by the printer case, but it basically worked.
I got thinking about some kind of hybrid computer with an LCD or OLED display for text entry and showing what you’re typing, and a thermal printer for hard copy and program output. I couldn’t be bothered to solder up pins to my spare Arduino Pro Mini, so I decided to see if I could use a micro:bit instead to drive an OLED display. The micro:bit is great for quick prototyping – no soldering required and it’s a breeze to program in MakeCode or Python rather than C++ used by the Arduino.
First I had to do some level shifting: the Arduino works at 5v and the micro:bit at 3v, so I used a 1K and 2K resistor as per this guide to make a voltage divider, dropping 5v to just over 3v so I didn’t damage the micro:bit. So, the serial TX pin of the Arduino is connected to a 1K resistor, the other side of which is connected to Pin 1 on the micro:bit and also to a 2K resistor which goes to ground. It’s a very crude level shifter and it may explain why I had to reduce the baud rate, but it does seem to do the job. The grounds on the micro:bit and Arduino are linked, and I back-powered the micro:bit from the 3.3v pin on the Arduino UNO. I also used a MonkMakes I2C breakout board to connect the OLED display to the micro:bit and used two Python libraries ssd1306.py and ssd1306_text.py to drive the OLED display.
As you can see that was a bit flaky, but slowing the baud rate down to 1200 and adding some delays at the start of the Arduino TinyBASIC program worked a treat:
All good fun and confirms the idea is sound, but alas the text is too big and the display too small, so my next step will be to replace the micro:bit with an Arduino that can print smaller text on an OLED display – or maybe even a 4 line LCD display? And if that doesn’t prove workable, then I just may well fall back on making a machine that has an old-fashioned composite video output!
FYI, the current version of my micro:bit Python program looks like this. It just polls pin 1 for serial data and prints anything it receives on the OLED display. If it gets confused it shows a ‘?’ on the micro:bit’s LED display.
from microbit import *
from ssd1306 import initialize, clear_oled
from ssd1306_text import add_text
import micropython
# baudrate was 19200 for thermal printer
uart.init(baudrate=1200, bits=8, parity=None, stop=1, tx=None, rx=pin1)
micropython.kbd_intr(-1) # disable accidental keyboard interrupt
initialize()
clear_oled()
x = 0
y = 0
while True:
if uart.any():
msg_bytes = uart.readline()
msg_str = str(msg_bytes, 'UTF-8')
if len(msg_str) > 0:
try:
for char in msg_str:
if ord(char) > 31:
add_text(x, y, char)
x += 1
if x > 11:
x = 0
y += 1
if y > 2:
y = 0
clear_oled()
if x < 0:
x = 0
if y < 0:
y = 0
elif ord(char) == 13: # new line / CR
x = 0
y += 1
except:
display.show('?')
Update 1 - adding a 2nd Arduino with an OLED display
Despite hating soldering so much previous me hid my solder from myself in the loft, I've made progress replacing the micro:bit with a cheap Arduino Pro Mini clone driving the OLED display with a smaller, and hence more useful, font.
I just connected the serial TX pin on the Arduino UNO running BASIC and polling the keyboard to the serial RX pin on the Arduino Pro Mini that's driving the OLED display. Despite my truly awful soldering of pins on the Pro Mini, it works!
The Pro Mini doesn't have a USB adaptor, so you need something like an FTDI adaptor to bridge between the Pro Mini and a computer running the Arduino IDE. My adaptor needed 2 extra pins soldering (CTS and RTS) and I had to figure out what they connected to. In the highly unlikely event anyone has the same FTDI adaptor and is wondering how to connect one to a Pro Mini, here's the wiring you need:
Pro mini > FTDI adaptor
-----------------------
DTR > RTS (data terminal ready > ready to send)
TX > RX
RX > TX
VCC > 5v
GND > GND
GND > CTS (clear to send)
You'll also need to disconnect anything from the Pro Mini's serial input before you flash a program or it won't work. Also make sure that you have the correct voltage FTDI adaptor - mine has jumpers that allow you to select 3v or 5v, I've selected 5v as I have a 5v version of the Arduino Pro Mini.
My FTDI adaptor with 2 extra pins soldered
Here's the Arduino program I wrote to put text received on the serial port on the OLED display. It uses the Adafruit SSD1306 library. Note that I had to change the I2C address from the Adafruit code example to 0x3C for my display, and if you try this you may also need a different number. Also it's still using the very slow serial transfer rate of 1200 baud I was using with the micro:bit, which almost certainly could be speeded up.
#include <Wire.h>
#include <Adafruit_SSD1306.h>
#define SCREEN_WIDTH 128 // OLED display width, in pixels
#define SCREEN_HEIGHT 64 // OLED display height, in pixels
int incomingByte = 0; // for incoming serial data
int x = 0; // counters for working out rough cursor position to clear screen when full
int y = 0;
// Declaration for an SSD1306 display connected to I2C (SDA, SCL pins)
Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, -1);
void setup() {
Serial.begin(1200);
// you may need to change 0x3C depending on your type of OLED display
if(!display.begin(SSD1306_SWITCHCAPVCC, 0x3C)) {
Serial.println("SSD1306 allocation failed");
for(;;);
}
delay(1000);
display.clearDisplay();
display.setTextSize(1);
display.setTextColor(WHITE);
display.display();
display.setCursor(0, 0); // Start at top-left corner
display.cp437(true); // Use full 256 char 'Code Page 437' font
}
void loop() {
if (Serial.available() > 0) {
incomingByte = Serial.read();
display.write(incomingByte);
display.display();
++x;
if (x == 20) {
x = 0;
++y;
}
if (incomingByte == '\n') {
++y;
x = 0;
}
if (y == 8) {
display.clearDisplay();
display.setCursor(0, 0);
y = 0;
x = 0;
}
}
}
I think the best solution for this project would be a 256 x 64 pixel OLED display driven by an Arduino. They cost around £27, compared with less than £5 for a 128x64 OLED, but as someone pointed out to me on Twitter, a wide OLED would have similar dimensions to a Radio Shack TRS80 Model 100, which is exactly the vibe I'm aiming for.
So, before I get one of those, I decided to see how the video out version in Rob Cai's original project worked. It was amazingly simple to make. I removed the OLED display and repurposed the second Arduino as a 'video card'.
First I added the MRETV library to the Arduino IDE as per his instructions, then I flashed Rob's TVtext_slave.ino file to my second Arduino. I found 1 typo in this file I had to fix. The line #include <MrETV.h>
should read #include <MRETV.h>
(capital letter R).
As per Rob's guide, I connected pin D2 on the Arduino via a switching diode to a 1K resistor. The other end of the 1K resistor is connected via a diode to TX pin 1 on the Arduino. Where the two resistors join, I tapped off a wire that goes to the centre pin on an RCA / phono plug that provides the video out. Connect this plug to the composite video input of a TV.
I've not connected the sound yet, so I'll do that next then see if I can improve the keyboard mapping, maybe wire up a reset button and investigate if I can get a delete key working. And maybe even see if I can modify the font!
I've also been messing about with KiCad for the first time, and I think this is what Rob Cai's circuit looks like:
NIM is a simple but potentially infuriating, ancient 2 player game. You have some counters or matchsticks, you’re allowed to take a limited number in each turn, say 1, 2 or 3. The winner is the person who takes the last counter.
Sometimes it’s played the other way round, so the player left with the last counter loses. This is called a misère game, but there’s enough misère in the world as it is, frankly, so we’ll play the happier version of the game today.
Thinking about this game makes a great maths investigation, and it can be a good computing activity too. Challenge your students to write a program that will play and beat a human, or modify and improve the programs I’m going to show you in this video.
Anyway, I decided to see if I could write a BBC micro:bit program so that the micro:bit could play a human at NIM and always win. Perhaps you could challenge your students to do the same and see what they come up with – can they identify winning strategies, and abstract them into a working computer program?
I approached this challenge by taking the really simple NRICH example and applying Matt Parker’s strategy from his Dr Nim video.
The key here is to think of the end game and the position you want to get your opponent into.
In the Dr Nim game Matt Parker shows in his video, you have 12 marbles and can take 1, 2 or 3 counters in each turn. So he chunks the game into multiples of 4.
In every go, whatever you take, Dr Nim will take whatever number he needs to make sure you’ve taken 4 between you.
oooo / oooo / oooo
So if you take 1
oooo / oooo / ooo
Dr Nim will take 3.
oooo / oooo /
If you take 2
oooo / oo
he’ll take 2.
oooo /
If you take 3,
o
he’ll take 1 – and win!
Now, we’re computer scientists so we always want to abstract some kind of pattern if we can, to make any coding more efficient, so straight away I notice that if the human takes n counters, Dr Nim takes 4-n counters.
Also I notice that with the option to take up to x counters, you want to break down into chunks of x+1, so that if your opponent goes first, you always have the advantage. You want to make sure they always have x+1 counters at some point when it’s their turn to go.
Hold that thought! We’ll come back to it later.
So, back to our micro:bit version of the game. I’m going to follow the NRICH example and say you can only take 1 or 2 counters in each turn, but I’m going to start with 9 counters instead of 7.
This simple version is easier to think about, work out all the permutations, and easier to code. Also we can use micro:bit button A to take 1 counter, and button B to take 2 counters, so we’ve got a nice simple user interface.
So I coded a version for the micro:bit. Try and beat it:
You could play many more games, and trust me the micro:bit will always win.
So how does it work?
Remember Matt Parker with his 12 marbles or pegs which he treated as 3 lots of 4? Well he had sets of 4 because the choices were to take 1, 2 or 3. The chunk you’re working with should be one more than the highest number you can take in a turn.
We can only take 1 or 2 counters in our micro:bit version of the game, so we’ll treat it as three lots of three:
ooo / ooo / ooo
We’ll make the sap, sorry the human, go first. Remember, in a pair of turns, we need to make sure the human and machine have taken 3 counters between them.
Each time, if the human takes 1 counter…
ooo / ooo / oo
our program will take 2:
ooo / ooo /
If they take 2
ooo / o
the program will take 1:
ooo /
As there are only two choices at each turn, we can hard code this into blocks that follow each button press:
Here we use a function to update the display and check if the game’s over. I added a bit of logic to show different messages depending on whose turn it was when the last counter was taken, though with these numbers, the ‘you win!’ message will never be displayed. Try altering the number of counters you start with and see if that makes a difference. Does the program still work?
Now, do you notice anything about these two sets of code?
They are very similar! There’s a pattern here, and when computer scientists spot patterns, they get all excited because there’s an opportunity to be clever and make the code more compact.
We do that in this new version of the project by creating a function that does the same work, just slightly differently depending on how many counters the human took.
Remember that formula 4-n earlier? I spotted that in Dr Nim, if the human takes n or marbles, Dr Nim would always take 4-n marbles and be guaranteed to win, because that game works in blocks of 4 counters.
I kind of use that here.
The variable humanGo keeps track of how many counters the human player took.
We set the number for the computer to take, by using 3-n. Our game works in blocks of 3, so we set the computer’s go to be 3 (or minus 3 here) minus the human go.
Why is it minus 3 here not 3? I’m using negative numbers here just to make the block simpler when we change the total number of counters, stored in the counters variable. MakeCode doesn’t have a block to change the sign of a number. Well, not yet. I’ll have to see what I can do about that. I’ve managed to sneak at least one new block into MakeCode, possibly even one used in this project, it’d be fun to have another one to call my own.
So this version of the code works in exactly the same way, it’s just a bit more efficiently coded. It’s cleverer, using a function to avoid repeating two very similar sets of code.
But is it easier to read, follow and understand?
Probably not. This is something that would make a great discussion point with a class of students. Which version of these programs is ‘better’? Which is easier for someone to come along and understand and modify, or if you yourself look back at your own code months or years later and wonder how on earth you wrote it and what it does?
The first one makes it very easy to follow what happens in each case. But if you want to adapt this to play a more complex version of NIM, say with 12 counters and the ability to take 1, 2 or 3 at each turn, the version with the clever function is probably going to be more adaptable.
Have a play with these, and if you adapt my code to make a more advanced game of NIM, please let me know. You could use shake gestures, wire up 3 tin foil buttons to the pins, or use the touch logo on the new micro:bit (V2) to get more button inputs for more choices.
Like the Dr Nim game in Matt Parker’s video, perhaps you can create an ‘equaliser’ mode where the poor human player has at least a chance of winning?
Have fun annoying your friends and relations with your unbeatable NIM micro:bit machines!
I’ve been exploring writing a very, very simple text-based language for the micro:bit, in Python. I think it could be an educational project in two ways:
A task for older students to design and create their own language.
Make a text-based language for younger students that’s simpler than Python, simpler even than BASIC or TinyBASIC.
I made a few rules for myself, the main one being that no quotation marks will be used. This poses a few challenges, but I wanted users to be able to code it using just words and numbers and maybe a few operators like =, +, -, <, >
It should also be so relaxed about variable types it makes even Python look uptight.
This is still very much a work in progress, but I think it’s got potential. Its main differences from BASIC are:
Commands you enter aren’t executed, they get added to the program listing
Line numbers are assigned automatically and run from 0 in steps of 1
You can delete and amend lines but you can’t, currently, insert lines. I should probably fix this.
Here’s how it works.
You’ll need a BBC micro:bit and a computer. You type your program on the computer in a serial console (which can just be a web page), and the micro:bit will output to the console, its LED display and sound on pin 0 (or the built-in speaker if you have a V2 micro:bit).
Flash the Python program file to a BBC micro:bit and connect a serial console to it. You can use the Chrome browser and either the micro:bit Python editor or an online console like the Chromelabs one. If you use the Python editor, click ‘Connect’ and then ‘Open serial.’
You should now be in ‘Mi:Little Coder’, or ‘smolBASIC’ as I’m now calling it, because it’s smaller than TinyBASIC.
If you enter > heart
> pacman
> ghost
> run
you should see three icons display on the micro:bit.
Type list and you’ll see your program listed: 0 heart
1 pacman
2 ghost
If you want to get rid of the ghost, type del 2 to delete that line.
You can replace lines by typing a new instruction starting with the line number: 0 rabbit
You can scroll words on the display. Type ‘scroll hello world’ and list your program again: 0 heart
1 pacman
2 scroll hello world
Start a fresh program by typing new
You can play notes and tunes with play B
play E
play F
You can save and load your program with save and load. You can only save one program at a time, but it’s stored in non-volatile memory, so if you unplug the micro:bit, then plug it back in you can type load to get your last program back. I think this is pretty neat.
I’m not sure this language is ‘Turing complete’ but it must be close: it also has the ability for the user to enter data, store it in variables, test it and branch according to the results.
Here’s a program that asks how old you are and gives different responses in the console:
0 print enter your age
1 input a
2 b=17
3 if a>b goto 6
4 print you are too young to vote
5 stop
6 print you can vote
Have a play with it, and see what you think. It was created on a whim, I know my Python code is terrible, it can be made more compact and should probably work more like BASIC to run commands whether run from a listing or typed direct. Or should it? What do you think?
I’ll also be doing some more reading about the roots of Tiny BASIC – I’ve been enjoying reading ancient copies of the People’s Computer Company from 1975, it’s fascinating to see the concerns and ideas of some of the pioneers of home computing, including those who wanted to create a simple, text-based language that fitted in very little memory on cheap systems and that was given away for free… unlike Microsoft BASIC, you didn’t have to steal or buy Tiny BASIC, it was ‘copy left’ and free.
I’ve written before about how the KIM-1 (my brother’s) was the first computer I ever used, and how the very first programming I did as a child was 6502 assembler rather than BASIC. This led to me to make little machine code machines with micro:bits, and build my own 6502 breadboard computer, based on Ben Eater’s design but adding a hex keypad not a typewriter keyboard.
I was very strict when building my 6502 computer just to use tech that is roughly era-appropriate, eschewing microcontrollers for example. This puritanism is all well and good but caused me to neglect this very neat KIM-1 emulator for the Arduino Pro Mini: the KIM Uno.
You can download the PCB files and get it made yourself, it’s a very simple build and the components are very cheap, really just an Arduino, a couple of 7-segment LED displays, 24 buttons and a few resistors. I was reading the documentation when I got to the line ‘Actually, the software will run on any Arduino.’
That got me thinking. Maybe I have all the bits I needed to build one of these lying around, assuming I used a breadboard instead of getting a PCB made. I certainly have millions of those little buttons, an Arduino Uno, piles of resistors, some 4×4 membrane keypads that would be easier to wire than individual buttons and some LED displays.
I compiled the code onto my Arduino Uno, and using a serial connection over usb connected to it from my laptop at 9600 baud using the awesome Chromelabs in-browser serial terminal. And it worked! You can switch between ‘normal’ mode and ‘luxury’ terminal mode by pressing the tab key. They call it ‘luxury’ mode because back in 1976 you’d have to have been seriously minted to be able to afford a teletype machine to connect to your KIM-1. Most people used the keypad and the 7-segment LED displays.
It’s a great emulator, with some useful utilities built in, as well as Peter Jennings’ Microchess: a working chess program in ~1K of machine code. You should read up on its creation, it’s an interesting story about a genius piece of coding.
I love programming. It is almost impossible to explain the joy of writing software to someone who has not experienced it.
First and foremost, it is an act of creation. From a simple thought, and the arrangement of a few words and symbols, a reality is created that did not exist before.
No other activity can keep you in the moment the way that writing software can. At each step, one hundred percent of your concentration is applied to the solving of the current problem. Time disappears.
Peter Jennings
So having proved the concept, I set about trying to build a KIM-1 clone using the KIM Uno’s software and schematics, and the bits and bobs I had lying around.
Snag 1: no breadboards.
Solution: rip apart another project and hope I documented it somewhere.
Snag 2: the keyboard layout is nuts. I mean really nuts.
The original KIM-1 had 24 keys arranged in 6 rows of 4. Indeed so does the KIM Uno.
But that’s not how they’re wired. No, siree. It’s wired in a matrix of 3 rows of 8 buttons.
It’s actually very clever. I did wonder when adding my keypad to my own 6502 computer how the designers of the KIM-1 didn’t run out of GPIO pins. The answer was they actually shared the pins between the keypad and the display segments and switched them very, very quickly.
Here’s how to wire it up. With the membrane keypads, I’ve numbered the pins looking from the front, so pins 1-4 are the rows and pins 5-8 are the columns. You need to join the rows together to make 1 very wide keypad. So, connect row 1 on keypad A to row 1 on keypad B. Do the same for rows 2 and 3. These become rows 0, 1 and 2 on the KIM keyboard. Connect rows 0, 1 and 2 via a ~2K ohm resistors to pins D9, D10 and D11 respectively on the Arduino.
Now wire up the columns.
Keypad A pin 5 / column G -> Arduino pin D8
Keypad A pin 6 / column F -> Arduino pin D7
Keypad A pin 7 / column E -> Arduino pin D6
Keypad A pin 8 / column D -> Arduino pin D5
Keypad B pin 5 / column C -> Arduino pin D4
Keypad B pin 6 / column B -> Arduino pin D3
Keypad B pin 7 / column A -> Arduino pin D2
Keypad B pin 8 / column DP -> Arduino pin A5
Snag 3 – the displays
It turns out that my lucky bag of random 7-segment LED displays wasn’t so lucky. They’re all common cathode, when the design for the Kim Uno needs two common anode displays. They’re very cheap to buy, but while I wait for one to arrive, I noticed that you can also attach an OLED display to it, if you uncomment a line in the config file and connect the display’s data pin to A4 on the Arduino and the display’s clock to Arduino pin A4.
The sketch will only compile for a Uno if you remove almost all the sample code, and you get this intriguing display which doesn’t make a whole lot of sense (there is separate firmware to turn your KIM Uno into a Cosmac Elf) – I was expecting to see the LED display mirrored on the OELD!
I’ll have to order a couple of common anode LED displays and maybe an Arduino Pro Mini and report back. Oh, and I’m probably going to need a bigger breadboard.
The keypads relabelled with masking tape and Sharpies. The layout is a bit crazy, but hey the original KIM-1 keypad layout doesn’t make a lot of sense to me either, and this saved a metric tonne of fiddly button breadboard wiring.
We’re going to need a bigger breadboard
I got some common anode LEDs and made this. It worked. Almost. One segment of the LED display didn’t light and I couldn’t figure out why:
So I got a bigger breadboard and wired it all up from scratch, spacing everything out a bit more. I missed one jumper out and one was in the wrong hole, but once I’d fixed that, I have a working self-contained Kim-1 clone / simulator! You can use the keypads and LEDs and the serial port on a computer as well, living the 1976 computing dream!
Next step will be to put it in some kind of box that supports the keypads, and then to replace the Arduino Uno with the Arduino Pro Mini – pictured at a jaunty angle on the breadboard. I just realised that as it has pins running all the way round it, it’s not going to work on a breadboard. Doh! I guess I could get another small Arduino that does, or use male to female jumper wires and let it float.
Arduino Nano update
I made a more compact version using a cheap Arduino Nano clone that fits on the same breadboard as the LEDs and the resistors. I bought a pre-soldered one to save time and swearing.
A couple of things to note:
It was hard to get the pins of the Arduino into the breadboard. In the end I had to work a jumper wire down each row prior to insertion to loosen the holes up a bit.
At first the sketch wouldn’t flash on to the Arduino. I got the error message ‘stk500_getsync() attempt 1 of 10: not in sync: resp=0×00′. Turns out this was because I needed to select old firmware in the Arduino IDE. Go to Tools > Processor > ATMega328P (Old Bootloader) before flashing the Kim UNO code to a cheap Nano clone.
I successfully powered this off a PP3 / 9v battery, making it completely self-contained. Unplug the Arduino from any other power source like USB, connect the +ve battery terminal to the Arduino’s Vin pin, and the battery -ve terminal to GND on the Arduino.
