Category: Programming

CPU Journey

The 6502 was the first CPU that I programmed1 in machine code — on my Vic-202 and on BBC Micros3 at school, back in the 80s. I wrote a few simple games for the Vic-20, mostly because its limited 3.5Kb memory made it hard to do anything in BASIC. On the BBC Micro I got a bit more ambitious and wrote something that I imagined was like a simple round-robin, cooperative multitasking scheduler. The cassette tapes containing that code will all be somewhere in a landfill site near Hull, whiling-away the time until entropy reduces the bits to noise.

Later I wrote some code for the Motorola 6809. And later still I used 68000 dev boards as an undergraduate. We had to upload assembly language to an honest-to-god minicomputer to be assembled to machine code before we could find out if the seven-segment LED display would do the right thing, or whatever it was.

(During an intern year at IBM I remember talking to an employee who was writing System/36 microcode to interface a transputer development board to a 3090 mainframe. Godlike stuff, and way beyond me.)

It’s been a while now, but I remember feeling that the 68000 was clearly powerful and elegant and a “proper CPU”, but also that I had little hope of understanding all the details of its operation. The 6502 was my first, and with hindsight was far less elegant with plenty of warts, but I felt at the time that I understood it pretty well. The 6809 was somewhere in-between, I guess, and a very nice CPU to work with.

As a professional developer I haven’t had to write a single line of machine code or assembly language these thirty-odd years. Maybe I should be glad. Even now, though, I try to think of computers as physical machines with physical characteristics and limits — even if the tools and developer experience try to convince me otherwise.

I’ve never thought about it before today, but I suppose I benefited from that early progression from 6502 to 6809 to 680004. Whether or not it makes sense as a journey nowadays, I couldn’t say.

  1. It occurs to me that we seldom talk about programming computers any more. We write code or apps, separated from the hardware. ↩︎
  2. Yes, machine code. The Vic-20 didn’t have a built-in assembler and, while I think I was aware that such as thing could theoretically be obtained somehow, I had no idea how to go about doing that. All I had was a monthly subscription to Commodore User magazine and my falling-apart copy of the Vic 20 Programmers Reference Guide. So I wrote-out the assembly language on paper and hand-converted it to machine code. Debugging was even more fun. ↩︎
  3. BBC Basic had a good, built-in, two-stage assembler. ↩︎
  4. I never got on with the Z80: that brash upstart /s ↩︎

Photos news

Herewith a housekeeping announcement about changes to the photo galleries on this site.

Prior to some time in November the photos at andyjohnson.uk/photos were served by an old installation of Lychee. Nice as Lychee is, I’d grown a little frustrated by the difficulties of uploading photos from my phone. I’d also, frankly, forgotten how to build Lychee on Windows — a problem, as I was intermittently aware that the installation was out of date.

So I retired Lychee and, for a while, brought the photos into WordPress and served them using a plug-in called Modula. This worked fairly well, and Modula is slick and pretty, but in the end I concluded that it wasn’t the best solution for a couple of reasons:

  1. Modula requires that all photos are stored in the WordPress media library, which lacks a way to group related images into albums. There are various plug-ins that provide a folder-like overlay on-top of the media library, but they don’t change the underlying organisation of the library. Without using some sort of naming file convention, it looked like it would be difficult to keep things organised.
  2. Modula is primarily designed for ecommerce sites that use images for product information. Its not a good fit for a personal photo gallery.

So I looked around at self-hostable photo gallery software that could run on the VPS that hosts this blog: basically a standard Linux/Apache/PHP virtual machine with only control panel and ftp access. And after a bit of research I decided to try Piwigo.

I’d looked at Piwigo several years ago but found it to be clunky and distinctly web 1.0-ish. In the years since it seems to have been successfully dragged into the JavaScript era, and now seemed quite snappy and pretty. It also has an updated Android uploader app. I decided to give it a go using Bootstrap Darkroom, which looked to be the most up-to-date of the various themes that Piwigo supports. I fairly quickly found that it did 90% of what I wanted, but the theme lacked some polish. Piwigo has a nice event-driven extensibility mechanism that allowed me to push this to 95% using just config tweaks, but the theme still lacked one thing I wanted: the ability to show the EXIF description or IPTC description metadata next to the image.

At this point I thought “hey, I’m a software developer – how hard can it be…” so I forked the repo. What I should have thought is “hey, I’m not a web developer – this will be hard…“. But I persevered and got properly familiar with npm and yarn and sass and PHP and VS Code, and dug into how to build the five year-old theme code with all its legacy dependencies… and it wasn’t easy. But I’m back now, battle-hardened and glad to be alive, and now I give you my Dark Aperture theme for Piwigo:

Dark Aperture theme screenshot
Dark Aperture theme example screenshot

It’s based on the Bootstrap Darkroom codebase, with a bunch of enhancements and fixes that are specific to my needs. I make no claims that it is useful to anyone else. My thanks to Thomas Kuther, who wrote the code that I merely adapted and tweaked

The theme’s name comes from Wide Aperture, which is the least-worst name I could come up with for the new Piwigo site running my new theme. I think it looks pretty good.

For the time-being the site has a few albums that are a subset of the photos that were on the old Lychee site. After I’ve recovered from all this webdev I’ll upload a better, wider selection.

BF

When you know deep-down that a Brainfuck interpreter should only ever be written in C, but you’re not quite ready to leave the comfort of C#. So in a spirit of minimalism you find yourself writing C# in a C style just for the hell of it.

public static void Execute(string program, Stream? input, Stream? output)
{
    int ip = 0;
    int dp = 0;
    var data = new byte[30000];

    while(true)
    {
        if (ip >= program.Length)
            break;
        switch(program[ip])
        {
            case '>':
                dp++;
                break;
            case '<':
                dp--;
                break;
            case '+':
                data[dp]++;
                break;
            case '-':
                data[dp]--;
                break;
            case '.':
                output?.Write(data, dp, 1);
                break;
            case ',':
                input?.Read(data, dp, 1);
                break;
            case '[':
                if (data[dp] == 0)
                    ip = JumpTo(']', +1, program, ip);
                    break;
            case ']':
                if (data[dp] != 0)
                    ip = JumpTo('[', -1, program, ip);
                break;
        }
        ip++;
    }
}


private static int JumpTo(char match, int incr, string program, int ip)
{
    while (true)
    {
        ip += incr;
        if ( (match == ']' && program[ip] == '[') || 
             (match == '[' && program[ip] == ']') )
            ip = JumpTo(match, incr, ip, program);
        else if (program[ip] == match)
            return ip;
    }
}

This made me wonder if the style of a language affects the style of its implementation. Not sure.

(For any impressionable children reading this: don’t do it this way. Use descriptive variable names and comments and put braces around your if/else clauses.)

(And for any hiring managers reading this: its deliberate, I promise.)