At last, the promised final special part of my Melbourne trip has arrived. The difference is that this part didn’t really have anything to do with my trip to Melbourne at the beginning, and started long before I even had any idea I was going to Melbourne. It touches on my voluntary SyQuest data recovery offer, which was bought to a halt after the drive was damaged. Each and every recovery project is a little different, so read on to find out what difficulties were encountered and workarounds used.
It is with special thanks to the reader who has granted special permission for me to use limited low-resolution screenshots of the contents to help illustrate the article. I’ve tried my best to redact sections of these screenshots non-essential to the story.
I was contacted by a reader from Melbourne back in February about some SyQuest cartridges (88Mb and a 200Mb) which had been left sitting for a while, from which they wanted the data recovered from. Apparently, it had been on the backburner for a while, and they were going to try it themselves at some stage but things just didn’t end up happening and so they ended up contacting me. Rather embarrassingly, it’s now the end of June, and I’m only just posting about this now. What can I say? It’s been a long road, and I’ve been so incredibly busy. Sorry about that.
Of course, I was ever so willing to assist a fellow person in need, but my primary workhorse was an 88Mb drive that couldn’t touch the 200Mb cartridge, and it was damaged after its encounter with a few moldy cartridges. Without the necessary tools, I couldn’t really “do my magic”.
It came as a surprise to me that the reader was generous enough to offer to purchase the required drive and have it shipped to me in addition to the cartridges to perform the recovery, after which the drive would remain in my custody to help others with their recoveries as well. It was an offer I could not refuse.
A quick hunt on eBay from both of us turned up some promising candidates, although the big killer was that it was to come from the USA where postal charges are very high. Two candidates were selected – one which was believed working but in a bit of a rough shape, and another in unknown condition at a good price, which looked as if it would be working.
By mid-March, the units had arrived at my door, and were to undergo functional testing before being unleashed on the patients.
The first drive was in a slightly rough state as described, and with anticipation, I plugged it in and crossed my fingers.
To much frustration and disappointment, the drive had two solid LEDs indicating a microprocessor or mainboard failure. The drive was not detected on the SCSI bus at all, and if you fed it a cartridge, it had absolutely no appetite and sat there with the spindle stopped.
As it turns out, this drive didn’t just have it a little rough. It was dead. Unfortunately, there wasn’t much that could be done about this, and it was decided that it would be kept and dissected in the name of science.
If you ask me as to why the drive was dead, I think the most probable cause is the failure of its prior owner to observe the orientation of the molex power connector and thus applied 12v onto the 5v rail and vice versa. This is especially likely when we consider that the drive had a cracked molex shroud around its power pins on the motherboard, and care must be taken because the SyQuests have the power plug mounted upside down with bevel edges on the bottom. I know this from experience, but your average Joe probably doesn’t.
The underside of the motherboard doesn’t have much except test-points, and looked relatively clean.
The other side of the motherboard housed all the components along with several “greenwire” jumpers soldered around the place to route unroutable traces and fix PCB errors. There was an Atmel AT27C1024 one-time-programmable ROM in a socket in a PLCC44 package. This likely contains the firmware for the drive, so I decided to remove it for further examination. It is also interesting to note the presence of an Intel controller, Cirrus Logic SCSI controller and various other chips for seek motor and spindle motor control. Towards the front edge, it seems that cartridge insertion status is monitored through two magnetic reed switches, similar to those used in home alarm door magnet sensors.
The rest of the drive consists of a few connections from within the chamber for the heads, seek motor, spindle motor and locking solenoid.
Wanting to see if there was anything that could be found firmware wise, I used my TL866 universal programmer and a PLCC44 adapter. Unfortunately, the chip was also dead, and returned FF for all cells.
At least the board had some resistor packs installed for SCSI termination. These are often hard to find, and easily damaged due to their SIP package. Very fiddly to install as well.
The other issue that I found with this first drive was hinted to when I looked through the flap – there was a rusting spring. Opening the cover shows that there is a good amount of deposit on the cover suggesting that water had entered the drive at one stage. Poor storage seems to have also potentially contributed to its demise.
Some residue was also visible on the cartridge tray, although it may purely be a cosmetic issue. Having rust flakes inside of the spring (not pictured) is probably not healthy for the mechanism though.
While this drive is a more technically advanced 200Mb drive, it’s also virtually unchanged from the internals of the 88Mb drive. Even the heads look roughly similar, and it appears to only have a single head gap from what I can see. The motherboard had a lot of component changes.
The one major change is really the front cover. Instead of having a flap that “falls into” the drive on cartridge insertion, this flap pulls down to expose the opening.
This arrangement probably helps in reducing the dust that enters the drive by having a “lip” that seals around the door, and thus improves reliability. There’s also a clear logo outside, and a small window for you to see whether a cartridge is inserted and its write protect status.
While not functional as a SyQuest drive, which is quite disappointing, it was kept as a source of potential hardware spare parts.
Given the cost and having the items come so far, I was not entirely sure whether a decision would be made to go ahead with another “lucky dip”. After the readers’ negotiations with the seller to try and improve the postal cost situation, a second drive came towards the end of March.
This one claimed to be in an unknown state, but I looked at the listing and thought there’s no way this drive wouldn’t work. It is in an external enclosure from ClubMac as well, which provides it some additional protection.
The case had relatively solid steel and ventilation holes.
It also had an integrated power supply, cooling fan, electronics style connectors and switchable ID and termination. Looking up the model number, it seems that this same case was used for external hard drives as well. The label on the underside seems to claim that this unit was built with a SyQuest drive from the factory.
By now, you’re probably wondering why I bothered photographing almost every side of a beige box. That was because I was frantically looking for details on the input voltage it would accept. Items from America are often 120V only, especially older products, and simply plugging it into an Australian power outlet without confirmation is asking for disaster.
I took the lid off, since my Plan B was to simply take the drive out and use it like an internal drive. Everything looked neat inside, although the SCSI lead was a bit long. Still no hints as to whether it was compatible with 230/240v on top nor bottom.
The switching power supply board was made by Skynet Electronic in Taiwan. Looking at the fuse, which is supposed to be rated as a fast-blow 2A 250V fuse, and the primary side cap of 400V, I was pretty sure this was indeed 230/240v capable. It had a lot of Japanese Nippon Chemi-Con capacitors, which are very reliable quality products.
Despite this, I decided not to take a risk, and dismantled the drive for connection to my internal power supply. Later on, I tested this supply above, and found it to still work satisfactorily from 240v, so I reassembled the unit after all recovery was complete. Better to be safe than sorry – I didn’t want to be the bearer of more bad news if I could avoid it.
The drive still had its warranty label seal, implying that it had never been tampered with. On the top cover, there is a warning to make sure that you use genuine SyQuest manufactured cartridges to maintain warranty. The underside has its PCB covered with a protective plastic film, as in other SyQuest drives, but the motherboard on this unit is different and has ICs on the underside of the board as well. Out of the two units, I’d probably guess this unit was the older one.
On the rear panel, we can see that the termination resistor packs are not fitted as termination is supplied by the case. The upside-down Molex connection can also be seen as well.
As with the 88Mb SyQuest drive, only the lower row of mounting holes are provided, which can cause problems for tool-less cases which expect a certain configuration to exist.
Judging from the relatively light dust accumulation on the fan in the enclosure, it was run it a clean environment or only used moderately.
The case also has rails to accommodate 3.5″ hard drives, which probably explains some online listings for this model of “drive” which claim to be SCSI hard drives – the model number was for the enclosure only.
Not wanting to disturb the drive any further, I didn’t take this one apart in any way.
Plugging the drive into my recovery box running Debian Linux with an Adaptec PCI SCSI card, it was immediately recognized, and a known good cartridge read back in well under two minutes. This drive was as healthy as you could have wished for.
A total of five cartridges were the “patients” awaiting examination. Of the five cartridges, four of them were 88Mb cartridges, which we had covered quite well previously, so I didn’t bother with photographs.
It was my first time meeting the 200Mb version though. From the outside, the cartridge was the same size and shape as the 88Mb cartridge. The lower area had a larger moulded SyQuest logo, and the label was different. The write protect “wheel” was also a different colour – beige instead of bright yellow.
The moulding on the underside was slightly different, featuring a vortex-swirl design which seems to be an attempt to engineer the airflow inside the cartridge – maybe to improve cleaning, head stability or maintain lower acoustic noise. As usual, there is a serial and ID number label, but it is on the underside rather than the top. Screws are used to secure the cartridge assembly.
The spine has space for a label which can be read with the cartridge inserted.
The recovery process utilized ddrescue in its default mode to recover as quickly as possible.
All 88Mb cartridges recovered in under 2 minutes, with no read errors. Unfortunately, the 200Mb cartridge had two errors, totaling 8192 bytes, suggesting the loss of two 4kB native sectors. Interesting to see another storage technology back in the early-mid 1990s already probably adopting 4kB sectors for efficiency reasons.
To try and improve the situation at almost all costs, I reinvoked ddrescue with infinite retries and left it for most of the day. Ultimately, after 161 retries and 7 hours, it could not be read out, and I declared those two sectors as being “lost” possibly due to media failure (loss of magnetic material, accidental erasure, damage due to drive losing power during a write, etc).
This produced raw image files which contained all the data recorded in the user accessible sectors on the SyQuest cartridge, which completes the physical recovery. With these raw image files, we can mount them and try accessing the data.
Before moving any further, the image files were copied and safeguarded. A quick check of the images in a hex editor shows that they are all Mac OS formatted with an Apple Partition Map and HFS filesystem.
Before attempting to mount any of the images, working copies were made as mounting the images under Mac OS (or OSX) is done in a read-write fashion resulting in disturbance of the filesystem metadata and damage to the hidden Apple Misc/Driver partitions. Images which have been mounted are “dirty” and may not function correctly if rewritten back to a SyQuest cartridge and mounted on a period-accurate setup.
Because of the way HFS works, each file has data and resource forks. Copying between filesystems often results in the loss of the resource fork, which can render the file completely unusable – especially font suitcases where all the data is stored in the resource fork. As a result, work with the images must be done under Mac OS even if it is mountable under Linux.
To do this, I used Basilisk II, an Apple emulator, with an old image of a System 7 hard drive. I created a fresh blank virtual hard drive file (.dsk) to copy the files from the SyQuest images to, in order to consolidate all the files together into one image. It was found that using OSX to do this resulted in the loss of icons and other metadata.
Once this was done, it was found that one of the disks had all its data compressed as a StuffIt! Archive. While this isn’t particularly hard to “undo”, I felt it was pertinent to decompress it back to individual files to ensure that future exploration of files won’t need to resort to chasing down “old” software.
The second volume had many files (not shown), almost all of which were compressed with DiskDoubler. This type of compression was formerly popular, but is now proving a pain, as the decompressor only runs in Classic (or “real” System 9 and earlier) and Classic has been long depreciated and no longer available in OSX. Luckily for me, whoever wrote the cartridge had the forethought to include a copy of DiskDoubler which was a lifesaver in more ways than one.
Using this copy of DiskDoubler, all the “DiskDoubled” files were also decompressed back to their original forms, thus relieving us of the reliance on an obsolete piece of software which won’t run under modern OSes.
The following volumes were not compressed at all, which meant that files were already in their “native” format. After this, I had a hard drive image containing all the files, both data and resource forks, and with no oddball compression.
While I did deliver the raw images to the owner, I suspect the file data is more convenient for them. To deliver this back to them, I decided to use OSX (running in a VM on a PC, no less) to mount the image and then create a ZIP archive of the files. If you create a ZIP though this fashion, the resource fork data is preserved in a special __MACOSX folder inside the ZIP archive and restored upon unpacking.
So now, we have completed both the physical recovery, and the logical recovery of files from the filesystem.
Checking Out the Data on a PC
Of course, I like to take things a little further and examine the files, as there was a concern that even if we had the files, it may be entirely meaningless if the software to interpret them was not available or could not be run.
As I am a native PC user, I extracted the .ZIP archive to have a pile of files with no extensions. This is a common problem. By checking through all the files in a hex editor, the types can be understood by looking at the “file signature” – namely the first few bytes of the file.
The most common files on the disks were QuarkXPress files, with the “signature” MMXPR3 appearing at the beginning.
Next most popular were TIFF images, with “MM” appearing at the beginning.
There were also Macromedia Freehand documents, with a signature of “AGD2”.
And Photoshop Documents with a signature of “8BPS”.
There was also a few encapsulated PostScript files, which were easy to identify due to the text-comment heavy nature of the documents.
In the case of TIFF files, assigning the appropriate .tif extension on the PC was sufficient to preview and use the files. In the case of encapsulated PostScript files, assigning an .eps extension and opening in Acrobat Distiller was very hit-and-miss, due to the reliance on Macintosh fonts which are not available on the PC. Likewise, with Adobe Photoshop documents, allocating .psd extension allowed them to open with some font replacement.
The main documents, however, were QuarkXPress documents for which I have no PC version to use, and Macromedia Freehand documents, which Adobe Illustrator would not import due to a problem with file-linkage and absolute paths. Ultimately, for these reasons, working “within” Mac OS is necessary, which also means working within the constraints of what can be emulated.
Accessing the Data and Fixing the Headaches
To address the issue of QuarkXPress files, I needed to gain access to the document. As I already had a copy of QuarkXPress 3.11 for Mac installed in one of my system images, I tried to open the document there.
It would have been way too easy if it had worked. The file signature implied that it was a version 3-family file, so I decided to go over to MacintoshGarden.org and fetch a version that might work. [Aside: For some silly reason, their site doesn’t work in Firefox at all, but loads properly in Internet Explorer.]
For accuracy, I know that I can’t go too “far ahead” in version number, or risk not having the file open at all. I also know that I can’t have a version that’s too old, or it will give me the same dialog as above – so >3.11 and <5 was the criteria. This bought me to Version 4.
The most promising version was 4.03 in terms of completeness, so I downloaded that and “injected” it into my System 9 image using HFVExplorer. Unfortunately, that meant that the .sit file wouldn’t unpack.
The cause was simple – the file type information wasn’t set properly because of the “injection” process. Thanks to DiskDoubler’s File Info dialog, I can re-allocate the type and creator to allow for recognition as a StuffIt! Archive (SITD) and unpack it. (Note: this image was of another version, as I gave a few versions a try to see if I could get any of them working).
Of course, you can achieve the same sort of effect with Resedit, which I totally forgot that I had (inspecting a different file).
Instead, I had to fall back onto a Version 4.00 instead, which did unpack and execute correctly. Attempting to open a file bought up another problem of the era:
Because of the way QuarkXPress worked, if a file was authored with a particular “Xtension” active, it requires the same Xtension in the opening installation to access the file. Once the dialog is dismissed, you see absolutely nothing.
Luckily for me, I went trawling in the broken 4.03 version folder and found it had an Xtension called Pasteboard XTerminator. It isn’t the original Xtension, but it is one that removes the need for having it. Alternatively, there are other ways as detailed here.
In the Open dialog, it was noted that many of the documents were created in Version 3.0, but at some stage, were probably saved by an installation of 3.3, so they wouldn’t open in 3.11 which I had. But Version 4.0 was “new enough” to open all the documents.
Another issue that came about was that of fonts. While the original designers were diligent to copy all the special fonts used in a particular project to the cartridge, it seems that some of them might have been missed. Installing all the font suitcases into the Fonts folder inside System still left a few fonts missing.
In other cases, there were also linked images which went missing because they were stored under a completely different path and weren’t copied over to the SyQuest cartridge. It was interesting that the path implied the machine in use had a Micropolis 1Gb hard drive attached – they were quite famous for building very capacious hard drives in the era but went bankrupt with some questions surrounding their products failing.
Because the software didn’t “package” all the files together when saving, loss of linked files necessarily means that the document is rendered incompletely, which is an unfortunate reality unless the missing data is found elsewhere.
The next problem was trying to export the data from QuarkXPress into something which can be used on a modern system or even rendered. To my surprise, there wasn’t any effective export features at all. The only thing it could do, was to create a EPS file, which I thought was a good way to go about it.
Unfortunately, it seemed that Quark has its own interpretation of what an EPS file is which couldn’t be understood by any of Adobe’s products. It also didn’t render the fonts as paths, resulting in a reliance on Macintosh font suitcases which were not available on the PC.
At least the EPS files already on the disk were rendered by Adobe Illustrator 5.0 correctly under the emulator, although it did have lots of problems running out of memory on high resolution rasterization.
The only solution I could think of was to exploit its print feature. I decided to use a PDF printer called PrintToPDF version 2.45. Because of problems with emulator crashing, I had to disable JIT compilation which slowed down emulation significantly. I also had to increase the RAM of the emulator to try and make sure the process completed successfully.
A common user complaint was that all the document fonts were replaced with Times when viewed – this was because the fonts were not being rasterized, and viewed on a machine without the required font. As a result, I configured the printer under Page Setup to rasterize every font so that the generated PDFs will look the same everywhere.
PDFs could then be generated from the documents, although taking almost 15 minutes per page. Textually complex pages triggered an issue where the font cache would run out of RAM because of the size of the rendered text. As a result, I had to go to Adobe Type Manger’s control panel and increase the font cache to its maximum setting to try to avoid this. Unfortunately, super-large banner documents still triggered this, resulting in partially rendered text.
I also managed to grab a copy of Macromedia Freehand 8 and throw in a license key to gain access to the Freehand documents. It was found that if the RAM of the emulated machine was set to 1024Mb or 512Mb, Freehand hung on opening. Reducing the RAM solved the issue, but also caused problems with exporting, resulting in out of RAM errors depending on the export resolution.
Unfortunately, the PDF render had its own problems – text seemed to be on its own layer with transparency not working properly.
In Acrobat Pro, it is possible to select the white surrounding rectangle, hit delete, and then the transparency is fine again. Unfortunately, this was particularly time consuming and I didn’t feel it was worth doing it for every block, so I left it as-is.
In the end, unfortunately, there was no clear way to “upgrade” the files to a modern format without potentially losing fidelity and editability. This technique was merely to archive a “viewable” version which may not be entirely representative of the original document, but is the best that I could do with the tools available to me. It serves as a good guide as to whether to explore a particular document further.
There is a slim possibility that if the files were opened with modern versions of the software under modern MacOSX, that the documents may be better viewed and better preserved because of the removal of the limitations in computing power and memory of the “emulated” old Macs, but it is also quite likely that the new versions of the software will refuse to import the files altogether.
Meeting in Melbourne
Because I was going to Melbourne, and the reader was from Melbourne, I felt it was a great opportunity to meet up, have a chat over lunch and return their original media to them for safe-keeping along with a disc containing the recovered data (as a back-up over the digital delivery). After all, there was no good reason for me to keep the cartridges – the main reason I usually don’t return them is the prohibitive cost of return postage.
Needless to say, I had a very good afternoon talking at length with them on a variety of topics, and I thank them very much for their support in donating the drives to me so that they could continue to serve others in the future. As they were also looking to recover a few ZIP disks, I bought along an internal ZIP100 for them in return.
This adventure was a pretty long one, spanning over several months. In this case, the physical recovery didn’t take long, but actually making good sense of the data and regaining access to the data (even just to preview it) consumed a lot of my time and energy. As usual, when there’s a will, there’s probably a way, however imperfect.
The chronology of events was as follows:
Because this effort has now been completed, I now am in possession of a functioning SyQuest drive that is capable of reading 44/88/200Mb 5.25″ Alta-series cartridges. If you have some old long-forgotten cartridges that you want recovered, and are willing to post them to me (and/or contribute a small donation), I’d be happy to help.