It's easy to forget just how much modern devices depend on software. OK, so it's pretty obvious that your computer and phone are just paperweights without the magic ingredient of a programmer's inspiration. But you need extend your thinking to include stuff like your television, microwave, digital watch, and even your fridge.
It seems strange until you really stop and think about it. My first computer, an Oric Atmos, had both UHF (TV) and RGB sockets on the back. I started off using an old color TV, but the image was pretty ropey so I took a trip to a backstreet electronics dealer in Leeds (who's shop actually was under an arch of a railway viaduct) and purchased an ex-military barebones RGB monitor. With a home-made case and bodged-up cable it was wonderful - a rock steady display with real colors instead of the vaguely fuzzy and flickering picture on a TV.
But where I'm going with this is that the "user interface" for the monitor was a set of small potentiometers soldered to the circuit board, which you twiddled using a tiny screwdriver. Your mechanical actions directly controlled the amount of volts flowing in the wires. A distinctly analogue display menu system. Now, when you turn on a flat screen monitor, you get a boot-up screen containing the maker's logo and you can use a fancy software-powered multi-level menu to digitally adjust what finally gets tossed onto the display.
Of course, it's the same with almost every other modern device. The digital display and input buttons on your oven, your washing machine, and your kitchen timer are connected to embedded chips running a simple operating system. And, of course, it's the same with things like your wireless router and network switches. In fact, it's wireless router software that actually prompted this week's random ramble of a post.
Some weeks back I complained about my unbalanced network routing problem. I had a response from a "random dude" (yes, that's his or her real name) asking why I didn't try installing DD-WRT on the router. There was no mention of whether it would solve the problem by turning my 2 Mbit ADSL connection into a 20 MBit one to match the speed of the cable connection, so I'll assume that the reason was it would give me better control of how the actual load-balanced routing was managed.
So I went to look at what DD-WRT is. Turns out that, for those not familiar, it's a Linux based alternative OpenSource firmware for a range of routers, including my Linksys RV042 load-balancing router. My first though was "who would be mad enough to install anything except the manufacturer's own software?" But then I remembered who I work for. I buy Dell computers and then install someone else's software (i.e. Windows) on them all the time. In fact, I install software from lots of manufacturers on computers that were made by other people. OK, so my Dell computer does already have some software on it in the shape of the BIOS, but even that's not written by Dell - it comes from Award or Phoenix.
So should I install DD-WRT? From the screenshots, it looks a lot nicer than the built-in stuff and the range of features it supports is astounding. Mind you, there are a dozen or more pages in the built-in software that I've never looked at, or couldn't understand when I did look at them, so I'm not convinced that new software will help. Unless it comes with a very comprehensive user guide and a support phone number. It's also somewhere between the "Yes I'm happy to install a new operating system on my PC (as long as it's Windows)..." and "Will my microwave still know how to warm my coffee if I install Linux?" options in terms of what seems reasonable usage of a weekend.
But why not? The worst I can do is brick it. And then it will make a rather attractive paperweight, especially if the lights on the front still flash. Except that, when I went to the DD-WRT installation instructions I discovered that I don't actually understand any of what it says. The site itself is amazing; there's hundreds of pages of articles, documentation, help, and more. And it's evident that there are lots of people whose life's work consists of playing with code inside wireless routers.
I did go off and read what a "30/30/30" is (a full reset that requires three operations of 30 seconds each), what the "peacock thread" is (several hundred lines of text that describe what can go wrong and how to fix it), and how I'll need a "jungo-image.py" (a script to install it). And if it goes wrong I'll need a "JTAG" rather than shorting pins. Though if you are familiar with hardware and firmware, I guess all this will just be second nature.
But then there's the Linux stuff. I know nothing about Linux, so much of the technical description of the installation steps simply improved the parting in my hair (or it would have done if there was any left) by whooshing over the top of my head. And even what is probably simple and obvious terminology left me standing. Do I really want to "access the following site on the webif" and "enable the busybox shell?" Maybe I'll just drop into Amazon and buy a better router. One that also has "swp half thumb fastmult edsp" would be good. Probably.
But I guess we should be thankful there are dedicated teams of people that revel in this kind of stuff, and that hopefully their efforts improve the firmware in the products we buy. Though it's a bit like suddenly coming across some strange pastime that you never realized existed. Like Mountain Bike Bog Snorkelling.
Ooooh get you with your showy Oric Atmos. I had to make do with a second-hand Oric 1. Happy days.
Hi Mark. I started off with the Oric 1 but the pushbutton keyboard was awful and some keys stopped working after a while. Besides, the Atmos was much nicer to look at as well as to use - yes I was a bit of a home computing snob I suppose. But I sold enough programs (an assembler, debugger, word processor, and other stuff) through a retailer in Preston to pay for it several times over! That was the start of Stonebroom Software. Before I got a real job.
Just in case you are interested in what it was like in "the good old days" of programming computers, I dug out this from an old blog post (daveandal.azurewebsites.net/.../default.htm):
"When I started programming you had to start every program by writing or importing the code to take a character and print it onto the screen in the appropriate position (you could choose any one of the 26 lines and 40 characters width). And, if you were really keen, you could do it in "graphics mode" so you could actually have custom characters. Italic or bold, for instance. And then, to maximize the performance of your sparkly new application, you went through the code changing all the variable names to single characters, and all the subroutines to inline code. In fact, I made a chart generation program run over three times faster just by applying this optimization technique.
Of course, if you wanted an application to run at slightly more than glacial speed, you wrote it in machine code. That way, users wouldn't actually see the screen being redrawn each time you needed to prompt for input. So most of the developers of my generation became experts at loading and storing accumulators, comparing registers, and branching if not equal. I can remember reading articles in the magazines of the day that showed how you could reduce code that took up 500 bytes of memory (note: that's bytes, not KB) by 20% by pushing and popping the stack. I even wrote a 6502 assembler program in Oric Basic and then used it to write an assembler in machine code. Then used the new machine code version of the assembler to create other utilities, and even a fairly-fully-function WYSIWIG word processor.
I mean, I remember when we discovered that the Oric Atmos (our favorite development tool at the time) had 16 bytes at the top of memory above the O/S that wasn't cleared when you reset the system. That meant you could do all kinds of devious things like cracking the best new games of the day to find the cheat codes, and making your own copies on those new-fangled floppy disk things, just by writing a short routine that disabled the auto-run feature. As long as you could fit it into 16 bytes, the world was your coding oyster. All you needed was a regular supply of coffee and toast (we didn't have a local pizza shop), and some reasonably believable excuse for not managing to get into work the next day."