I bought a good number of sound cards over that period.
I started with a cheap Soundblaster clone called the Thunderboard. It offered Adlib compatibility, which was enough for games music. The card was somewhat noisy when playing audio and not always compatible. It did, however, have native drivers with Windows 3.1 when that finally appeared.
The next card was an early wavetable card from Orchid. I wanted a Roland but couldn't afford one, so went for this thing instead. The card supported the GM sound set, but also roughly emulated a Roland device. It also emulated Adlib playback, but had severe compatibility issues when it came to playing back wave audio.
A few months later I acquired a Soundblaster PRO. Finally I had stereo PCM, but also updated the FM synthesis to OPL3. Finding games that supported OPL3 was tricky, but when they did appear the sound was phenomenal, with big 'farty' bass sounds.
Eventually my old PC became obsolete so I upgraded to something new. That came fitted with it's own adequate Soundblaster 16 clone from Opti, but went back to OPL2 for FM. It lacked any wavetable facilities onboard, but had a slot for a daughter-board that offered the feature. Unfortunately I could never find anything to fit that slot.
Then I picked up a Yamaha XG wavetable board that was probably the last in wavetable technology. The XG soundset added many more instruments to GM, together with a whole other set of parameters that could be tweaked. By then, of course, most games were abandoning external music sources, so it was only really used for other projects. I've still got this card at home, but lack anything with an ISA slot to fit it to.
I'm pretty sure I also picked up another cheap Soundblaster clone around this time too, as the card originally fitted into the PC wasn't compatible with the latest version of DirectX requited by one game. Again
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.
Kleeneness is next to Godelness.