This document is based on my memories of the time. I do not keep a diary so some of the dates may be a little off, although some of them stay with me and I can date them based on other events occurring at the same time. Although this document is split into sections, and will be read linearly, the reality was that a lot of these things happened in parallel, and there will be a lot of cross referencing between different topics. It is a pity that all of this happened pre smart phone or digital cameras, as it would have been lovely to be able to show you pictures of it all.

Technically the first packet radio in the UK was in the mid-1980s following on from an article in RadCom about a simple packet system called BBC Packet, using a BBC Micro. It was a remarkable program which included a simple terminal, and allowed simple point-to-point connections and chats. For a brief time this mode was quite busy, but was ultimately a technical dead end. However a number of us found it an interesting idea, and a latent interest in packet radio was created.

I got my first TNC in late 1987, a Pac-Com TNC-220 which was a non compatible evolution of the classic TNC-2. In the UK, Packet Radio was in a grey zone since it involved passing third party traffic (even when digipeating) and that was outside the scope of the licence at the time. Despite this dubious legality it was known that the RSGB and the DTI/RA or whatever they were called that year were looking into it, and we should continue playing with packet and just don't do anything too silly until they worked out the new rules, this would take a number of years. At the time it was still possible to just about do multi-hop digipeating with reasonable success, but the packet channel was starting to get extremely busy.

At the time you could buy Proceedings of the Tucson Amateur Packet Radio Digital Communications Conference (TAPR DCC) which was held in various US cities in the Autumn and contained many interesting papers. There was plenty of hot air in them, from people who had outrageous ideas and no actual implementation skills, but you would get papers that would genuinely make you sit up and think, and sometimes talked of implementations of their ideas. One edition (1987?) included a complete set of state machines for AX.25 v2.0 using SDL diagrams. It turned out not to be complete, but I'll come back to that later.

One such contributor was Phil Karn KA9Q, who in one publication described the KISS TNC and protocol and that suitable ROM images for the TNC-2 existed. He also described his own development work of a PC program that appeared to do almost everything.

As an aside I went to the 30th TAPR conference in Tucson in 2006, and it was great fun.

Sometime around this time, the Tiny-2 was released which was a TNC-2 clone but using more modern components, for example a TCM-3105 modem instead of an AM-7910 which saved a lot of space. The original TNC-2 was a huge PCB while the Tiny-2 fitted in the hand, it has a number of advantages: you could actually buy them, and they weren't massively expensive, although by modern standards they were eye wateringly expensive, but the hobby was like that in those days.

Being the technical sort, I wanted to know how it all worked, and what could be done to move things forward. Having a TNC in KISS mode offered access to the raw underlying packet data in a way that allowed for experimentation. Even then we knew that the KISS protocol was a little too simplistic as it didn't allow access to the timing of when a packet was transmitted which affected the timers within AX.25, however it was all that we had.

In early 1988 we were becoming aware of a new packet system named NET/ROM that was appearing within audible range of my excellent RF location in Derbyshire. NET/ROM was a replacement ROM for a TNC-2 clone which offered a simple networking and transport layer (layers 3 and 4 of the ISO model) on top of connected mode AX.25. Not bad running on a TNC with a 1 MHz Z80 and 32K of RAM and ROM. You had to buy a separate NET/ROM for each band and link them via their serial ports. The callsign of the node was burned into the ROM at manufacturing time but you could change other parameters including the sysop password, the node alias, and other items. Each ROM cost around £40 in 1988 money and had to be ordered from California from Software 2000. The arrival of the Tiny-2 was fortuitous.

There was already a single port digipeater at Alport Height (IO93FB) on 2m, and it was decided that we could make use of this site on multiple bands to provide trunking links and user access. I bought a number of NET/ROMs and over a short amount of time we had nodes on 4m, 2m, 70cms, and two links on 23cms. The latter was using about one Watt and one set to the north to Emley Moor with one polarisation, and the other was to the Birmingham area with the other polarisation. It worked well considering it was all operating with 1200 bps AX.25. We didn't link to our friends in Leicester since they always appeared to be in a constant state of disarray, lovely chaps though.

Around this time the first sysop meeting was arranged. Many of us who had an interest in packet radio met at a hotel in Crick and spent the day talking about what we were doing and what we could do in the future, and how we should co-ordinate with each other. The RSGB attended in the person of Mike G3XDV who explained that they were negotiating about new guidelines with the powers that be. It was all very exciting, and NET/ROM was discussed a lot. A memory of that Sysops meeting was how exciting it all was, we were meeting for the first time, although we'd probably seen each others callsigns floating around on air. It was very bizarre to go to the toilets and have to fight through groups of people have conversations about packet radio to get to the urinal! Please don't read that last sentence the wrong way, the excitement at the meeting was palpable and very innocent.

I had known John G8BPQ for a number of years. We both had an interest in V/U/SHF and we both lived in good RF locations, we would often work on 23cms SSB. I don't think we had met at this stage however.

John and I found that we had a mutual interest in packet radio and we would work and chat about it, and we both expressed interest in this new NET/ROM node protocol.

We got a copy of the NET/ROM manual from the Leicester group in early 1988, we met them at the Trowell motorway service station and they gave us a photocopy of it. This gave us the protocol definition, and John took it away and started implementing. The first packets from the nascent BPQCode was transmitted using an IBM SDLC card and a telephone modem. He phoned me to get me to listen for it and report what I saw. I have a feeling that it didn't work first time, but I may be wrong on that.

His software was written in 8088 assembler as a Terminate and Stay Resident (TSR) program on MS-DOS, TSRs would sit in the background, would typically hook into the vertical refresh interrupt (at 18 Hz) and essentially operated invisibly to the other program on MS-DOS. Remember we didn't have multitasking as standard, Linux didn't exist yet and Windows was still a joke. Many people did not even own PC compatible computers, as they were termed then, as standard, and if they did, it may have only been an 8086 or 80286 running at 8 or 10 MHz. Also RAM was limited, 640K RAM was still expensive.

BPQCode in the very early days was in source form so you could configure (callsign, etc) and compile it. That stopped fairly quickly after some people changed the copyrights on it, which understandably annoyed John immensely. It had a fairly crude packet tracing format. It worked very well and became a big hit with people who ran BBSs. I wrote a more fully featured packet tracing code for it in either late 1988 or early 1989, while attending a course at the hotel used for filming the original series of Crossroads, I followed the TAPR format for the AX.25 level 2 part, but devised my own format for NET/ROM.

John attended Sysop 2 and subsequent ones, and was often deferred to in technical discussions by most people. I mentally marked anyone who argued with him as morons.

For a multiport BBS, you needed to be able to run multiple copies of the BBS program. The main BBS programs of the time were written by W0RLI and WA7MBL. There were others, but they gained little traction since they didn't offer all of the features of these two. The way that multiple BBS instances were able to run on MS-DOS was via DesqView. Once BPQCode became common, it was not uncommon to see multiple instances of MBL431 running. The idea that a single program could be written in such a way as to access multiple ports inherently took some time to be appreciated. This led onto development by AA4RE and F6FBB in the fullness of time.

The way that a BBS interacted with BPQCode was as if they were talking to a real TNC talking the TAPR command set. John implemented a suitable subset of this to support the BBSs. I am not sure how much interaction he had with the software authors, this was pre Internet for most of us, and often he would send and receive letters to interested parties overseas.

There was an interface that ran parallel with the TAPR commands and that was host mode. This was created by the guy behind NET/ROM, and indeed NET/ROM implemented a subset of it for commanding it over the serial port. I think we both looked at host mode and declared it as being nonsense on stilts, even over thirty years later, I still feel that way about it.

I got to know F6FBB in the late 1990s. I visited him a few times when he came to Paris for business. I was living in Brussels (and later Zurich) by then, and hopping over the border was pretty simple. We spent time talking about packet, but mostly eating good food and drinking excellent wine. I have a particularly strong memory of my legs refusing to work properly after a dinner at a Cambodian restaurant near the Gare du Nord in Paris!

Every area had its own packet group. The Birmingham area had MAXPAK and a pretty good magazine to go with it. The Leicester area had LURPAC, and we had DANPAC, the Derbyshire and Nottinghamshire Packet Radio Group, or something similar. Compared to the horrible politics that seeped into other groups, ours was almost entirely sweetness and light.

By now, the powers that be had worked out the rules of packet radio and it all became a little less like the wild west. When I ran my BBS, G4KLX, it ran with 100W into a 16 element yagi on 2m, an ERP of around 4 kW. It never ran as a GB7, even though I did eventually get GB7KLX allocated after I'd closed it down.

The group would have a meeting every few months, and had a nicely produced magazine. Richard G4NAD was one of the main movers and shakers in the group.

We became responsible for GB3RP/GB7RP (RP=Raynet Packet) and later some other nodes and GB7xxx BBS systems. RP started as a single band (2m) digipeater which was clearly inadequate for how things were developing, we added extra bands/ports and NET/ROM using authentic NET/ROMs. Luckily we had G8BPQ as one of our members, and early on we were to run a version of his code on the Kantronics Data Engine. This was a dual port TNC, with each modem on a plugin board so you could choose the modes, it had a fast 80188 CPU and a decent amount of RAM. It was a TNC on steroids. It came with a single 1200 bps AFSK modem as standard, and you could have a 9600 bps RUH modem board. The one at RP had two 1200 bps AFSK modems.

However RP needed three extra ports. We had the Tiny-2s from the NET/ROM days, and so we used G8BPQ multidrop KISS. The idea behind it was simple, hang all of the extra TNCs from one serial port on the host device, and give each TNC an Id and use that to address them explicitly. Each TNC could only talk to the host when asked to do so by the host. In addition each packet passed over the serial link was protected by a checksum. Finally it also included ACKMODE where each TNC reported back to the host when a particular packet had been transmitted, so that the AX.25 protocol timers could be set correctly.

The whole stack was pretty impressive, each TNC would have very fast blinking lights to show that they were being polled which made debugging very easy. It was a super reliable system and got updated rarely, since it required the Data Engine to be opened up, and the ROMs changed.

Although the location of RP was sensationally good, it did suffer from some pretty obvious drawbacks. The 2m packet frequency had 100% utilisation, and was almost completely useless, even the 70cms channel was pretty well full also. The 2m node did get to transmit from time-to-time, due to interference. In the same hut and mast as RP was a high power paging transmitter on 156 MHz (I think), and when it transmitted, 2m went very quiet! So RP would get its long line of packets out.

The other problem was the weather. Alport Height is a very exposed location, in the summer it can be glorious, but in the winter it used to suffer from some extremely serious snow drifts and horizonal wind and rain. Luckily most of my visits were done in pretty good weather, but I did feel for the people who maintained the equipment in the other buildings and masts, they had to be there. I remember going up there after a particularly intense storm, RP had gone off, and I went up fearing the worst. I opened the hut and saw no obvious damage to our equipment, I restarted our equipment and it all came to life as if nothing had happened, I was relieved. A moment afterwards a guy turned up at the door with a short white stick in his hand. He was maintaining equipment in another hut and he'd come to see if he could help, and be nosey. He explained that the short white stick was originally a long colinear that had borne the brunt of the lightning. I followed him to his hut, which I saw was bigger, cleaner, and emptier than ours, it also had a horrible burnt electronics smell and a lot of smoke! Basically all of his equipment was fried. Other engineers turned up, so I made my getaway, since I was probably late for dinner or something.

You'll find no mention of TheNet in this section. This seemingly came out of nowhere in (I think) later 1988 and was a complete functional clone of NET/ROM but was open source and had no encryption or callsign locking like the original. It didn't take too long for Software 2000 to take legal proceedings against the people behind TheNet. An independent software source code analyst verified that TheNet appeared to be an almost perfect copy of the Software 2000 code, but with the arguments to the functions reversed compared to the original. Ultimately the court ruled against the creators of TheNet, but the damage was done, and sales of true NET/ROMs fell through the floor. DANPAC had very little to do with TheNet, not for legal reasons, but because BPQCode was considerably more powerful and flexible. Later versions of TheNet also included IP over AX.25 routing which made it unique, but that wasn't enough of a selling point for us to use it.

I believe RP closed down sometime in the late 1990s, although by then I was doing other things and was no longer responsible for it.

In the TAPR DCC proceedings were articles by Phil Karn KA9Q about his developments. He wrote an MS-DOS program that offered a terminal with a great many commands that implemented, AX.25, TCP, and UDP all over a KISS TNC. It was, and is, a lovely piece of software, and even included a mailer for SMTP data transfers! I think it expanded to include NET/ROM but I could be wrong about this. One thing that was great about this software was that it was open source which was still pretty rare at the time. I got my first version of it (dated 871225.33n) from Keith G4LZV of the Kent packet group. I was in London on business for a few weeks in early 1988 and I offered to buy him dinner if he could give me a copy of the KA9Q software. Luckily he knew of an excellent Chinese restaurant in Bayswater that we could eat at. We talked nothing but packet that evening.

The original KA9Q NET was based on a simple commutator loop and was pretty simple to understand. The last version of this iteration was dated 890421.1, and was very stable, and more importantly understandable. In some respects I feel that this is the best version released, but others disagreed with me.

It was suggested by Rob PE1CHL that by judicious abuse of C's setjmp/longjmp functions, that a form of co-operative multitasking could be implemented. At this stage the software was redeveloped and renamed NOS (Network Operating System) and was further developed by Phil and by many others. This new approach appeared to work, but it also seemed to coincide with the software beginning to bloat a little too much since it was trying to be a multitasking operating system as well as a packet radio program.

I used NET very happily, and later on once I had the Linux kernel AX.25 running, I was able to run NET/NOS at a friends house and TELNET into my Linux machine. It was horribly slow, but a great demonstration of the capabilities of both ends. I was never totally sold on running TCP/IP over packet radio because of the overhead for the protocol before you even got to the data payload. If we'd all had clear 9600 bps links, it may have been a different story, but with our links of the time, it was just too slow to be usable. Indeed when we had Linux TCP/IP running over AX.25, the kernel TCP implementation needed modification to handle the very large timeouts required over our links.

One of my diversions was acquiring an Acorn Archimedes in the late 1980s. This was a marvelous machine, using an early iteration of the ARM processor, and for its time was a very powerful computer. Mine had 4MB of RAM, and although a little quirky, the operating system was pretty impressive. The OS used cooperate multitasking and required each program to voluntarily give up access to the CPU regularly. People were already using KA9Q NET/NOS under emulation on the Archimedes but the experience wasn't very pleasant. I decided to port KA9Q NET to the architecture.

I chose the NET version because the central commutator loop lent itself to giving up the CPU after each iteration to allow the whole machine to multitask. I did add the ability to have a separate window for each session, AX.25, TELNET, etc. I ported the software in about one day. I was very pleased with the results and so were a number of other people since it ran much quicker and was also a good neighbour on the computer. I maintained that software for a few years before getting into Linux.

I can now say that I know Phil very well, and have met him a number of times. He's moved on from packet radio, and I recommend his KA9Q Radio project if you want to try something exciting.

I have already mentioned Sysop 1 earlier, in early 1988, sysop 3 was held in Bradford (I missed Sysop 2 I think), I think it was the first John went to, and I travelled with him in his camper van. BPQCode was still not massively known, but was taking off (remember this was pre Internet so software distribution was more challenging) and many still hadn't heard of it.

I remember two things from this meetings. The first was a talk by a visiting ham from California who described packet radio there. It was a fascinating talk and in turns scary and hilarious. The way he described after midnight on 2m in his area as “weirdo prime time” was memorable. Unfortunately I don't remember much about him, but it made the meeting more interesting than it could otherwise have been.

Also at the meeting, G3RUH gave a demonstration of his newly developed 9600 bps modems, and we were all mightily impressed, although no RF was involved. Both John and I got RUH modem beta boards (the only difference was a missing pull-up or pull-down resistor on the DCD line). They were Eurocard sized and interfaced to standard TNC-2 modem breakout pins.

As impressive as the modem was, the problem we had was the lack of suitable radios to use with them. Tapping into the discriminator for receive was relatively simple, but not all radios used true frequency modulation on transmit, many used phase modulation. For FM use this difference was unimportant, but for high speed packet, it was fatal. This is one of the reasons why we didn't get 9600 bps links running at RP, we wanted to, but no-one seemed to have the skill to design or market a suitable radio.

Kantronics came out with a special 9600 bps capable radio in the early 1990s, but they were very expensive. By all accounts they were very good, but I never got to use one.

My modem spent its time, post 1990, on the packet satellites, on my modified FT-290R and TS-790E, attached to a Kantronics Data Engine.

At one of the later sysops meetings in 1995, held somewhere near Birmingham I think, I approached Alan GW4PTS about taking over the Linux kernel AX.25 code from him. At this time Alan was responsible for the whole Linux kernel networking, and the AX.25 was somewhat lacking in features, I think it was only AX.25 v1 which was already old by then. He readily agreed. One advantage I had over earlier times was that I was now Internet connected which helped massively with communications with interested people.

Using the SDL diagrams in the TAPR DCC, I implemented AX.25. This is when I found that the SDL diagrams were not complete, however I had the narrative description of the protocol, so I was able to finish it based on that. I think I probably found a mistake in the published SDL diagrams at the same time. I was able to ask Alan to include my code which he did with almost no comments. I then went onto adding further protocols.

One moment of shame for me was early on in the development of the AX.25 code. I was looking at the code one day, and I saw a condition in the code that seemed to make no sense, I had written it for sure, but why? So I removed it and restarted the kernel. I very quickly realised that I'd made a mistake, my Linux machine was now responding to ALL AX.25 connect requests regardless of the source or destination, and sending rejection messages to all other packets, no matter what the source or destination. The condition code soon went back in, along with a suitable comment, and the balance of the universe was restored.

First to be added was NET/ROM since I was very familiar with it. I split the implementation into two separate parts, the kernel part did the core protocol based on routing tables, and a user space daemon that listened for, and transmitted, NET/ROM NODES broadcasts, while updating and querying the kernel NET/ROM routing tables. It was a split that made sense, and I believe is still in use. I included a BPQCode extension to the NET/ROM protocol at the same time.

I also added ROSE which was the ham name for X.25 layer 3 (PLP). ROSE is quite simple and unlike NET/ROM (or indeed IP) is not datagram based, but is instead virtual circuit based. Without going into the details, it means that the protocol overhead on data packets is considerably less than NET/ROM at the expense of not having dynamic routing. Once a route is established from A to B, via C, D, and E, it will use that until the connected is ended. NET/ROM potentially has the ability to change a route for a better one during a connection.

Only two groups worldwide used ROSE in reality. One was in the north-east of the USA and were named RATS, W2VY was my main contact with them, and he was developing a ROSE ROM for the TNC-2. The other group was in south-west France, which is how I made friends with F6FBB who was a part of that group.

One of the shocks of my life was when I received an email from Mr. Linux, Linus Torvalds, who had a query about some of my code. It was nothing particularly big or important, but it was a shock. I've since lost the email.

The kernel code spawned a large set of users, and some were very clever with leveraging programs to provide invisible links. For example we had ax25d which was the AX.25 version of inetd, and that could be used to spawn programs based on incoming packets using different SSIDs for differentiation. Some people had some pretty amazing plumbing between machines and programs using pseudo-ttys and other mechanisms.

I stopped the kernel AX.25 development in 1998 or 1999, I forget exactly when.

So I think that's my complete journey in packet radio. What people reading this don't realise is how much of the wild west this all was. We genuinely felt that we were doing something new, the Internet was only a rumour for most people, and for the rest of us, NET/ROM seemed like magic. It was the first time we'd seen a network operating and we could get our hands dirty doing so. It was helped, or hindered, by the activity levels of the time which were huge, finding a free channel on 2m FM was very difficult at that time, and that also applied to packet, everyone seemed to have a TNC or a Baycom modem.

I have not really come back to packet radio, I do have two Nino TNCs which are everything we wish we had in the 1980s and 1990s, as well as 9600 bps capable radios. I have introduced the idea of using C4FSK to the high speed packet world, to get 19200 bps into a 25 kHz channel whereas previously we stopped at 9600 bps from the G3RUH modem technology.

Things like IL2P show the way forwards by simplifying the packet header and adding strong FEC to the header and payload. This is all stuff we could imagine back in the glory days of packet, but we didn't have the CPU power nor suitable RF hardware to even attempt. We would have loved to have had Raspberry Pis then, but of course they would have counted as supercomputers in that era. So don't criticise us for what we achieved, but we didn't have the hardware, we were ahead of the curve and would have to wait a long time for the manufacturers and computers to catch up. It was a lot of fun though, probably more than you can imagine.

I have left out some parts, I have not always named names, and most of the controversies have been glossed over. Packet became very political at times, although DANPAC always managed to stay out of it. On a couple of occasions we threatened to block certain BBSs traffic coming over our part of the network if they didn't sort out their differences, and our representations were accepted as we usually stayed neutral in most arguments. It's interesting that some of the same issues are to be seen in the DMR world, and for pretty much the same reasons. This is one of the reasons why I tried to make most of my digital voice networking be decentralised so that no one group has power over another. You'll find no mention of G1NNA and G1NNB here!