I just received an email from my chum Ken Wood who has been following my recent Flashing LEDs and Drooling Engineers columns in the UK’s premier electronic, computing, maker, and hobbyist magazine, Practical Electronics.
Just to bring you up to date, a few days ago I posted two videos that will be accompanying the December 2020 issue of the magazine. These videos show my 12×12 array of ping pong balls, each containing a tricolor LED.
Recent experiments have involved “virtual drips” falling on the array and lighting the pixels with random colors. In previous articles and videos, we’ve implemented only a single virtual drip at a time. By comparison, in the first of these new videos, we allow multiple drips to be active at the same time, with their start times being randomly determined such that they overlap in interesting and unpredictable ways.
In the second of these videos, each drip is accompanied by an associated splash effect. A short time after a drip drops and starts to fade up (the drip location and color being randomly selected), the pixels to the north, south, east, and west also start to fade up to a muted version of the main drip color. Then the main drip pixel fades away, followed by the splash pixels fading away.
But we digress… an edited version of Ken’s email read as follows:
Hi Max, let me throw something random at you. I guess you must be (like me) a long-term Scientific American reader? Going back many years, there was the famous (in the right circles) “Mathematical Games” column by Martin Gardner. Martin was followed by Douglas Hofstadter, who was, in turn, followed by Alexander Dewdney who held the post from 1984 to 1991. Meanwhile, the column was renamed to “Computer Recreations” and later to “Mathematical Recreations.”
In 1984, Alexander wrote a column about a programming game called Core War that he had created with D.G. Jones. A scan of this original article, along with a lot of supporting material, can be found on the CoreWars.org website and Wikipedia.
The overall idea is that a simulated computing environment hosts a circular buffer memory array, into which are loaded two competing programs comprised of a very restricted instruction set. The programs are loaded at random offsets, all addressing is relative, and each has a separate execution pointer with instructions being executed alternately.
The objective is to be the last program not to crash. To that end, each program can try to sabotage the other one (e.g., by bombing random locations with stop instructions), and/or try to defend itself by self-repairing. The more sophisticated the program, the larger it is, and therefore the bigger the target it presents for bombing.
Human contestants design their candidate Core War programs, which are then pitted against each other in pairs as a tournament.
I figure this can be made visually appealing by presenting the memory array on a screen (or ping pong ball array) and color-coding each cell either “Neutral,” “Last written for or by Program A,” or “Last written for or by Program B” — using green, blue, and red respectively, for example — and running the programs at only a few steps per second so progress can be followed.
Needless to say, this is one of those “rainy day” ideas that’s been on the shelf for close to 40 years. Your 12×12 ping pong array isn’t very big, but it might be just big enough for a demonstration using a pair of small programs.
I must admit that I’m intrigued. As soon as I’ve posted this Cool Beans Column, I’m going to read up on the Core War concept. Even if it’s not possible to display the whole memory space on my 12×12 array, maybe we could display a subset or a “zoomed out” version (in which each pixel represents a number of memory locations) or a summary-type display. I would be interested to hear your thoughts on this.
And, as one final note, for your delectation and delight, both print and digital versions of back issues of Practical Electronics are available for purchase. Even better, the code for each of the sketches (programs) discussed in my PE columns is available for free download, even if you don’t have a subscription to the magazine.
POSTSCRIPT: I just read this beginner’s guide to the Redcode pseudo assembly language that is used to create programs that run on a virtual machine known as a Memory Array Redcode Simulator (MARS). Now I’m thinking that we should create our own MARS simulator to run on the Seeeduino XIAO (that I’m using to power my 12×12 array). Once we have this, we could combine it with our already existing 12×12 array Simulator, which would let anyone create Core War warriors that we could run on the array. One thing we will need will be an assembler that can assemble Redcode into a form that can be incorporated into our MARS simulator. I’ll be interested to hear what you think about all of this.
Here’s a good introduction to the Redcode pseudo assembly language that’s used in Code War: http://vyznev.net/corewar/guide.html
Based on what I just read, I’ve added a POSTSCRIPT to the column above.
Hi Max,
I see there were a number of errors in my recollection (which you have put right, thanks) – it was nearly 40 yers ago (but some things stick, like when I read about RSA encryption)! It seems my idea to visualise the battlefield was not actually my idea – I didn’t remember that part (or perhaps I never read that particular article)!
I now think 144 locations isn’t too bad for a Core Wars demo. The sample warrior programs in the original articles are 1, 4, 8, and 11 instructions long.
If anyone (with more spare time than me) wants to stretch this even further, designing Core Wars warrior programs might be amenable to evolutionary genetic algorithms.
Hi Ken — initially I thought 144 locations would be way too small — but after reading up on the Redcode “assembly language” I agree with you — I’m looking into this as we speak — thanks for sharing this idea with me — Max