One of the commercial accountancy software packages found in the UK prompts its user to make regular backups of the data to floppies for archiving purposes.

The strategy behind the game is to clear the playfield of all bar a handful of small asteroids, and then wait for the flying saucers to appear. If you're moving fairly quickly up or down the screen you can avoid the saucers with practice. As the game awards 1000 for the small saucers and a bonus life every 10,000 points it's a somewhat easy task to rack up many extra lives. Once the last asteroid was eliminated, the game would restart, increasing the number of large asteroids at the start up to a limit of around 12.

Early versions of the game were even easier as broken game logic resulted in an area of the screen that rendered the player immune to attacks. There wasn't even any means for making the game harder by setting the game's dip-switches - these only controlled the initial number of lives and other sundry settings such as language and coin count. Suffice to say experienced players could easily play the games for hours at a time.

Atari later released Asteroids Deluxe which was somewhat harder. This included a second type of saucer that split into components which homed in on the player, as well as amendments to other parts of the game logic.

There's no maximum as the score counter rolls over at 100,000. You need to have someone to manually keep track of the number of roll overs.

I remember being in an amusement arcade in Redcar, UK in the early 1980s, when someone was attempting an Asteroids record. He had an assistant with a clipboard to verify the roll-over count.

Intelligent LAN cards are nothing new. Back when 80386 processors were being used in servers, several manufacturers produced NICs with their own processor. The LAN protocol stack would be run partially on the NIC itself to reduce the load on main server. We had a Xenix server at work that used such a NIC.

As a matter-of-fact I've still got a similar designed serial card in my cupboard of spares. This used an 80186 to control 6 serial lines, leaving the main processor free to get on with other things.

I seriously doubt that there will be a VM capable of running this OS. The Altos 586 used an Intel 80186 processor, which was an 8086 with several external components (clock generator, interrupt controller, DMA controller etc.) integrated into the chip. Therefore the machine is not PC compatible as these bits of hardware will be accessed in a different mechanism compared to a standard PC.

The 80186 was typically used in embedded devices. A few non-PC compatible or semi-PC compatible machines did use it, most notably the Tandy 2000.

This takes me back....

Firstly, I'm sure that there were never 10MB IDE drives. The drive will either be ST506, ESDI or possibly even SCSI.

Secondly Xenix would create several filesystems within the Xenix partition, using its own separate partition table. As far as I'm aware no mechanism to read these tables was ever added to the Linux kernel.

I remember being in London in 2000 attending a training course. It must have been late in the year, as it was after we'd moved offices that August.

Anyway whilst down in London I read a few of those free newspapers to pass the time, and couldn't believe how they were hyping stocks in all kinds of daft websites. Then there were the equally stupid adverts splashed all over the underground. One company in particular had bombarded the whole of the network whilst lavish adverts of for their service, whose entire mode of operation involved serious personal privacy breaches. It was obvious that a crash was looming.

I worked for a systems reseller/support provider back then. We had 50 to 100 customers out in the field running a particular OS and associated software products.

Our major vendor was extremely slow at getting updates out. The OS definitely had a problem, as account expiry dates were stored using two digit years, so ever user on every system would get locked out come 2000. They managed to devise a fix to the account security system, but it was well into 1999 before this update appeared. Even then the update was in the form of a complete new release of the latest version of the OS which had some terrible inherent problems not seen in the earlier releases many customers chose to still run.

More annoying with this new update is at the same time many long lasting OS features were discontinued, features which the majority of our customers used. It was as if they simply couldn't be bothered to audit the code, so they simply junked it. These features included WAN connections via serial and leased lines and integration with IBM mainframe architecture - with these features no longer available the OS no longer had an advantage over the then competition.

The knock-on effect was that the majority of our customers simply decided to abandon the OS altogether and migrate to something else, such as NT.

Some really old and depreciated API calls could get dropped in the transition between OS versions. When depreciated these calls will log error messages in the various log files.

Back in the early 1990s my then employer was a reseller of a non-PC server platform. The manufacturer sold two models with different processor options (386, 486 I believe), and each had the option for extra memory boards from 4MB to 32MB in capacity. The memory boards for the high-end machine cost around 4 times the price of those for the low-end model, although the specification was otherwise identical.

This hardware platform was discontinued, as the OS vendor moved to PC platforms. A few years later we managed to acquire a job lot of these old servers to from a customer, in the hope of using them as spares for those still out in the field. All of these servers were supplied with the memory boards in place. It was then that it dawned on us that the only difference between the two versions of this memory board was the position of an unmarked option jumper.

That looks like Espionage Island from Artic Computing. It was released initially for the ZX81, then ported to the larger memory ZX Spectrum with no changes - same limited text descriptions in upper case text, limited vocabulary, white text on a black background and so on. Their whole series of games were fairly limited plot-wise, and extremely linear - i.e. just one puzzle to solve at a time for most of the game. So if you got stuck on one puzzle there was no point exploring the rest of the game.

The only advantage that Artic's games had is that they were quick, having been coded entirely in assembly language. Many other games of that era were written in BASIC, and therefore suffered from having slow parsers and logic engines, with some games taking almost a minute to respond to commands. One software publisher went half-way - they coded the vocabulary parser in assembly, but still had the logic in BASIC.

Here in the UK there were a good number of such games published during the 8-bit micro boom of the early 1980s.

The first game to really start things going was Melbourne House's The Hobbit which, on some platforms, included crude graphics for some of the locations. The parser for this game was quite complex, allowing the player to pass instructions on to other characters. The other characters in the game also had some form of artificial intelligence, granting them the ability to wader around at random and move things around. Consequentially no two games were ever the same.

Another significant developer was Level 9 who created huge games using text compression. These were sold for a huge range of platforms.

Another major development was when Gilsoft developed The Quill, a an adventure game construction kit. This allowed virtually anyone to create a game based around a standard runtime environment. Many games were then released to the market, some so cleverly constructed that major software publishers could pass them on at full price. Later add-ons were created that allowed in-game graphics, basic sound effects and other features. Text compression was eventually added, too.

Only a few weeks ago I was given a URL by a recruitment agency for an on-line skills test which needed to be completed as part of a job application.

That particular site was coded to reject all login attempts if the user agent wasn't IE. Furthermore there were severe rendering problems if I used anything other than IE6, making the test impossible to complete. As I don't run Windows here by choice this was fairly annoying.

I ended up having to install a copy of XP under a VM just to complete the test.

I found an identical model at work about 15 yeas ago when clearing up. It came supplied with MS-DOS 2.x, a bus mouse, and some strange GUI software called Epson Taxi. If I recall correctly the floppy drives uses non-standard connectors, so it wasn't possible to fit anything of a larger capacity. I'm also certain that the second floppy drive wasn't working.

It was possible to get the thing onto our LAN using a boot floppy and an ARCNET card, but even that was tricky as it took some effort getting both DOS and the LAN software onto a 360K floppy.

Eventually I located a suitable 8-bit ISA hard disk controller and hard drive from elsewhere in the building.

Most of these flaws probably can be applied to the PCs and CP/M word-processors of Amstrad, a UK consumer electronics company who started to make PCs in the mid 1980s after having some success with their own 8-bit machines before then. Most problems were due to saving costs.

Early PCs featured the power supply built into the monitor, which, coupled with non-standard monitor ports, made replacement difficult. The power-supply wasn't rated high enough to drive many expansion cards. The units themselves, being maninly plastic, had terrible shielding problems causing severe interference. They keyboard and mouse also used a non standard interface; not only was the connector different, but the different keyboard drivers made the supplied version of MS-DOS mandatory.

Later models had better PC compatibility, but some suffered reliability issues due to Amstrad's proprietary hard disk controller. These were so bad that later units were retro-fitted with an standard off-the shelf controller, taking up one of the three expansion slots.

The CP/M word-processors originally shipped with 3" floppy disk drives, which were almost exclusively used by Amstrad. These units also had no on-board ROM; the printer ASIC supplied the process with the minimum instructions to boot off a floppy. The majority of the printer electronics were in the base unit, which meant that the printer itself used a non-standard interface and couldn't be replaced with purchasing a third-party serial interface. Although these machines were supplied with 256 or 512 MB RAM, the majority of the memory could only be used as a ramdisk.

Amstrad also produced a couple of portable machines. They did have a full-sized keyboard, but unfortunately came with a tiny LCD screen. They were also floppy only without third-party expansion units.