Version 1 - Microsoft Basic, RML 380Z, 16k 2MHz Z80, 5.25" floppy disks
The very first version of the canal route planner was written in 1981 by Steve Atty for his 'O' Level Computer Studies project. Every place on the route had to be entered using a numerical code (the data consisted of around 100 places - mainly junctions - and only the main routes through Birmingham were possible) and a total distance and locks figure was produced.
Version 2 - Sinclair Basic, ZX81, 16k 3.5MHz Z80A, audio tape storage
For the next version, in around 1982, Nick Atty ported this to a Sinclair ZX81 with 16k ram pack. This had a much easier to use entry routine: there was a helpful way to get the starting place (on typing a letter it listed all places starting with that letter, then a second letter reduced the list further etc), and then a list of where you could go from there was produced, and a place could be selected by a single key. For speed this used a machine code search routine embedded in a REM statement (you did things like that then!). This version also estimated the total time for the journey using a 3 miles-per-hour, 10 mins-per-lock rule.
Version 3 - Sinclair Basic, Spectrum, 48k, 3.5MHz Z80A, audio tape, later dual 100k single sided single density 5.25" floppy disks
Nick then developed a version for the Sinclair Spectrum. The big enhancement here was maps: each place had a pair of coordinates and wire maps could be plotted showing the route in solid on a dotted diagram of the whole system.
Version 4 - Sinclair Superbasic, QL, 128k (later expanded to 784k, dual 1.4Mb 3.5" floppies).
In the mid 1980s Nick wrote the most sophisticated version yet for the Sinclair QL. This had a nice front end with separate windows for menus, results etc. It added the table of overnight stops for the first time as well as a short- cut to data entry where as well as listing the nearest places from the current place, it also listed the next junction in each direction (if that was different). An attempt to make a route generator was built in, but this was far too slow to be practical.
Version 5 - Memotech MTX80
At around the same time, Steve wrote a version for the Memotech MTX80. This was specifically created to help judge awards at the 1988 IWA National Rally in Castlefields, Manchester.
Version 6 - GFA Basic Atari ST
This version of Steve's had a very nice input routine where it displayed a map of the system and by clicking on it you could drill down to an individual place.
Version 7 - Generic C based program.
When the time came in the mid 90s to move on from the QL, Nick was starting to get a bit fed up with continually rewriting the program. He therefore started to develop the next version in C (first on the QL, then on an Atari ST) and to separate the processing engine from the display and entry routines. Faster processing also made it possible to store the data in a more human-readable form for the first time (in the past there were lists of places, and then lists of routes between places, using numeric codes for the places).
Originally, the idea was to have a set of generic processing routines and a set of OS specific I/O routines. We then realised that using a web based front end would not only solve all our porting problems for years to come, but would also allow the program to be put on a web site and made available to the world. Nick had often thought about releasing a PD version of an earlier program, but had never finished them enough. This would allow the work in progress to be shown and comments for improvements received. Early in 1999 he acquired a second-hand PC and a month or so later installed Linux to provide a suitable development environment.
Version 8 - Scripting capability
As this was developed it became clear that adding new functionality involved too much C programming and so the engines from version 7 were used to create a general-purpose scripting language for writing web applications. This is written in almost entirely ISO C (with a few, documented, extensions).
Version 9 - SQL database and ClearSilver templates
Although version 8 eventually grew the ability for people to propose new places that could be manually added by maintainers this was very clunky. Also the scripts were a mess of calculation and HTML printing. By using a true database back-end and a proper templating language we could allow live updates, more easily maintained pages and a potential to produce different pages for different media or in different languages if the need arises.