mattlacey.com

Matt Lacey — Tue, 03 Feb 2026 00:00:00 GMT

In September I looked back at my '25 resolutions and turns out I'd gotten something done for once. For 2026 I'm not setting resolutions as I don't feel I can be resolute about them right now. Time is scarce and my mind is fickle. Still, there are some things I'd like to do, including writing more. So I'm writing something down just for my own accountability as much as anything.

2025 Final Status

These are the goals I set for myself, along with some updates

Finish the port of the ZX Spectrum Next game - did this and released it!
Get a fully playable 'demo' (i.e. at least one level) of my STE platformer - a complete vertical slice - Yeah, not so much. I did get it compiling and running again but that was about it
Get the engine out of the Honda, then remove from the block the stuck exhaust studs. At some point someone welded nuts to these in an attempt to get them out and still couldn't budge them. I think a drill is going to be required As per my September status update, the engine is out. I need more space to do more work on it, and an engine hoist.
Stretch Goal - Get the Honda running - yeah..... I'm gonna go head and as you to forget I wrote that

2026 Best Intentions

Write more. That should be easy enough if I just force myself to choose a topic
Get something going on the Net Yaroze. I've had one of these since the program was active, but never really achieved anything. I recently took my Atari STE off my desk for a bit to get it set up again, and my intention is to get something 3D on the screen using only what I had available at the time. I've got Code Warrior running under Windows 2000 on an old PC, I've dug out the reference manuals and I'm getting stuck in
Make some kind of progress with the Honda - ideally strip the engine down at a minimum

Matt Lacey — Thu, 25 Sep 2025 00:00:00 GMT

Excuse my language, but I feel it's necessary to explain the levels of my confusion right now. Like it or loathe it, generative AI has changed the coding game. I've not played with a lot of tools, and have really only used Claude Code in anger for a couple of months, here's a brief overview to set the stage:

Claude Code - I'm using this for work. It's impressive but it's performance fluctuates
Devin - I had a look at this for work, but it's VM based setup didn't really work well with my flow. Claude working on my machine was a better setup for how we operate
ChatGPT - I've asked it for code on occasion, and it's so-so. I wasn't sold on using AI for code at work until I tried Claude Code
Lovable.dev - Utilised this for a couple of prototypes, I don't think it's good enough to build something proper, but if you want a very fast POC/interactive prototype that looks nice, it's prettyy damned good
Cursor - Installed it, played for a bit, but didn't want to switch IDE. I tend to use a combo of (n)vim/vscode and the CLI (for git etc.)

So when I talk about AI in this post, I'm mostly referring to my experiences with Claude Code, but from what I've seen there's not a lot to choose between the major players in terms of capability, more just how they operate.

A World of Contrasts

Most of my confusion around AI and where software development is headed stems from the fact that it's capabilities are so mixed, and the ecosystem around it so messed up. Ed Zitron is the man to follow if you want a chance in hell of understanding some of the financials, and they're frankly bonkers. AI tools are cheap right now, but the companies providing them are burning cash and energy at an unfathomable rate. I think we're in a window of opportunity where these tools are capable and cheap, I don't believe that window will be open for long, and for some businesses now is the time to make hay. Something has to give.

It's all too easy to be fully doom and gloom about it, so for now I want to ignore the financial side, I'm considering only what the tools do now for the money they cost now as an end user. Are they bad for the planet? Yes. Are prices going to have to rise? Yes. Might it crash the whole tech industry? Good odds. But as I said, let's ignore that. I just want to get my thoughts out as a long-time coder. So, what are the contrasts of which I've hinted? Here's a short list:

Generative AI can't think, but god damn it does a good impression of thinking at times
Claude knows more than I do about every single dev technology I can think of, and lot more that I've not even heard of. From my day-to-day web stuff, to the BeAPI reimplemntation in Haiku, to coding for the Motorola 56k DSP (a few years ago no LLMs had a clue on this)it knows a LOT. And yet knowing is only half the battle.
AI is super fast at generating code, but said code is often iffy, sometimes outright broken or incorrect
Sometimes it feels like a super intelligence, at other times it feels dumber than a bag of rocks

So where does that leave us? In summary, Claude Code is the fastest and most knowledgeable junior developer I've ever worked with (and I've had the pleasure of working with some great junior developers). No I can't use a lot of it's output verbatim, but the correction and feedback loop is so fast a human just can't compete.

So What Does That Mean?

I don't have no idea, which is why I wrote this, not that I expect it to help. What does this all mean? Where the fuck are we going with this? I really don't know. I believe those poised to get the most out of these tools right now are those with a decent whack of experience under their belt, because the output needs careful review, and the AI needs guiding. Some of the output is terrible, some just needs tweaks, and some needs an experienced eye to spot an issue. I feel deeply for those just graduating or entering our field, they likely don't have the experience to judge the output themselves and therefore can't use the tools in the same way, but they can use these tools to help learn. From a learning perspective, it's a world apart from learning from books, guesswork, and QBASIC online (as in built-in, not on the net) help I started with. I still recall installing the CD based MSDN library and it feeling like a revolution, all that information so easily searchable! That kind of learning defined a lot of my formative programming years, but learning today can be as simple as a series of very specific and pointed questions that get almost immediate answers.

The tough/brutal/shit part is this: if LLMs are as good as juniors, but faster and far cheaper, then suddenly it makes hiring juniors a very tough proposition for a company. Of course it's the right thing to do, but sometimes the dollar wins, and that doesn't mean turning a profit, it might just mean not going out of business. Depending on whether it all goes to shit or not, hiring any developers might be a laughable proposition in a few years time; maybe we're all done for. In the space of a few months I've accepted that my job has changed, but it's not necessarily a bad thing. I wasn't enjoying fixing crappy bugs in Jira tickets, and now I don't have to do that so much. Sure I have to review the output and check each one, but I can outsource the tedious work of it.

There's an argument that developers love to code and that's why we do it for a career: it's true for many and was for me, but I'm more than happy to keep the act of programming for my hobbies where I can tinker with retro computers and random projects without having to worry about crappy CSS issues on a specific device, or wondering why iOS 26 is now showing a black bar where a keyboard should be. I'm tired of those problems and that kind of work, and now Claude can do it for me. That's not even hyperbole, on a few occasions I've pointed it at a Jira ticket and it's read it, looked at the code, suggested a fix inside of a minute, and it's gotten it correct with no changes required.

Yes, some (many even) tickets I can do faster myself, and some I chose to, but the real speed up is not in having it replace me, it's having it do one thing while I do another. Or having it do two or three things while I do another. I've done this. I've had it working on a R&D prototype, fixing a bug, and documenting a process for a team member; all while I've been investigating another bug in a specific customer environment. There are genuine use cases where this can boost my output, so that's great right?

That is Great! And Yet...

And yet. And fucking yet. Sure, it is great from a let's-save-money-and-not-hire-juniors point of view, but if we don't hire juniors, how will they get experienced? Will we even need experienced developers? It might be in a few years nobody builds software; you'll just ask your phone to do something and it'll build an app for it on the fly if it doesn't exist. Or, the costs of LLM based tools will go through the roof, the industry will crash and burn and we'll be back to square one. Most likely neither of these things because this train is headed for parts unknown: we're off the map and here be dragons or world-carrying space turtles or paranoid androids.

So yes, it's great that it can improve my output, but it's not the be all and end all. Some simply dismiss any and all AI technologies out of hand, or think it "It's AI so it must be crap output"; often it is, often it isn't. From a business perspective right now, in the right context it can make a lot of sense. In other contexts it feels like the Segway, neat, but you could likely run faster, stay fit and stop your muscles wasting away. More than a few studies have shown already that outsourcing all your thinking to these things does not generate good results, either in your work or your capacity to solve problems. I use it to do work, but so that I can use my problem solving elsewhere simultaneously.

I don't have a takeaway here, other than to say I don't think anybody knows what's actually going on and where the software industry is headed. Though I'd be surprised if there's a single person out there who's not sick to the back teeth having AI agents and features being jammed into every single piece of software they use. Thank fuck for open source.

Matt Lacey — Mon, 01 Sep 2025 00:00:00 GMT

Turns out I've not written a thing this year, though I haven't been entirely slack. I figured an update would make sense just for my own sanity as much as anything else.

A Reminder

These are the goals I set for myself:

Finish the port of the ZX Spectrum Next game
Get a fully playable 'demo' (i.e. at least one level) of my STE platformer - a complete vertical slice
Get the engine out of the Honda, then remove from the block the stuck exhaust studs. At some point someone welded nuts to these in an attempt to get them out and still couldn't budge them. I think a drill is going to be required
Stretch Goal - Get the Honda running

Progress

And here's how they're going:

I finished it! You can download it here. I made a pretty solid push to get this done, and I finally got there. Finishing a hobby project is a rare thing for me so this was an nice achivement.
Uhhh, yeah. I got it building again. No other progress.
The engine is out! The studs are still in it. An engine mount is also still in it. Yes, I did hope to make more progress on this, but in the mean time I acquired another motorcycle that's also needed some work, and have managed to sort a few things on that, so kind of a win? More to come there I think.
See #3.

Distractions

A 1954 Ariel Red Hunter NH 350... this is what distracted me from doing more work on the Honda. Once that bike was stripped down and scattered around a few shelves I had space for the Ariel, and then that subsequently took up time instead.
Moving OS. I've been running a multiboot setup for years, with Windows 10 (then 11), Pop OS! and Haiku. I wanted to try out Arch, and I wanred to try out Hyprland, and that combination is now what I use most of the time on my personal machine. It's taken a fair bit of tinkering and needs a fair bit more, but it's enjoyable, and feels not too dissimilar to when I used to run Slackware 20+ years ago, at least in spirit.

I'll on doubt put a project page up in due course for the Ariel, because something tells me there will always be something in progress with that bike, but that's part of the fun.

Matt Lacey — Thu, 23 Jan 2025 00:00:00 GMT

I wrote a post last year detailing some goals for the year, in the hope that some structure might help me actually finish something for once. It kinda helped, I did look back it at once or twice, but success was a mixed bag, because as usual one thing led to another and one hobby project got dropped for three more.

Status check on 2024

Sort out the Atari STF that I bought and need to sell

I actually did this one! You can read the write up but basically I got it cleaned up, fixed a few bits on it and sold it on to a local guy who was keen to relive some of his childhood. Pefect.

Finish the TIC-80 platformer I started, at least to the point of making it a worthwhile 'demo' of sorts

Yeah, not so much. I don't think I've written any code for the TIC-80 this year, though I'll have to check my repos to be sure of that. I did however get my Atari STE platformer back up and running, made a bit of progress, and then got distracted. I started porting a friend's ZX Spectrum Next BASIC game to the STE instead, and thought that would be done for Christmas. All that's left to do is the help text for the front end, but it's been that way for a month. Ho hum.

If possible, get my old Honda CBR1000F back on the road
If not possible, because it's in more of a state than I already know, get rid of it

Possibility still unknown. Said Honda is in far more parts than it was at the start of the year, most of it's on a shelf.

This Year?

Here's a few goals for the year that seem doable.

Finish the port of the ZX Spectrum Next game
Get a fully playable 'demo' (i.e. at least one level) of my STE platformer - a complete vertical slice
Get the engine out of the Honda, then remove from the block the stuck exhaust studs. At some point someone welded nuts to these in an attempt to get them out and still couldn't budge them. I think a drill is going to be required
Stretch Goal - Get the Honda running

No doubt when I come to review this list next year I'll have done some very different things alotgether, but time will tell.

Matt Lacey — Tue, 10 Dec 2024 00:00:00 GMT

Let's cut to the chase. I remembered this game. I knew it existed. I knew it played something like Indiana Jones' Desktop Adventures. Could I find it? No. Does it exist? Yes. Have I found it? Very yes.

Striking Gold

Searching online for this think I came up with nothing, though I tried a few times over the years I never found myself getting any further, though one fateful day I did find a reddit thread about this exact game, while nobody else could find anything, it did it least prove to be that I hadn't dreamt the entire thing up. For a few years nothing much changed. Searches didn't help and I continued to write it off as a lost cause. Earlier today I checked the reddit thread once more and was quite amused to see someone else looking for the game but there still being no other progress.

Then I decided to search on archive.org, and up came a couple of PC World cover disks (discs I guess, being CDs) - the second is the one I've used. I'd already decided this was the most likely avenue of finding the thing, but searching archive.org in the past had proved fruitless, so I was quite heartened when a search for "tombstone" in the software archive brought these disk images up. It seems odd that I'd not found these before since these images were added in 2021, but upon inspecting the contents of the April 1996 image I found the game files and quickly downloaded the .iso.

Running IT

At first I tried running the CD-ROM menu program using Wine, but had no luck for some reason. I tried the game's installer too but with similar results. Then I remembered that I only had to hit a button to fire up my old Pentium machine - so I did that, dug the keyboard out from behind my desk and set about getting the game onto it. DOS booted fine, but for some reason network file transfers on it are running super slowly. Small files (up to around 100KB) are super quick, but beyond that it seems to stall for ages at a time. It would likely have been faster to dig out a floppy but I was feeling lazy and left it to run.

When that was finally done I eagerly fired up the installer, only to get an error message. A quick view of the bundled text file indicated how to solve that: updating VER.DLL for my Win 3.1 installation with one bundled with the game. Times have definitely changed. Once that was done the installer ran without issues, and the game started! I grabbed some screenshots, but hit a snag: the window is rather large, bigger than the view of the canvas size in Paint, and paint seems to only paste into the visible part of the buffer. Undeterred I rebooted into Win95 to see if it would run there, and sure enough that worked fine, and apparently by that time Microsoft had seen fit to fix that particular Paint bug, so here it is... Tombstone!

Next Up...

Other than playing it, the next task is to see if I can track down the author, one David Graham who sold it through a company (possibly unregistered) called D.G Soft. Mobygames has a Dave Graham, could be the same guy, we'll see, with some luck. It took me my surprise to discover it was a UK game. Then again, perhaps that's why it was (seemingly) relatively unknown?

Grab It!

I'll be donating to arhive.org off the back of finding this, but to save them a little data transfer, and save anyone who cares some time, you can download a zip of the installer directory here. I assume the Shareware usage is still good. Once I've worked out why my old DOS PC is running so slowly, I'll grab a copy of the installed directory, but all the installer appears to do is run EXPAND on each of the files, renaming them to proper file extensions on the way.

Matt Lacey — Fri, 18 Oct 2024 00:00:00 GMT

For some time I've run a Minecraft Bedrock server for my kids on an old 2013 Macbook Pro, which was running Ubuntu 18.04. Apart from occasionally updating the Minecraft server software I've barely had to touch it, but that process was still a little tedious, and then recently I hit the point where I couldn't easily update Ubuntu because that release was no longer supported. I attempted to do an upgrade but downloading the packages took so long (no idea why, it wasn't my connection) that I got bored and decided to start over. In addition I wanted to explore the idea of being able to run multiple servers on the one machine.

In the end there were a few separate steps involved in achieving my goals, but the process wasn't immediately obvious - at least getting the servers up was ok, but making them visible to the XBox client less so, as it doesn't let you add a server by entering the IP address.

Running Multiple Servers

Because the Linux binary provided by Microsoft is built for Ubunutu, I decided to stick with that distribution and downloaded the brand new 24.10. It took a little while to sort out the WiFi drivers (proprietary Broadcom ones required) but other than that it was smooth sailing. In my head Ubuntu is still a "new" distro, it boggles my mind to think that it's now 20 years old.

Once that was done I decided to have a look at using Docker to run the server. Although I've always vaguely known about what Docker does and is, I've never used it beacuse I've not had reason to, but I had a hunch that it would not only make running multiple servers easier, it would also mean I could run multiple without having them run on different ports.

Note (18/10/24) - The steps below are me writing them out retroactively. There could be something missing but hopefully it's enough to guide you through a process that took me a fair bit of trail, error and research. I will run these from scratch in a VM in the near future and ensure they're as accurate as possible.

Step 1 : Install Docker

Rather than go into detail here, I suggest visiting the official Docker website's install instructions.

Step 2 : Setup Some Servers

Karl Rees, along with a couple of others, created docker_bedrockserver, which is a docker container setup to run the bedrock_server binary that you'd usually download directly from Microsoft. In fact, his repository includes scripts to automatically update the servers on restarting the containers. That said, when I tried to get it going there were a few things that were a little out of date. I'm going to open a pull request shortly to get those changes into Karl's repo (hopefully), but for now you can clone from the fork I created - https://github.com/mattlacey/docker_bedrockserver. It's probably worth reading the README in it's entirety, but following is the part relevant to setting up multiple servers quickly.

README.md starts here

To run multiple servers using multiple Bedrock worlds, each running at a separate IP address on your LAN, the setup script can try to setup your environment for you. Be sure to install docker-compose.

Download the source code from git.

git clone https://github.com/mattlacey/docker_bedrockserver

Run the setup_multi.sh script.

cd docker_bedrockserver
./setup_multi.sh

This copies the example .env file, docker-compose.yml file, and mcdata folder to their expected locations, and populates the environment variables with some naive assumptions about your network and mcdata storage location.

If you want more than just the two example servers, edit the docker-compose.yml file to include a separate section for each server. Be sure to change the name for each server--change both the container_name property and the WORLD environment variable. Be sure to use a different IP address for each server as well.

Run docker-compose

docker-compose up -d

README.md ends here

At this point it pays to read some of the Docker documentation, but in short you now have two containers running, each hosting a server. You can check they're running using docker ps, and stop them both with docker compose down. Do that now, and then we'll look at some of the settings in docker_compose.yaml, which is the file that tells docker how to configure the containers.

Step 3 : Edit `docker_compose.yaml`

I can't really provide settings for your LAN, but chances are they're similar to what's in the compose file already. That said, one major change I had to make was changing the network driver to ipvlan instead of macvlan - for some reason my network hardware doesn't like macvlan and I couldn't see the containers on the network. The networks section of the file will look something like this:

networks:
 default:
  driver: ipvlan
  driver_opts:
   parent: ${NETWORKINTERFACE:-wlp3s0}
  ipam:
   config:
   - subnet: ${IPPREFIX:-192.168.0}.0/24

Note: wlp3s0 is the name of the WiFi connection on my Macbook when running Ubuntu, find yours using ifconfig or similar, and ensure the subnet matches your network configuration too. Most home routers configure the local network to use 192.168.0.x or 192.168.1.x.

After the generic section of the file you'll see two blocks for servers, with examples of settings for game mode and the like. Each server will need an IP address for your network, so be sure to put in a value that's legitimate and free for your LAN. Again, I can't tell you what your network configuration is, but hopefully if you're doing this you're already comfortable with tools such as ifconfig. Using the subnet above, the first server block would look something like this:

 minecraft1:
  << : *default-mcserver
  environment:
   WORLD: family
   MCPROP_SERVER-NAME: "Creative World"
   MCPROP_GAMEMODE: 1             # 0 is survival, 1 is creative, 2 is adventure
   MCPROP_ENABLE-LAN-VISIBILITY: true
  container_name: minecraft1
  networks:
   default:
    # Be sure the last three digits of IP address is unique
    ipv4_address: ${IPPREFIX:-192.168.0}.20

After editing the file, either restart or start the servers as required:

docker compose up -d
# or
docker compose restart

Step 4 : Play! (On PC at least...)

At this point, depending on the hardware you're playing on, you could well be good to go. On PC (and Android) under the servers tab in the game, there's an option to add a custom server. Adding the IP addresses you assigned in the yaml config file here should be all you need to do. If the containers are up they should be available on your network on the standard Minecraft port 19132.

Step 5 : Get That XBox/Switch On Using BedrockConnect

I spent a day or two trying to work out how I could get these shiny new servers to appear in the Friends List on the XBox my son plays on. There's no way to add a server in the server list, and unlike the server I ran directly before embarking on this adventure, the new ones didn't show in the Friends list, meaning he couldn't join. I still don't know the exact reason why they don't share in there, but I suspect it's to do with UDP packet delivery between the virtual network of the container and my physical LAN. Anyway, I eventually tripped over Putmatt's BedrockConnect which is designed to solve this exact problem. It really goes further than I need, so here I'll boil it down to the few steps needed to get a Switch/Xbox showing your new serves in the Friends list.

The Minecraft clients for these platforms get a list of servers from a special server, and essentially we can hijack this process by running our own DNS server for the console to use, redirecting it's requests to yet another Docker container that provides the console with our own list of game servers. Puggmatt provides a setup script for the DNS server in his setup instructions.

Warning!! It's never a great idea to just run random shell scripts from the internet without reading them first. I read it, felt ok with it and proceeded. I do suggest reading it first for the sake of sanity, not least because you need to run it with sudo.

Download the script (you might need to run sudo apt install wget if it's not already installed) and run it using the IP addess of the machine you're setting this all up on, i.e. the one running the Docker containers. The process will look something like this:

wget https://raw.githubusercontent.com/Pugmatt/BedrockConnect/master/scripts/install-bind.sh
chmod 755 ./install-bind.sh
sudo install-bind.sh 192.168.0.10

Now to run BedrockConnect itself I also wanted to use a container for convenience, and quickly found straussman's container repo to do just that. The README on the repo lists a few options for running it, I went for a using docker compose again for consistency, and the process was quite straight forward, requiring just the config file (as provided) and a short JSON file listing my two custom servers.

mkdir bedrock_connect
cd bedrock_connect
mkdir config

In the bedrock_connect directory, use the editor of your choice to create a file called docker-compose.yaml with the following contents:

---
services:
  bedrockconnect:
    image: strausmann/minecraft-bedrock-connect:2
    restart: always
    environment:
      - NODB=true
      - CUSTOM_SERVERS=/config/serverlist.json
      - SERVER_LIMIT=25
    ports:
      - 19132:19132/udp
    volumes:
      - bedrockconnect:/config

volumes:
  bedrockconnect:
    driver: local

The in the config directory create a file called serverlist.json where you can list the two servers you created using their IP addresses (last time I labour this point, but the IPs below are just an example - adjust as required!):

[
  {
    "name": "Local Server - Creative",
    "iconUrl": "https://i.imgur.com/nhumQVP.png",
    "address": "192.168.0.20",
    "port": 19132
  },
  {
    "name": "Local Server - Survival",
    "iconUrl": "https://i.imgur.com/nhumQVP.png",
    "address": "192.168.0.21",
    "port": 19132
  }
]

With this done, bedrock_connect can be started using the same command as before (in the right directory of course!):

docker compose up -d

The final step is to point your Switch/XBox at the DNS server created by the shell script. On the XBox the DNS settings are under the Advanced box under network settings. For the primary use the IP of your server that you provided to the script (192.168.0.10 in the example above), then set the secondary to a public one, such as 1.0.0.1. With that done, launch the game and if everything's gone to plan you should now see your two Bedrock servers showing under the Friend's tab!

Matt Lacey — Fri, 29 Mar 2024 00:00:00 GMT

If you're using an SD-Card with an Atari machine, you'll need a driver to make it work. There's ICD Pro which is old, but free, Pera Putnik's drivers which he sells quite cheap for the specific machine configuration that you request, and then there's Dr. Uwe Seimet's venerable HDDriver. This costs a fair bit more but it supports all Atari ST-line machines and just about any disk hardware. I purchased version 10 of HDDriver quite a few years ago and have been happy with it every since, but I laos purchased Pera Putnik's driver and have used that with great success too.

Making It Work

One thing that was working for me with Pera Putnik's driver and not HDDriver was being able to access the partitions on the SD Card from my PC when running GNU/Linux. Windows was fine, but under Pop_OS I could only mount one partition. Weirdly running fdisk -l /dev/sdc would list other partitions but I simply had no way of mounting them. I played around with different options when partitioning and didn't get anywhere, until finally I tried paritioning without Windows compatability enabled.

Simply turning that off, leaving byte-swapping unchecked, and specifying compatability with TOS 1.04 (I'm still playing around with the STF that I bought) did the trick. All the partitions show on the Atari, and all four mount perfectly on my PC too.

I need to see if there's some suitable way to label the partitions, but for the sake of my own sanity, on each drive mounted on the Atari (F through I) I created a folder on the root of each with the corresponding drive letter as the name. It's not perfect but it'll do me for now.

Matt Lacey — Wed, 03 Jan 2024 00:00:00 GMT

Today I discovered a blog post that I wrote years ago and had completely forgotten about, a list of 4 coding resolutions for 2013 (I was being a smart arse and wrote 100 in the title for a binary representation of 4). I don't think I ever went back to the post, but in short they were:

Learn more ARM Assembly
Contribute to Haiku
Finish a Game
Continue to Participate in the Force.com/Salesforce Community

To the best of my recollection (hey, it was 11 years ago!) I would have scored 25% on this, with #4 being the only thing I managed to do, and it's something I still do today but in a much smaller capacity. Some years later I wrote quite a lot of 68k assembly, but never really progressed on the ARM front. I didn't do much for Haiku other than comment on things and maybe get it building, and as for finishing a game that just didn't happen. Again, it did happen some years later, that game being written in 68k - two birds with one (late) stone!

2024

Discovering this blog post again, and at such an apt time of year got me thinking, what should my resolutions be for this year? I don't typically set them, but having some that are hobby specific might (but probably won't) kick me into action to some extent, so here's a short list, that I'll endeavour to report on again next year, just so I can show myself how distracted I get and how I'm a perrenial starter, not a finisher, when it comes to hobby projects.

Sort out the Atari STF that I bought and need to sell
Finish the TIC-80 platformer I started, at least to the point of making it a worthwhile 'demo' of sorts
If possible, get my old Honda CBR1000F back on the road
If not possible, because it's in more of a state than I already know, get rid of it

Matt Lacey — Thu, 07 Sep 2023 00:00:00 GMT

So yesterday I finished up hitting an assertion in brownout, one of the tools that comes with the brown versions of the GCC compiler, and I seem to recall it does some format conversion of, well, something.

brownout: brownout.cpp:418: std::map >::iterator get_section_for_va(elfsectionboundsmap_t&, uint32_t): Assertion `_va >= reference_bound->second.first' failed.
make: *** [Makefile:190: lolworld.elf] Aborted (core dumped)
make: *** Deleting file 'lolworld.elf'
rm lolworld.o

This post isn't realtime because I figured (correctly) that things might move faster if I spend less time writing prose while working. Tonight's path took a different direction. First off I explored the other examples folder, barebones-interop and that proved interesting. First I got a build running quite quickly, secondly there were no Makefiles in sight. Instead, this uses fbuild or Fastbuild, which I'd not heard of before, but am already quite impressed with. I fully intend to learn more, and possibly use it to build Dave.

Once that was installed, compiling the barebones-interop demo was simple, and so I switched my attention back to my previous issue. Full disclaimer: I'm not any further ahead on that front, but I don't necessarily need to be either. I realised I wouldn't solve this puzzle on my own so went straight to ggn to ask what the deal was, and he said it's a known complicated issue that still needs resolving, but in the meantime he'd been working at converting AGTs demos over to Fastbuild, and to that end has a repo called "Portable build system for Atari Game Tools by dml" with some pre-built toolchain binaries. This does exactly what it says on the tin, and within a minute or so of him pointing me at the repo I'd successfully built the abreed (a POC Alien Breed) demo that comes with AGT:

That just about brings things up to speed for where I am right now. Next step is to get on with actually trying to build my own code once more, and that seems like a good opportunity to learn more about Fastbuild. ggn also told me about it's neat report generation, whereby it can generate a HTML report of build times, so naturally I had to try that and you can view the output from it's build of the abreed demo if you so wish.

Matt Lacey — Wed, 06 Sep 2023 00:00:00 GMT

AGT (Atari Game Tools) is a set of tools and libraries built by DML, aka Douglas Little, and to be frank the guy's knowledge of Atari ST/STE/Falcon development is humbling. AGT makes it quite easy to get started moving sprites and backgrounds around the screen in ways that would have dropped jaws back in the day, because Douglas has done the hardwork for you. What it doesn't do is bring down game development to entry level. It's a bit of a moving goal post and can be a little confusing, but that doesn't detract from it's magnificence. Years ago I started work on a platformer using it, but having not touched it for far longer than I meant to, I really want to get it going again. Of course, AGT has changed in the meantime and now I've got some work to do to get it building once more, let alone running.

This is a sort of real-time rambling journal of my efforts in doing so.

Setting Up AGT

The first step is to clone the AGT repo from bitbucket.

Next comes building the various graphics tools AGT provides (these are used for sprite & background cutting and conversion to formats used by AGT). This is a relatively simple job if you're in a *nix environment (macOS, GNU/Linux, WSL, or MinGW all work). Some Windows binaries are provided but on other platforms you need to go through the various directories in the tools directory, and run make in each.

As a test I tried compiling one of the examples and failed almost immediately: on this OS (unlike most of my other systems) I don't yet have a 68k GCC cross compiler installed. There's a few options out there, the most well known arguably being Vincent Rivière's m68k-atari-mint cross-tools, but there's reasonably old now and I know GGN has a thing for brown ^[1] and has a repository with a shell script called bigbrownbuild that can generate GCC cross compilers for a veritable pile of GCC versions. The last time I tried to get this to work I failed, though I can't recall what computer or platform I was trying it on.

Before writing the last paragraph I couldn't remember the name of the repo, so I simply searched for "atari gcc brown" and inevitably ended up on the correct site, GGN's blog titled "Beyond Brown". From there I found the relevant link but first I totally got distracted reading about The twist and I can't say it was time mispent. No least because I tripped over the following quote in there, which seems rather apt for my current scenario:

Putting tasks off for long periods, especially for reusable code, is sure to make them look daunting or impossible as time passes.

Good point. Dave's not re-usable (yet) but putting it aside for so long has left me completely out of tune with that code, and with AGT.

bigbrownbuild.sh

Here we go.

Run the script, fail fast. Check the log file indicated by the command run (build-binutils-13.2.0/binutils_build.log)

Install makeinfo with apt-get install texinfo. Praise ye gods for teh gigabits.

Run script again

Wait. Wait more. It might be building ok?

matt@pop-os:~/Develop/Atari/bigbrownbuild-git(master)$ ./bigbrownbuild.sh
Host machine: Linux
Cleaning up build dirs from previous build
Downloading all relevant archives
Unpacking binutils, gcc, Newlib
Building gcc 13.2.0...

Configuring, building and installing binutils
Building the actual cross binutils...
Configuring, builing and installing gcc (without libs)
Building the actual cross gcc...

Nope, failed on the next step, building mintlib:

Source patching and building mintlib


****************************************
Oops, something exploded while building!
The error happened while buildgcc was executing make SHELL=/bin/bash &> mintlib_build.log

You may inspect the following logfiles for further info:
binutils_config.log, binutils_build.log, binutils_install.log
gcc_configure.log, gcc_build.log, gcc_install.log, gcc_libc_build.log, gcc_libc_install.log
mintlib_build.log, mintlib_install.log
gcc_libstdc++_configure.log
gcc_libstdc++_build.log, gcc_libstdc++_install.log
gcc_misc_build.log, gcc_install_build.log
gcc_type_traits.log, gcc_type_traits.log
binary_strip.log, binary_strip.log

Errors list a lot of log files, but the key is in the command output. We want mintlib_build.log for this one, which for me is at mintlib-bigbrownbuild-13.2.0/mintlib_build.log. The error in this case was a missing pre-requisite because I was too lazy to determine if they were installed or not after reading about them in readme.md. Such is the life of a coder: often it's all too easy to make assumptions and waste time slowly proving them incorrect. In this case it was bison, easily fixed with a sudo apt-get install bison since I'm on an Ubuntu based distro^[2]^[3].

Run the script again, get further. I'm still waiting but the last line logged to stdout is "Building and installing the rest" which is promising, though I am wondering what "the rest" entails.

A few minutes after that and I see this:

~/Develop/Atari/bigbrownbuild-git/build-gcc-13.2.0 ~/Develop/Atari/bigbrownbuild-git/build-gcc-13.2.0
~/Develop/Atari/bigbrownbuild-git/build-gcc-13.2.0
Reorganising MiNTlib folders
Building and installing brownout
Creating an archive with all the goodies
All done!

Guess we're all done then. The first thing to do now is check that the binary is there and runs, then see if there's an example program to compile with it (seem to recall reading there is as of some particular version), and then get back to configuring AGT to use it.

I'd configured the script (you literally edit some things in the script file itself, read the readme!) to build into ~/Develop/Atari/brown and sure enough there's now a few directories and files in there. bin, naturally, is where I want to look and the first smoke test is good:

matt@pop-os:~/Develop/Atari/brown/bin$ ./m68k-atariturbobrowner-elf-gcc --version
m68k-atariturbobrowner-elf-gcc (GCC) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Going back to the repo, there's a directory called barebones and that has a few sample source files along with a .bat file to build them. I'm not going to nerd snipe myself now and convert that, so let's just try compiling the cpptest.c. file, which seems like a pretty good candidate for testing C++ compilation. Assumung (yet another one) GCC norms I try an optimistic m68k-atariturbobrowner-elf-cpp ./cpptest.cpp expecting maybe an a.out or a.tos or similar. Instead I see a few screenfulls of C++ source and nothing to suggest compilation is taking place. Sure enough, running ls right after shows no new files. Guess it's time to read ~~build.bat after all.~~ the readme. Always read the readme. I figured checking the readme again before diving in would make sense, and whaddayaknow, there's a section titled 'Building the "barebones" examples'. It tells you to run make. Somehow, until now, I've completely failed to notice the Makefile sitting right there in front of me. Let's try make:

matt@pop-os:~/Develop/Atari/bigbrownbuild-git/barebones(master)$ make
m68k-atarimegabrown-elf-gcc -c -m68000 -Ofast -fomit-frame-pointer -fstrict-aliasing -fcaller-saves -flto -ffunction-sections -fdata-sections -fleading-underscore -D__ATARI__ -D__M68000__ -DELF_CONFIG_STACK=16384   -Wall -o vsnprint.o vsnprint.c
make: m68k-atarimegabrown-elf-gcc: No such file or directory
make: *** [Makefile:234: vsnprint.o] Error 127

Ah. Of course. Wrong shade of brown. Updating the Makefile to use turbo rather than mega power might do it... nope: turbo isn't just turbo brown, it's turbo brownER. Yes, I said this would be a realtime ramble, and if this makes no sense, well the executable was once m68k-atarimegabrown-elf-gcc and now it's m68k-atariturbobrowner-gcc. While fixing this I also noticed a library path that needs to be updated because ggn isn't a user on my machine ^[4]. Also brownout.exe is clearly for Windows, removing that extension should be fine because brownout was an executable built alongside the various GCC cross compilers.

brownout: brownout.cpp:418: std::map >::iterator get_section_for_va(elfsectionboundsmap_t&, uint32_t): Assertion `_va >= reference_bound->second.first' failed.
make: *** [Makefile:190: lolworld.elf] Aborted (core dumped)
make: *** Deleting file 'lolworld.elf'
rm lolworld.o

Ok. There's something quite funny about this failing on lolworld, but I'm tired, my bourbon is finished and I'm going to try and get my head around this assertion another time. Hopefully tomorrow because I seem to be on a roll.

*** TRANSMISSION ENDS ***

Part II

I'm honestly not sure if it's the word or the colour that takes his fancy. I must ask about that. ↩︎
Pop_OS! for those interested ↩︎
Side note: remember when package installs involved lots of slow downloads? These days the install often takes longer than the data transfer: Fetched 962 kB in 0s (2,874 kB/s) ↩︎
As far as I know anyway ↩︎

Matt Lacey — Fri, 25 Aug 2023 00:00:00 GMT

As per my last post, I've been busy futzing around with an old PC, and in doing so I wanted to hear it's audio output. Due to a rather restricted setup I reasoned the best way to do this would be to use the line-in on my main PC since it's pretty much always on when I use that other machine. In Windows this was very easy indeed, visit the old sound settings panel (not the new UI one), go to input devices and check the box to "listen" to that device, in other words, monitor it.

That's all well and good, but under Pop!_OS I wasn't having anywhere near as much luck.

Hello, Pipewire

I've used Linux on and off since the late 90s (with BeOS and BSDs thrown in too), and I remember when alsa was the hot new thing. Then came along pulse audio, which I've been vaguely aware of but until this year I've not used a Linux distro as a main OS for a long while. I was blisfully unaware of Pipewire, but what I read about it sounded good. Best of all it has a module for Pulse compatibility, meaning I should still be able to use things like alsamixer to mess with settings. Except, I can't.

No, I don't know why, the services are loaded etc. and running in the userland systemd environment but I have zero joy trying to run various commands like alsamixer:

matt@pop-os:~$ alsamixer
ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused

cannot open mixer: Connection refused

or pactl:

matt@pop-os:~$ pactl info
Connection failure: Connection refused
pa_context_connect() failed: Connection refused

As of yet I've been unable to find a solution to this problem, but while attemping to learn more about Pipewire I did find Arch's excellent write-up on it, and in there discovered Helvum, which is a patchbay for pipewire and while I thought about building it from source I figured it was worth a quick look in the Pop!_OS store first - sure enough there's a flatpack build in there.

Patching the Plumbing

It took all of two seconds to install Helvum, a couple more to launch it and barely any more than that to solve my problem. All I had to do was click and drag from the two (Left and Right Channel) nodes for the line-in source on motherboard and hooked them to them to the playback nodes for my graphics card as I use HDMI audio via my monitor (it's actually then connected via an analogue connection to an old amp with only one input, but it does avoid any noise on the signal from the PC by doing the first bit digitally). Job done.

There is a bit of noise on the sound from the retro PC, but I believe the source of that noise is my modern motherboard, not least because it's worse when scrolling windows. It's not terrible though and not really noticable at comfortable volume levels.

Matt Lacey — Thu, 24 Aug 2023 00:00:00 GMT

The Backstory

Some years ago I picked up on old PC from eBay for $20 with a few to check whether it worked (it was listed as not working), see if I could fix it, and hopefully shift it on. What I didn't count on at the time was an onslaught of nostalgic feelings for old PCs. Beige boxes have never been that exciting, and the evolution of PC so gradual (apart from a few notable moments^[1]) that I didn't think there was anything to miss. At the time the machine was running Windows 95 with a fair bit of cruft, and I wanted to play around with DOS once more, so I imaged the disk and set about installing DOS 6.22 and Windows 3.1.

Seven Years Later

With the machine setup again after a (long) house move, I wondered once more about the original install and what was on it. I'm not 100% sure of it's original install date, but as you can see one of the registry files was created onthe 28th of July, 1997 which is a nice round 26 years and 26 days ago. There are older file dates on there but I suspect those I could have just been carried over from the install media. For this exploring I could have used a virtual machine, which I did back when I took the original image, but that didn't seem like much fun, so I opened up the box and installed an IDE->Compact Flash adapter that has a PCI bracket allowing for easy swapping of the CF card.

I located the original image I made that's been sitting untouched on my harddrive for seven years and dd'd it to a 2GB CF card I bought years ago but had never used. I hit the power button and got pretty much what I expected, the bog standard 9x era "Invalid System Disk" message.

More searching ensued and I located a Windows 95 boot disk image - I had one on a floppy already but it was for a different version of Windows 95 (B) and didn't seem to work with the unknown install that was on the CF card. Once I'd managed to boot from the disk I used sys a: c: to make that partition bootable.

Crossed fingers, a power cycle and Windows 95 started to boot, but unfortunately hit a BSOD (0xOD at 0117:00007DBD, helpful!).

Debugging the BSOD

I rebooted and Windows automatically booted into Safe Mode, which was a good start. While in there I removed the old graphics card and sound card from the device manager. I honestly can't recall if the machine had a separate sound card before but I'd put in an AWE32 during my DOS experiments to relive my youth, and I'd also dropped in an S3 Virge graphics card along with an Orchic Righteous 3D (3dfx Voodoo) that I've owned since new. Given the hardware was totally different it wasn't that surprising Windows failed, so I restarted again and thought I might get lucky. Unfortunately, I got another BSOD.

More online search about debugging boot-up BSODs brought me to a thread from 2004 on Tom's Hardware^[2](https://forums.tomshardware.com/threads/windows-95-safe-mode.1147081/)] which had a good list of ideas to try.

The first step was removing some startup programs, but I had no joy.

The second step was removing more hardware devices, but again, no joy.

The third step was Commenting out the contents of config.sys & autoexec.bat - no joy, but this time none was expected as they were pretty innocuous.

The fourth step was to remove system.ini and win.ini, replacing the former with a copy of System.cb, with a few additions detailed in the Tom's Hardware post: MUCH JOY!

Making Windows Happy

Booting to a desktop was a great step but it was time for the next quest: find all the relevant drivers for the new^[3] hardware in the machine, first stop being to deal with the mouse which was now non-functional.

I removed the mouse via Device Manager, then launched the Add new Hardware Wizard, which found a few things:

Mouse
S3 Graphics Card
Voodoo Card (I think.. it's still listed as a PCI Multimedia Video Device)
AWE 32

Yet another reboot and the mouse started working, though the drivers seemingly installed for the S3 card didn't do anything and it still showed as not working, with lovely 16 colour desktop. I installed some drivers from the vogongs.org library and that satisfied Device Manager, but opening Display settings still popped up a dialog indicating an issue with the video card, and wouldn't allow for higher resolutions or colour depths. Looking at the Device Manager again I noticed it waas still showing a Cirrus Logic video device (onboard VGA), so opted to remove that completely. After doing so, higher resolutions worked but choosing 24-bit colour prompted a reboot. The OS started up and annoyingly re-installed the Cirrus Logic drivers and triggered another reboot, but after starting the dithered background colour of the desktop was finally gone. I don't know why an onboard chipset that's not being used has an effect like this, but hey, it works now.

The ISA network card didn't appear under the Device Manager, and it took some searching online to kick-start some old memories and finally I got it going after visiting the Network control panel and adding a new adapter in there. Amusingly, at least in 2023, after adding the adapter Windows automatically installed a couple of network protocols, but didn't install TCP/IP by default. I couldn't remember the IRQ or address range for the card, and my wild guess was incorrect, but after quickly booting back into my DOS install and firing up the packet driver there I was sorted. I put in the correct IRQ and address range, rebooted, and sure enough, running winipcfg showed it had correctly receieved an IP address from my DHCP server.

Next Step: Investigations...

That's everything to date, I'm going to poke around with it a bit now to see what's installed etc. and check that everything is functioning as expected. More to come on that later. There's plenty of crud in the root of the drive as can be seen in the screenshot above^[4], probably data files from a game or similar but time will (hopefully) tell. Somewhat disappointingly, the warez directory is empty.

Those that leap immediately to mind are the introduction of graphics accelerators and seeing the Voodoo run for the first time, the not-long-after introduction of Hardware T&L with the GeForce 256 card, and then the move to SSDs from HDDs ↩︎
Read Bill Starbuck's excellent post here ↩︎
Yes, it's all close to 30 years old, but it was new to that particular install of Windows 95 ↩︎
You may not notice this simply reading the page, but both screenshots are .bmp files because I saved the screenshots in MS Paint on the 95 box and couldn't be bothered to reformat them. Yes, I know there are plugins that can do that for me automagically. ↩︎

Matt Lacey — Fri, 30 Dec 2022 00:00:00 GMT

Somehow almost all of 2022 passed me by without a post, bit with the recent release of the Haiku R1/beta4 I figured it was about time that I finally worked out how to get it dual booting with Windows 11, rather than just settling for booting via USB whenever I wanted to use it.

Warning! I'm no expert on EFI booting. This is simply a writeup of how I got Windows 11 and Haiku R1/beta4 booting side by side. Use this information at your own risk! I'm also not using disk encryption in Windows and so don't have an issue with booting it with Secureboot disabled. I'd suggest reading this post on schdck's blog before continuing here. This will get you familiar with the process, though it's all a little easier from Haiku.

I've been following Haiku since it was called OpenBeOS, and have been running builds of it ever since the first demo version of the AppServer that rendered coloured rectangles in place of windows and GUI widgets, and in the early pre-EFI days I was perfectly comfortable setting up multiple operating systems. MBR partitioning and the BeOS R5 boot manager were my friends, and they were easy to use. For some years after that I was content with running Haiku in VMs on whatever laptop I had at the time, but then around 2015 I once again built a PC and had it running Windows 8. From that point on I wasn't comfortable trying to work out how to make it dual (or more) boot - I didn't want to screw up my Windows install. 7 years later, and upgrades via 10 and 11, that same Windows install is still going, but I really wanted to get Haiku booting properly too.

Side note: Booting from USB

I tend to use Balena Etcher to write the Haiku ISO files to USB drives, it's easy and works well on macOS and Windows. For whatever reason though, I've never had much luck with my current motherboard and booting Haiku from a USB drive unless I go into the UEFI setting sand make the USB drive the first boot device in the list. Simply selecting that device from the boot menu on start up isn't enough, Haiku is only happy when that device is right at the top.

Installing rEFInd

Step 1: Install Haiku

Once Haiku is booted from a USB drive you'll want to install it to your hard drive. Hopefully you've got some free space on a drive somewhere (you can shrink existing partitions in Windows), and all you need to do is partition it with the BeFS, initialize that, and then use that as the target forthe installer. On my machine it takes less than a minute. I've not gone into details here because it's quite easy to find this information on the Haiku website.

Step 2: Download rEFIind

Visit the official rEFInd download page and download the "binary zip file" option. Extract the ZIP file and you should see something like the following in Tracker when you open the directory you extracted the zip into.

Step 3: Install rEFInd

Installing rEFInd really just requires you to copy the correct files for your architecture from the extracted directory to your system's EFI partition. Chances are if you're on a modern PC you'll want o use the x64 files, though rEFInd also provide binaries for 32 bit systems and 64 bit ARM machines. But before we copy those files, we'll make a few other changes to the EFI partition.

Mounting the EFI partition is easy under Haiku as it doesn't do anything to stop you from shooting yourself in the foot. Doing it from Windows and elsewhere is rather more complicated. You might want to use DriveSetup to help you identify the correct partition, it'll likely be at the start of a disk, around 100MB in size, and formatted as FAT 32. Right clicking on a partition in DriveSetup and choosing "Change Parameters" will pop up a dialog showing the partition type, and you can use this to confirm that the type of the partition is "EFI system data". Obviously close that without making any changes.

Once you've identified the partition you'll want to right-click on the desktop, navigate to Mount in the menu and then click on the partition. Mount it Read/Write or you won't be able to make changes. Once you open this partition in Tracker you should see a directory called EFI, and under that (assuming you have Windows installed) one called Microsoft.

Create a directory along side the Microsoft one called HAIKU, and copy the Haiku EFI bootloader from /boot/system/data/platform_loaders/haiku_loader.efi into it. I renamed mine to BOOTX64.EFI because at some point I thought that was required. As of now I'm not so sure, but it doesn't hurt at any rate.

Go back up a level and rename the Microsoft directory to something else - I simply prefixed it with an underscore. This change is because the path to Microsoft's loader is a standard one that a lot of machines will look for before anything else.

Finally, create a third directory called BOOT - this is where you need to copy the relevant rEFInd files, and the directory will look something like this:

With the parent EFI directory looking like this:

I was following an older blog post about installing rEFInd from Windows 10, and that included making a modification to the refind.conf file - adding an entry for Windows that looked like this:
menuentry "Windows" {
    loader \EFI\_Microsoft\boot\bootmgfw.efi
    icon \EFI\BOOT\icons\os_win.png
}
I did this, but it appears this step is actually necessary with new versions of rEFInd as it searches for known bootloaders, and I when I rebooted with this in the config file I got two entries for Windows. I since removed it, and the remaining icon for Windows boots just fine.

The last thing you might want to do is edit /EFI/BOOT/refind.conf on the EFI partition and look at some of the options in there. You can change the timeout etc. for different options though I left it as-is.

Profit?

At this point you should be able to reboot your machine and find yourself looking at the rEFInd menu, with one option for Haiku and another for Windows, hopefully with you being able to boot each of them.

Matt Lacey — Thu, 17 Jun 2021 00:00:00 GMT

I rarely use Office, it's something I have to deal with time-to-time as a part of working with clients, and out of the suite Excel is the tool that gets used the most. If you've got a licence for it, it really is a solid piece of software for working with relatively small (say 1/4M) data sets. Sure I do some CSV manipulation using standard *nix tools such as sort, head, cat etc., but in some scenarios when dealing with multiple data sources the viusual nature of it can be very handy indeed.

Recently, for reasons I've entirely forgotten, I was digging around in the program's settings and tripped over an option for sounds under the Accessilbity settings, and out of curiosity, enabled it. I am so glad that I did. I didn't have any love of Macs pre OS X, but I did like the sounds they made. Opening windows, moving windows, closing windows, everything made a sound, and it added a great sense of whimsy to normally dull process of navigating a UI. The sounds in Excel do very much the same thing. Every time I open it I'm surprised by the sounds (because everything else is so deathly silent, aside from never-ending notifications of course), and every time they make me smile.

While writing this post I checked out the 'Classic' theme, but as it turns out I not only prefer the 'Modern' theme, but it more readily reminds me of those old Macs, so I'll be sticking with that.

So if you do use Excel, and you like a bit of fun in your computing, I heartily encourage you try the sounds out.

Matt Lacey — Thu, 17 Jun 2021 00:00:00 GMT

I recently finished reading Robert M. Pirsig's Zen and the Art of Motorcycle Maintenance, and it was an interesting ride to say the least. First and foremost it's a book on philosophy, which is something I wasn't accutely aware of, though I knew it was involved from various scraps of information I'd picked up over the years. Secondly it's a semi-autobiographical account of a road trip across the US on the motorcycle, and lastly it discusses briefly some aspects of motorcycle maintenance, not the specficics as such, but the process.

I ride motorcycles and that's what drove the initial appeal for me. After watching yet another incredible YouTube production from FortNine, I realised it had to be my next read. What I truly wasn't expecting was to find so much content that resonated with the developer in me. I highlighted a few passages while reading for subsequeuent review, and here are some of those that to me transced the subject at hand and demonstrate lessons that are well worth learning.

When It Just Won't Run

When discussing the process behind solving an issue with a non-running motorcycle, I could have sworn Pirsig was talkin about debugging a piece of code, and it dawned on me that debugging isn't a software problem, it's an engineering problem, and working through it looks similar in many engineering contexts:

The real purpose of scientific method is to make sure Nature hasn’t misled you into thinking you know something you don’t actually know. There’s not a mechanic or scientist or technician alive who hasn’t suffered from that one so much that he’s not instinctively on guard.

Pirsig, Robert M.. Zen and the Art of Motorcycle Maintenance (p. 94). HarperCollins e-books. Kindle Edition.

One of the key tenents that I aim to bear in mind when debugging an issue is this: don't assume anything. The moment you assume a line of code doesn't neven warrant considering because it's "simple", is the moment you condemn yourself to hours of cursing only to come back to that line at the top of the function later, and want to slap your previous self silly. Check that first if statement in the function, don't dismiss it. Start at the start, even when you think you know the start is correct. If you don't, you'll find more than a few times that when you finally work your way back there after exhausting all the 'obvious' options that you could have saved youself considerable time and torment.

Clever Code is Not Clever

Labouring a point here, everybody knows you should write clear code, not clever code. You know this, I know this, but I still can't help myself sometimes. Clever code can be fun, because it offers similar feelings of achievement as to when you were first learning to code, but keep it to hobby projects where it doesn't matter (and no, that's not all hobby projects).

Any effort that has self-glorification as its final endpoint is bound to end in disaster.

Pirsig, Robert M.. Zen and the Art of Motorcycle Maintenance (p. 189). HarperCollins e-books. Kindle Edition.

'Nuff said.

Plan Head. Think it Through

If you read an older book on writing programs (think from the 80s or earlier), they all start with writing out your code on paper, in pseudocode, and then taking it from there. Sure, they're often talking about ten liners and the like, and editors are better now, but that does't mean you should write code without thinking through your options first.

Your mind was already thinking ahead to what you would do when the cover plate was off, and so it takes a little time to realize that this irritating minor annoyance of a torn screw slot isn’t just irritating and minor. You’re stuck. Stopped. Terminated. It’s absolutely stopped you from fixing the motorcycle. This isn’t a rare scene in science or technology. This is the commonest scene of all. Just plain stuck. In traditional maintenance this is the worst of all moments, so bad that you have avoided even thinking about it before you come to it.

Pirsig, Robert M.. Zen and the Art of Motorcycle Maintenance (p. 251). HarperCollins e-books. Kindle Edition.

There's no little screw to round out in code, but how often have you found out that the part you assumed would be fast and easy turned out to be anything but? Sometimes the 'easy' part turns out to be the all-but-impossible part, and a little planning ahead really can help avoid those scenarios. Personally I find the best way to avoid those kinds of scenarios is to run my ideas by someone else before I start smashing the keys.

It’s this understanding of Quality as revealed by stuckness which so often makes self-taught mechanics so superior to institute-trained men who have learned how to handle everything except a new situation. Normally screws are so cheap and small and simple you think of them as unimportant. But now, as your Quality awareness becomes stronger, you realize that this one, individual, particular screw is neither cheap nor small nor unimportant. Right now this screw is worth exactly the selling price of the whole motorcycle, because the motorcycle is actually valueless until you get the screw out.

Pirsig, Robert M.. Zen and the Art of Motorcycle Maintenance (p. 257). HarperCollins e-books. Kindle Edition.

Leave Things Better Than They Were

In my last book report-of-sorts, where I wrote about my thoughts on Jon Ousterhout's "A Philosophy of Software Design" I included a quote about leaving code better than you found it. It's one of the core concepts of that book (as well as the idea of shallow interfaces and deep implementations) that's stuck in my head ever since. Sure, here, Pirsig isn't really saying the same thing, but it's a not-dissimilar lesson that we'd all do well to heed.

The place to improve the world is first in one’s own heart and head and hands, and then work outward from there. Other people can talk about how to expand the destiny of mankind. I just want to talk about how to fix a motorcycle. I think that what I have to say has more lasting value.

Pirsig, Robert M.. Zen and the Art of Motorcycle Maintenance (p. 267). HarperCollins e-books. Kindle Edition.

Personally I've got a lot more to learn about motorcycle maintenance, but working on my bikes does make for a nice change from the the keyboard and screen which dominate all too many of my evenings. Doing so creates the same joys and pains too. Zen and the Art of Motorcycle Maintenance isn't a light read by any standard, but it's one I'll be reading again in the future, because I'm prety sure the first pass only just scratched the surface of understanding.

Matt Lacey — Wed, 14 Apr 2021 00:00:00 GMT

Recently I undertook a bit of a road trip, the kind that involves the better part of thousand kilometers. The kind that also includes three young children (read: five and under) in the back of the car. Clearly, entertainment was going to be needed. Our car actually has an after-party roof-mounted DVD player, which is great, but we only have a couple of DVDs that are in the correct region for it, and as a result I'm far better accquainted with both Aladdin and The Lion King than I'd really like to be. Naturally I set about finding a way to get other content onto that screen; It has composite input, which is a good start, but I didn't want to buy anything new, and seemed to find a lot of mixed reports around the various cables and adapter combinations on offer (typically Phone -> HDMI -> Composite). No problem, I thought, I've got a spare Raspberry Pi knockout about, surely I can do something with that? I could, but in 2021 it took quite a while to work out what the correct setup was, so I'm listing it here in the hope that it'll save somebody else a lot of time digging through older resources.

Step 1: Install scrcpy

scrcpy is a program that connects to your Android phone via adb, and streams the display to a window, allowing you to interact and control the phone with your keyboard and mouse. I found various options for dealing with this, but in short it boiled down to these easy steps when running the latest version of the Raspberry Pi OS.

First, install the Snap Store and ADB:

sudo apt update
sudo apt install snapd
sudo apt install adb

Reboot:

sudo reboot

And finally, install scrcpy:

sudo snap install --beta scrcpy

Step 1.5: Test scrcpy

Plug in your Android phone via a USB cable, start the adb server, and run scrcpy:

adb start-server
scrcpy

You'll likely see a confirmation message on your phone asking for permission to enable USB debugging. Accept it, you may find you need to run scrcpy again after doing so. When it works, you should see a bunch of messages fly by too fast to read, before a window pops up showing your screen.

Step 2: Enabling Hardware Acceleration

At this point my setup worked, but it was smashing the CPU of the little Pi and showing both a poor frame rate and a lot of lag. I'm using a Raspberry Pi 3B, and found a few different posts and the like for turning on hardware acceleration, but after a fair while trying out different options the solution turned out to be very simple (at least running scrcpy version 1.17). Run the Raspberry Pi configuration tool:

sudo raspi-config

Navigate to Advanced Options -> GL Driver and enable GL (Fake KMS). That's it. Run scrcpy again and you should see it responding much faster, and at a much higher framerate.

Step 3: Workout Your Command Line Options

scrcpy has a few different command line options you can specify, for my particular setup I wanted the video full-screen, horizontal, and didn't need a crazy resolution, so I simply used this:

scrcpy --rotation 0 -m 800 -f

where:

-f enables full screen mode
--rotation 0 specifies a horizontal rotation mode
-m 800 indicates the maximum dimension of the video feed should be 800 pixels

Step 4: Profit?

To make life easier in the car I configured the Raspberry PI desktop to start a terminal once X starts, which I did by editing /etc/xdg/lxsession/LXDE-pi/autostart and adding @lxterminal to it.

To facilitate start up (and restarting - I found that scrcpy would crash on occasion as well, seemingly related to some kind of rendering context changes on the phone when moving between apps and the launcher), I added a quick and dirty shell script called start to the system with the following content:

adb kill-server
adb start-server
scrcpy -m 720 --rotation 0 -f

Step 5: Save Your Filesystem From Corruption

Outside of a car you probably wouldn't need this, but I didn't want my SD card to get corrupted through the Pi being powered down suddenly without a proper shutdown procedure. There's a tonne of guides around on making the file system readonly, and I followed a few, again to find that most were out of date. The easiest option as of the time of writing is to again launch the Pi configuration tool (sudo raspi-config), navigate to 'Performance Options' -> 'Overlay File System' and turn it on. Job done!

Results

This setup worked wonders for our trip, it did crash once or twice but not nearly as much as when I was testing, I guess because the phone was simply running Netflix most of the time and wasn't moving between apps. I mention Netflix in particular because that worked well, some other streaming apps wouldn't work at all, menus etc. would be fine but the moment content started scrcpy would bail. It seemed to be related to the codecs used for the streams but with Netflix working well I didn't feel the need to spend more than ten fruitless minutes trying to work that out.

Matt Lacey — Thu, 11 Mar 2021 00:00:00 GMT

Dark themes are all the rage, and have been for a few years now. On the one hand they can be great, on the other they sometimes still suffer from the same problems I encountered when trying to tweak my *nix desktops to be dark fifteen years ago - elements sometimes get missed, and either stand out horrifically, or simply get lost. Just today I logged into the Office 365 admin tools for our business, to have one of those "what's new" tours appear where you see a bunch of tool-tip style popups, one after the other, show you around new elements on the screen - what was conspicuous in it's absence was the 'Next' button on the first one. Of course, when I hovered my mouse where I expected a button to be it suddenly appeared in bright, unmissible orange, and when I moved it away I realised it was there all along, it was just very dark grey on a black background. It wasn't Disaster Area's sun-diving stuntship bad, but it was pretty bad.

Where Are The Comments?

As you may have surmised from the title, this post isn't just about dark themes, it's about comments. Specifically it's about how comments appear in dark themes in IDEs. Checkout these screenshots taken from my IDE with some of the most popular (based on blogs, ratings etc.), and look at the comments. The problem in my opinion (yes this is an opinion piece, and yes, you may disagree) is pretty clear: comments in dark themes are often configured to use colours that do not contrast well with the background. To my mind, this makes absolutely no sense, and it's infuriating.

Dracula Official

A pretty standard take on comments in dark themes.

Cobalt2

This is the best of the bunch here, blue on blue isn't ideal but at least there's a reasonable difference in brightness.

Night Owl

I like the colours in this theme, but the comments need to be brighter.

Atom One Dark

Given it's popularity, it surprises me how much these comments just blend into the background. If you squint your eyes they pretty much vanish.

Monokai Dark

Not much better than Atom, used to be my default until I switched because of the comments.

It's as if comments are regarded as messy, unsightly, or that they're somehow less important than the code around them. Sure, comments such as // set name to null or // loop over the array are essentially worthless, but good comments are worth their weight in bitcoin. Good comments are arguably more important than the code around them, because although reading the code tells you what it does, only comments can tell you why it does it, and there's many occasions where the why isn't immediately apparent. Comments alone can tell you why some ass-backward crazy looking code is written as it is - oftentimes there is a good reason for weirdness.

Codey's In Bed By 10pm

Respect your comments. Put effort into writing them, and let them stand out by using a theme that appreciates the power of comments. A good example of such a theme has been cooked up by a good friend of mine, Kevin Poorman, called "Codey's In Bed By 10pm" and I thoroughly recommend checking it out. On the surface it might appear that the comments and background are on par with Cobalt2, but the difference is the contrast for the code and the comments appears to be very similar, they're treated as equals, as all code and all people should be.

Matt Lacey — Tue, 20 Oct 2020 00:00:00 GMT

It's pretty common during interviews for software development roles for the interviewee to be asked about any side projects or hobby code, and rightfully so this is often seen as unfair. Coding in your spare time should not be a requirement, many people don't have the time for it, others may just want to spend their spare time doing something else, and they shouldn't be punished for that. Ever. Some developers have a seemingly endless list of hobby projects, that churns and changes constantly with little ever being completed. I've always been one of those developers but it only recenlty dawned on me why.

I code professionally for about 30 hours of the week on average. Other aspects of my job take up the rest of the time and some weeks are far, far longer than others. So why do I code for fun, on the same machine in my limited downtime? Because suddenly I don't have to give a shit.

In my professional code I strive to be better. I read articles, books, and always aim to improve the code base. The code is defensive, it tries hard to be user friendly, and all of that consumes a lot of time and mental effort. When it comes to hobby code I can choose the language, the platform, the code style, the project. It's all under my control, and the end product is typically for me, which means I can just write the bits I want to write and throw the rest out of the window. Check an array index before using it? Nah. I'll assume it's right, and when it's inevitably not, I'll debug and work out why. If bad input blows things up, so be it - I'm the one giving it input so I should just get my input right. Clearly this is not an approach for any end user audience beyond myself.

Arguably you should always strive to write your best, most robust code, and often that takes defensiveness. But for older computers and lower level languages it's correct and fast code that count. Yes I probably should always try and stick with best practices and focusing on improving my architecture skills, but when I'm coding for fun it's because I want to have fun: the way to do that is to write the bits I want to write and not let the rest bog me down. If I spent all of my coding time (work and otherwise) trying to do it 'right' I probably wouldn't code as a hobby, because the fun would have been sucked out of it.

Don't ever rank a job applicant lower than another because they don't code in their spare time. Maybe they don't have spare time, maybe they just don't want to spend their time that way. I used to (incorrectly) think it was an important thing to watch out for, but many of the best developers I know don't code in their spare time and some of them then wonder why I do.

For me it's pretty much a way to blow off steam. I can have a whisky and crash an Atari over and over while I work on a project that'll likely be of benefit to nobody but me, and even for me it's not the end product that'll provide any benefit: it's the process.

Matt Lacey — Thu, 01 Oct 2020 00:00:00 GMT

On a niche podcast I host with a friend of mine, I mentioned how Chip's Challenge was released on Steam for free, and that somehow the size of this game was somewhere around 100MB. This may not sound big for a game, and today it really isn't with new AAA titles coming in closer to 100GB, but the thing is, Chip's Challenge is an old game. In fact archive.org has a copy of the Windows 3.1 version, and it weighs in at 198KB zipped, 488KB extracted. I can't run it under Windows 10, but I suspect it'll work fine if I copy it over to the Pentium machine on my other desk.

On the podcast we don't focus on games, but I'd brought it up as another lamentable example of how the progression of technology often seems to involve crazy changes, like taking a small game and somehow making it huge. But I didn't think much more of it, until a friend of mine sent me a Tweet and suggested that it might be using an emulator or VM:

"Of course" I thought. I've got a bunch of Steam games that come packaged up via DOSBox, so it'd make perfect sense. I decided to actually install the game and it's interesting to note that despite the game being a couple of orders magnitude larger than it was originally, I could pull it from the other side of the world in less time than it'd take to copy the original 500KB game off of a floppy. Then I dug in to see what emulator or similar it was using.

There's a few things to take note of here:

There's a Steam specific .dll, which isn't surprising - but it does indicate that the game has been recompiled
The size of the executable is now around 4x the size of the original game
There's no sign of an emulator, which would make sense given the recompilation

So the extra size must be in the data directory, which again seems odd because the core data files shouldn't have changed, and the graphics and sound should be as they ever were. So I dug deeper, checking folder sizes to see where the disk space has gone, and it didn't take long to discover the cause.

The music is all in MP3 format, weighing in at 83MB. Again, this may not seem extreme if you're not someone who was playing PC games in the early 90s, but if you were, you'd know it wouldn't have shipped with MP3 music. The original game used MIDI files, and these MP3 recordings are not new versions of the music, they're actually recordings of the MIDI files being played back. The Steam version includes many more tracks than the original Windows 3.1 archive I found, but two of the tracks are the same in each. In the old version we have 2 MIDI files taking up 21,595 bytes, and the two corresponding MP3 files consume 1,462,803 bytes. They're relatively small compared to the others included as they're quite short tracks, but here's the real kicker:

MP3 is lossy, which means the modern version of the game uses over 67x the disk space, more RAM and CPU cycles at run time, for inferior music. Progress!

Matt Lacey — Thu, 30 Apr 2020 00:00:00 GMT

I tend to go through phases of reading books related to development, often reading a few back to back and then taking a break for a few years at a time. This isn't intentional but seems to be a natural cycle for me. Recently I've been reading them again, and the most recent book I read was John Ousterhout's A Philosophy of Software Design, and I wanted to make a few comments about it and to recommend it to others, because I think it's a worthy read for all developers.

I must admit, that I didn't actually look up John Ousterhout prior to reading the book (and now I feel it's criminal that I didn't already know his name): I simply picked up due to a recommendation from a friend of mine, and this meant I had a rather pleasant surprise about halfway through when Ousterhout mentions that he created TCL. As somebody who spent close to two years developing in TCL professionally (though I must say I've never used it outside of that role) I had to do a bit of a double take, and immediately go look him up. TCL is a dynamically typed language that can be used in a range of domains: the company I worked for used it extensively because of how well it could be interfaced with C. They used C for the core of their web application framework and then TCL was used to drive the interface and higher level business logic. The point though, is that Ousterhout has seen his fair share of development, system design and architecture, and it's clear he's picked up some excellent ways of working along the way.

Upon finishing the book I reached out to my friend to get his final thoughts on it, and while he liked it he felt that "Philosophy" was a bit of a strong word to use in the title. I do a agree to some extent, but I do think the word fits because it's definitely given me an alternative way at looking at the code I write. The book is not a detailed guide to architecture patterns, or hard and fast rules about how to put software together, but it does present a few generic guide lines and methodologys with which to approach software development.

Software Complexity Causes Headaches

The book opens with a discussion on what complexity means in software, and highlights that while complexity can not be eliminated from a large scale software solution, it can be handled, and sometimes that handling takes a little up-front investment. I wasn't entirely engrossed in this discussion, but that's not to say that I didn't get anything out of it, I just wanted to get to the meat of the book. That's where I was perhaps a little let down, because there is no grand overall idea presented, but instead a series of small ideas that work together. Of course, you've probably realised from that sentence alone what the deal is: the small ideas come together to make a grand whole, and I worked that out after the fact. There is no big summary or conclusion, it's simply presented as ideas and guidelines and left to you to deal with.

Simple Rules Can Go A Long Way

Anyone who's familiar with the concept of emergent behaviour knows that simple rules can build powerful systems, and that's how I believe Ousterhout's guidelines work. The ideas are not complicated or difficult to reason about, and they are easy to leverage both when considering your application architecture as a whole and on the fly as you write your methods and classes. I find it quite fascinating how he's managed to distill a few simple rules that impact your behaviour to the point of having a considerable impact, and the best part of them being simple is that you won't find yourself having to go back to the book to remind yourself about how some pattern works, or how something should be structured: this is more fundamental stuff and I believe that's how it can be considered a philosophy.

Whenever you modify any code, try to find a way to improve the system design at least a little bit in the process. If you're not making the design better, you are probably making it worse

John Ousterhout, A Philosophy of Software Design

Go Deep

I don't want to go ahead and bastardize the content of the book here, because I simply wouldn't do it justice. But one concept that's easily explained (and gives a good taster) is Ousterhout's classification for Shallow vs. Deep, which applies from high level structures such as modules, through classes and down to individual methods. The core idea is that complexity should be hidden away, meaning interfaces for code should be simple, and the code itself complex. If the interface is complex it'll necessarily become harder to use, and often more difficult to maintain. Sure, moving the complexity out of the public interface doesn't remove it, but it removes it from consideration by users for the module/class/method. Methods themselves may become more complicated internally, but I think it's fair to say that in most large systems, features and updates rarely involve rewriting existing code, more often than not they're about expanding interfaces or bolting in new modules, and utilising what's already in place. If the interfaces to the exsting code are simple and obvious then they should be easy to work with and re-use. This is what constitutes the definition of "Deep": Simple Interface - (more) Complex Implementation. In contrast, shallow classes and methods are those with detailed interfaces, resulting in relatively simple code because the complexity is often being deal with by the caller, which as you can imagine puts the burden of complexity on said caller and results in all code using the module assuming the complexity instead, which significant effect on a lot more of the code base.

Give It a Read

These ideas may not be for you, you may even fundamentally disagree with them if you're of the persuasion that no method should ever be longer than 10 lines of code, but for me the book really works, and that's why I think all developers should read it. Even if you do disagree in some of the core concepts there's bound to be something of benefit in the book for you.

Matt Lacey — Thu, 23 Apr 2020 00:00:00 GMT

This is a blog related to programming, and such articles will be forthcoming, but I feel it's important to set the tone before going any further, and I genuinely struggle to work without music. When I started on this post it was supposed to include a variety of music, but I quickly realised it was taking on a very D&B slant, because once I'd included one track I wanted to include others that I enjoy from the genre. At that point I decided this will be a D&B installment in a series, because I listen to a pretty wide variety of music day to day. It would appear that the Hospital Records label in particular has had a large impact on my listening of late.

Disclaimer: everyone has different tastes and what works for me may well be so far removed from what you like that you'll wish I'd never made this list, but I'm writing it anway, because I wanted to highlight some music I've tripped over a few years after the fact, and have absolutely grown to love. Some people prefer to work in silence, and if that's the case you can probably stop reading.... now.

I'm was planning to embed some music from Spotify, again, people have different opinions and different sources for their music, but Spotify has been mine since I got sick of managing an MP3 collection. I don't know the exact date, but it's been over 10 years. Unfortunately, there doesn't appear to be a way to specify a sensible volume level for their embedded player, and if often starts mid-track, with a heavy beat, way too loud, so YouTube it is. For each artist, I'm going to list/embed one of my favourite tracks, but more often than not you can bet I love the whole album/EP they came on.

B-Complex :: Early Bird

I don't remember how or whan I came across B-Complex, and her body of work isn't huge, but I'll take quality over quantity any day. A piano melody over the top of a track that just keeps rolling. I can't get enough of this track, but don't just check out the EP, because all of her work is so damned good".

Keeno :: Nocturne

More piano, maybe there's a theme? I often leave Spotify playing on radio mode because I find it's a great way to discover music, and this track had me hooked within the first 30 seconds. I listened to it, listened again, and then listened to the album it's apart of: Life Cycle. It's perfect for some late night hacking.

Netsky w. Emeli Sandé :: Thunder

I discovered Netsky during a hackathon back in 2013, but haven't stopped listening to his music since. I'd be lying if I said I loved every track on the album (III) that this track heads up, but I'm never even close to skipping one.

Sub Focus :: Out The Blue ft. Alice Gold

From the album Torus, this is perhaps a bit more upbeat than some of the other tracks listed. Again, I love this album, but I'm Including this track in particular because I've had the lyrics in my head all morning.

High Contrast :: The Agony And The Ecstasy feat Selah Corbin

More from Hospital Records: lyrical, fast, uplifting and even includes some organ for good measure with a synth riffing that could have been lifted straight from a Sega Megadrive game. High Contrast's work is quite varied within the genre, and another of HC's tracks that never fails to get me chair-dancing is Kiss Kiss Bang Bang.

Pendulum :: Watercolour

Probably far better known than most of the other artists I've listed, but Pendulum have been one of my most listened to artists for the last decade, and I listened to them a lot before that ever since they first hit the world stage with Slam. From the album, Immersion, I'd probably pick The Island -, Pt. I over this track, but couldn't find an official video for it on their channel, and this is a close enough second that it's practically equal. Immersion can't get enough air time IHMO.

I hope this has introduced you to some new music, or at least re-kindled interest in tracks/artists you may have forgotten along the way. The next installment will likely involve a lot more guitars. I'd love to hear your thoughts.

Edit :: Spotify Playlist

After writing this post and sharing it on Twitter, a friend of mine asked whether it was available as a Spotify playlist, so I quickly threw together a list with these tracks and a couple of others, it'll keep growing but if you use Spotify and like the music you've heard here, you might want to subscribe to it.

Matt Lacey — Mon, 20 Apr 2020 00:00:00 GMT

For many years now I've blogged on and off at laceysnr.com, primarily around the Salesforce development ecosystem, but ocassionally on other more general programming topics too. I may move some of those posts here at some point, but probably not. I want this site to be a place where I can write about more generic programming interests, as well as make a home for my projects. For the latter it's less about showing them off, and more about making me feel more accountable for them so that I might actually get more done.

The speed of websites and the internet in general has been something that's annoyed me for some time now, in fact, the general wastage involved in modern computing in general annoys me. We have crazy powerful machines these days, that are constantly pushing extreme amounts of data (think about updating a 4k monitor, 60 times a second, just to read some text), but we take them for granted. Abstractions built on abstractions built on abstractions mean that so much code is further from the metal than it's ever been, and that's a shame. It's a fact that many text editors on my desktop PC are slower to respond to the keyboard than my 1982 Atari 800XL, or my mid-90's DOS machine. Yes, those machines aren't doing anything else and my PC is doing all sorts, but the most important thing a computer does is react to the user, and when it feels like there's a barrier in the way of that interaction, it's not a good thing. Lots of people have written on this topic, talking about how their machines that are only a few years old can barely scroll a web page, and quite rightly in response they've created very lightweight websites. I think that's a good thing, and I want to do that, but I also want to leverage modern technologies as well.

The upshot? Well I'm going for simple content, and generating everything through Eleventy because I want to write quickly in markdown and have the computer do the boring repetitive stuff for me (which is what they're built for). I scouted around for a few days, and while I believe the Eleventy docs could be improved a little for those getting to grasps with it, it definitely felt like the right fit after trying out most of the big names in static site generation.

I'm not going completely spartan though - I've embraced/absued CSS to generate the background that's currently on the site. Will this stay? I honestly don't know right now, I'll see how it performs. But a hunch tells me this is the kind of thing handled once by the browser on page load and then I'm hoping dealt with in a smart way, but assumptions are not great things to make. Have I got any JavaScript running right now? No, but that's not to say I never will, but if I do add it I want to make it work nicely on old machines too, so already I need to find a way to deal with the CSS I've written. Perhaps a dedicated sub-domain will be the key: retro.mattlacey.com or something along those lines.

If you've read this for some reason, then I thank you, and hopefully there'll be more interesting content to read soon.