Recovery: “Musical” SyQuest Cartridges with DoubleSpace Compression

I’ve long offered my “volunteer” data recovery services for those with 44/88/200Mb 5.25″ SyQuest disks, and it’s been a little while since my last SyQuest recovery post. Just when I thought that maybe nobody else would be interested in it, I was contacted by Producer/DJ Ido Amin who had three 44Mb cartridges with some old art and music projects which he wanted to recover. I extended my data recovery offer to him, and soon enough, a parcel arrived at my doorstep.

Step 1: Examination and Physical Recovery

The disks were well packaged and arrived safely. Inside, there was a letter –

letter-text

Knowing from the past that bad cartridges can damage drives, I took some time to inspect the cartridges. The cases it arrived in were a little dusty and “sun-tanned” (yellowed plastic), but the disks inside were mostly clean.

Using my Linux-based recovery box, I used ddrescue to recover the data into raw disk image files for further analysis. One of the three cartridges read out without any faults, another had a 512 byte bad area that was recovered after about 100 retries.

syquest-renf-bad-sector

Unfortunately, the last disk was not as lucky – it had a 512 byte bad area that could not be recovered even after >4 hours of attempts (recovery restarted a number of times). The error seems to suggest that the drive was unable to locate the sector itself on the media, so maybe a write failure or magnetic media failure is responsible for the flaw.

Step 2: Image Analysis

Unlike all the other SyQuest drives I’ve dealt with, all three cartridges were MS-DOS formatted. One of the cartridges contained straight files which could be extracted directly. This makes things easier for me in a way, except for one little problem. The remaining two of the three cartridges were compressed with DoubleSpace.

dblspace-filesFor those who didn’t live through this era, DoubleSpace was a transparent full-drive (or partial drive) compression utility included with MS-DOS 6. This was in an era where CPUs were relatively under-powered, I/O was slow and space limited. Including DoubleSpace allowed users such as myself (at that time) with a 40Mb Miniscribe MFM hard drive the chance to run Windows 3.1 alongside a full complement of MS-DOS programs, albeit slowly. The whole system worked by loading a module (DBLSPACE.BIN) into memory that mounted DBLSPACE.00? files for reading and writing. The actual compressed drive would appear as C (e.g. if your C drive was compressed), and the “real” C-drive (i.e. the host drive containing the DBLSPACE.00? file) would be mounted at a higher drive letter such as F.

Unfortunately, such volumes are really only able to be accessed with the software they were written with. No DoubleSpace compatible utilities are widely available today. To compound the matter, DoubleSpace was very shortlived due to a lawsuit bought upon Microsoft from the competing disk-compression-utility company Stac Electronics. This resulted in DoubleSpace being removed in MS-DOS 6.21 and being replaced by DriveSpace in MS-DOS 6.22 (and onto Windows 95/98).

Step 3: Recovering the Data

As I don’t have a working MS-DOS installation on a computer complete with SCSI drivers for a SCSI card, getting access to a 44Mb cartridge image under MS-DOS posed a bit of a challenge.

To solve this, I decided to use my MS-DOS 6.22 VM in VMWare as my recovery platform. A 520Mb primary drive had MS-DOS 6.22 installed. To import the image “as if it were an attached SyQuest drive” requires converting a raw image to a .vmdk file. Unfortunately, there isn’t really any straightforward way I found to do this.

Instead, to do this, I first created a pre-allocated hard drive of a larger size as a secondary drive. I selected 0.1Gb, as this is larger than the 44Mb cartridge image. Then, I recognized that the .vmdk file containing the 100Mb file is just raw sectors, I overwrote the first 44Mb of that .vmdk file with the cartridge image.

When the system was booted, a D: became accessible and the file listing matches the WinHex analysis above. So far so good. To try and mount the image, I tried using DriveSpace as Wikipedia states:

MS-DOS 6.22 contained a reimplemented version of the disk compression software, but this time released under the name DriveSpace. The software was essentially identical to the MS-DOS 6.2 version of DoubleSpace from a user point of view, and was compatible with previous versions.

To get access to DRVSPACE, I had to set it up by compressing a volume. I created a blank third throw-away .vmdk to compress, so that I could bypass the set-up wizard. This .vmdk was then deleted.

cant-mount

Despite what was on Wikipedia, DriveSpace is not able to mount DoubleSpace volumes. This was unfortunate. Further investigation seems to suggest the following –

conversion-means-decompressing

This implies that users who upgraded from MS-DOS 6.22 from 6.2 could still continue to use DoubleSpace (probably by preserving the DBLSPACE.BIN and existing set-up). Those who wished to convert the DoubleSpace drives to DriveSpace entails full decompression and recompression. Those who installed MS-DOS 6.22 from scratch do not have DoubleSpace compatibility, which is unfortunate.

To solve this, I instead looked for the necessary file – the only option was a MS-DOS 6.2 Boot Disk with DBLSPACE.BIN. I managed to boot the VM from the boot disk to success – the DoubleSpace volume auto-mounted as D: and files became accessible.

The problem is now how to get the data out of there? Unfortunately, as xcopy was not available on the boot disk, and executing xcopy from the C: MS-DOS 6.22 install results in “Incorrect MS-DOS Version”, it required another tool. In this case, dosver was injected into the boot disk using WinImage, so that it could be executed to overcome the incorrect version message. This allowed me to finally copy all the files onto the uncompressed C: which I could then use WinImage or WinHex to access the .vmdk and extract the files. Job done!

It may actually be possible to copy DBLSPACE.BIN from the boot disk to the root directory of the MS-DOS 6.22 installation and reboot from that – with any luck, the OS might pick up on it and load it upon a restart, but I didn’t try this.

Step 4: Returning the Data

Interestingly, within one of the DoubleSpace volumes, there were a few ZIP files. This was on the cartridge with 512 bytes unrecovered. However, the recovered ZIP files were decompressed without any errors, and further analysis showed that the DBLSPACE.000 file just so happened not to use the bad sector, so no data was actually lost. What a good coincidence.

As usual, the files were zipped up and returned via Dropbox share. However, many of the files would have been created with old software and programs which are not able to run under modern computers. That being said, it is still relatively easy to emulate an old MS-DOS or Windows 9x machine under a virtual machine, so it’s not wasted in the end.

Conclusion

Another set of cartridges arrived for the voluntary data recovery service. The cartridges did put up a fight, but the physical recovery was mostly successful. The biggest problem was the use of DoubleSpace full disk compression, which became uncommon and rare due to a lawsuit. If it were not for the fact that I somewhat understood DoubleSpace and DriveSpace from having used it myself as a child, recovery of the data within would not be considered straightforward especially if it were not possible to source a boot disk or install disk set for MS-DOS 6.2. With a bit of “massaging” of image files, it was possible to perform the recovery using a virtual machine, which is more fun than trying to cobble together flakey old hardware.

Comment from DJ/Producer Ido Amin

Remixes are very common these days, but producing them in the late 80’s and early 90’s was quite a different story. Sampling on a home computer was a very novel idea, with challenges in hardware, software, speed, memory and disk space. I milked the best in this regard from 3 different home computers (an Apple ][ with a Greengate sampling card, an Amiga and an XT). I already had one remix hit, and was thrilled when Greg Hendershott’s Cakewalk 3 (1991) appeared, and I was able to create some more remixes on the relatively vast storage of some second-hand 44mb Syquest cartridges.

Twenty-five years later, computers have improved, sample rates and bitrates have quadrupled, and remixes are culturally acceptable (hallelujah!). As a form of digital crate-digging, I wanted to revive the early sample projects and re-do them.

But 25 years later, Syquest drives are no longer around. Searching the internet, I found Gough Lui from down under – pretty much as long as long distance gets! – and he kindly helped me resurrect the material, even visiting the netherworld of defunct OS systems with great skill to salvage what was possible.

Among the data salvaged, I’m thrilled about one specific audio project – a remix for one of Aris San‘s tracks, which had a title identical to my girlfriend at the time. For an experimental artist, one of the gifts of the digital domain is the ability to go back and re-mix your project, having the luxury of hindsight. The old ’91 remix is on my SoundCloud – email me for a private listen link.

Aris San was a fusion artist – playing energetic and soulful Greek music on an electric guitar, rock’n’roll style, instead of on a Bouzouki. That’s the spirit of all music – evolving, adding, creating fusion and integration. The passion for remixing is really the classic, traditional approach!

About lui_gough

I’m a bit of a nut for electronics, computing, photography, radio, satellite and other technical hobbies. Click for more about me!

This entry was posted in Computing, Tech Flashback and tagged , , , , , , . Bookmark the permalink.

Error: Comment is Missing!