View pdf of the article here Electronics Weekly 2023 11 29 issue – 26, 27
Reproduced here with the kind permission of the Editor of Electronics Weekly.
When a decades-old system is still heavily relied upon, but its now-obsolete storage device fails, what is the best course of action? Brian McSloy, Chief Technology Officer of Solid State Disks Ltd advocates the use a solid-state-based emulator and explains what’s involved in making one.
Data storage media such as magnetic (floppy) and magneto-optical (MO) disks, magnetic tapes and even early HDDs are, from a technical industry viewpoint, things of the distant past. However, many systems that were designed in that distant past, incorporating then state-of-the-art storage devices and media, are still in use today and must provide several more years of service.
For instance, in the military and aerospace sectors, radar systems, simulators, automatic test equipment (ATE) and computers are in use that were built more than 40 years ago and are based on pre-PC mini-computers and industrial computers. Also, some airlines are using Airbus A320 aircraft that had their maiden flights back in the 1980s, when floppy disk was the primary means of data transfer.
In the telecoms sector, legislation mandates that legacy services must continue to be offered, regardless of their commercial viability. Accordingly, digital access cross-connect systems (DACs), private automatic branch exchanges (PABXs) and other infrastructure from the 1980s and 1990s must remain operational. An example of perhaps the most ironic continued use of yesteryear data storage technology is within the semiconductor industry, where some fabs use tools that accept file transfers (for process recipes, for instance) only by floppy disk.
Where the removable media is concerned, some types are still available, albeit increasingly hard to come by. For example, the last manufacturer of 3.5” floppy disk media called it a day back in 2010. But that is not the main problem. With their moving parts, it is the mechanical drives themselves that start to fail. New replacements are simply not available and refurbished second-hand drives, when they can be found, carry short warranties. Moreover, it is not just that the original storage devices have become obsolete, alternatives that use the same physical interfaces are not available either.
In the interests of sustainability and keeping the host system operational for as long as possible, the practical solution is to replace the failing storage device with an emulator, a solid-state-based drive that uses the same physical connector, interface protocols and memory maps as the failing drive. Taking the swap-in replacement route means the host system needs no modifications and being solid-state, reliability is greatly improved (and with a lower power requirement). Also, if fitted with an Ethernet port, the new drive can be networked which opens a whole new world of possibilities.
As for the choice of storage media to use in the emulator, an industrial class Compact Flash (CF) card is the ideal choice, particularly where the end application still requires the memory to be removed.
Why industrial CF? It provides high endurance and longer-term availability than its commercial equivalent. Based on the end application (i.e., how the host system will be using the drive) other considerations include capacity, performance and memory wear. For instance, multi-level cell (MLC) is higher capacity but slower and has less endurance than single-level cell (SLC). That said, memory access will still be faster than with the old drive. As it is program-erase (PE) cycles that cause Flash memory wear, the correct selection of CF card is important, with the choice mainly dependent on the write frequency and the required device capacity.
Copy That
An extremely popular way of connecting computer peripherals in the 1980s through to the early 2000s was the small computer system interface (SCSI, “scuzzy”). Many storage device types adopted this interface including floppy, MO, tape and HDD.
The SCSI interface was standardised in 1986 as the SCSI parallel interface (SPI) 8-bit wide, single-ended bus. The SCSI standard evolved through a number of iterations, doubling the number of data lines to 16 and incorporating differential signalling, allowing the transfer rate to significantly increase, before finally being superseded by the serial attached SCSI (SAS) interface.
Also, the word ‘standardised’ must be taken with a pinch of salt as there was, particularly in earlier implementations, a level of incompatibility that has to be catered for in any emulator. Other interfaces were launched that do not incorporate the full standard, retaining just the SCSI command protocol or the SCSI architectural model, for example.
Within SCSI there are a number of standard mode pages and a set number of vendor unique ones. The latter tend to be used by host systems to determine if the drive is valid or not. Host system OEMs like Compaq and HP were heavily into this practice in the ‘80s and ‘90s. Indeed, many storage devices were developed for a specific host’s chassis. Figure 1 shows a Fujitsu HDD manufactured in the 1990s to fit a 1980s design for an IBM host computer.
This looseness of the SCSI standard also meant drive OEMs, such as CDC Control Data, Seagate, Quantum, Fujitsu and Connor, could implement SCSI in slightly different ways to make their solutions proprietary.
As mentioned, the goal is to make a replacement drive that can be switched for the failing one and for the host system not to notice.
In terms of designing the interface protocol into an emulator, there is the issue of accounting for any tweaks the host system might require. This information may be available online, but the most reliable method to determine it is to interrogate a working drive, even a refurbished one will do provided it is a similar model.
In the absence of information or an identical or similar drive, one option is reverse engineering: taking a logic analyser to the end application and placing it in-line between the host system and the legacy drive and recording the control and data lines. The timings will need to be reproduced in firmware and in this respect microcontrollers (MCUs) are available that lend themselves well to the task. For example, a highly capable MCU is the Atmel SMART SAM9XE which is based on the integration of an ARM926EJ-S processor with fast ROM, RAM and Flash, and has a wide range of peripherals. It also embeds an Ethernet MAC and a MultiMedia/SD Card Interface.
An emulator for virtually any 1980s/90s drive can be built around a suitable MCU, a suitable interface driver, some glue logic and power devices, and result in a relatively compact, low-power unit. Figure 2 shows a 2.5” solid-state SCSI (50-pin connector) drive with dual CF cards, which means data can be mirrored.
Once an emulator exists as a replacement it should be plain sailing. But will it though? Legacy drives are for the most part based on logical blocks, where the exact encoding of the data onto the disk is handled internally by the storage device (HDD, tape, etc.), but for some classes of device, such as ESDI or floppy, the encoding has to be implemented within the storage device’s firmware. This is a complex operation that can only be achieved by reverse engineering the particular implementation, including detailed low-level examination of the format written to the media, which sometimes varies across the surface.
What also needs to be considered is what the host system expects to be written to the drive or media before it is installed. In other words, the drive may need to be formatted, in much the same way a USB stick needs to be formatted to at least FAT32 for use with Windows. Also, some hosts will expect a new drive to be filled entirely with logic zeros. Other hosts will require the old data to be present on the new drive. This can be a problem, as some drives will have become very fragile over the years. Great care must be taken not to cause loss of data during investigation or replacement.
Moving Target
Above we have mainly discussed SCSI, but ESDI and IDE were also popular interfaces in the ‘80s and ‘90s. Thankfully, these can be emulated too and emulator OEMs like SSDL have created firmware libraries that reside in each emulator.
However, obsolescence is a moving target, and there are systems in use today that have already had their original drive replaced with an emulator which has subsequently become obsolete too. Accordingly, emulators can keep legacy systems operational, improve reliability, reduce power and support new features if required, but they must themselves be subject to obsolescence management. Making an emulator to replicate exactly the behaviour of a yesteryear technology drive, which was probably paired to a specific host, is not without its challenges or rewards.
