SyQuest-ered: Two 44Mb Cartridges Stacked with Directors & Projectors

It seems data recovery and conversion has become a little side-hobby of mine, and the lack of recent postings is because I’ve been quite busy working my magic on another set of patients.

I was contacted by Prof. Dan Boyarski of the School of Design at Carnegie Mellon University (Pittsburgh, PA, USA) back in late-March this year about helping out with recovering student work stored on SyQuest cartridges from the early to late 1990’s. Despite my willingness in principle, at the time, I was no longer able to help due to a lack of functioning SyQuest equipment, so the plans were put on hold as I simultaneously worked with another reader who generously contributed the necessary equipment to me.

Once the other project was well and truly done, I contacted Dan again as of 30th June to let him know that I was ready to process his cartridges, provided they were posted to me, the media was still in good shape, and the software would co-operate. Thanks to his efficiency, merely days later on the 4th July, the cartridges arrived for their operation.

The Cartridges

The cartridges arrived quickly and safely via Fedex. The novelty for me is that this is the first time I’ve handled 44Mb cartridges. I’ve only handled 88 and 200Mb cartridges to date, so I can add another one to the “list” of things I’ve handled.


The design of the box and insert are basically the same as the 88Mb cartridges I’ve seen, just with 44Mb on the front instead. This one had a silver label stuck on it proclaiming a 5-year warranty. I believe there was a different design of the outer card with white text for the capacity as well.


Again, nothing new from the back either, with a copyright date of 1991 on the package. The barcode label is still affixed to the outside, with a UPC code of 742078405010.


The spine doesn’t seem to reveal anything new, but I suppose at the time, this would have been one of the most useful pieces of kit around when internal hard drives still were commonly 20-120Mb for workstations, having a 44Mb removable drive with equivalent speed would have been amazing.


From the outside, the catridge was practically identical to that of the 88Mb sans the label and the red write-protect wheel, instead of the yellow used in the 88Mb and the beige used in the 200Mb cartridge.


There were no changes on the underside either.


The spine stayed the same as well, and had a space for labelling which could be read while the drive was in use.

Because the two cartridges were practically identical, I didn’t photograph the other cartridge. That being said, the label on the second cartridge was in worse shape and was peeling at the edges – I taped it down to stop it from lifting when in the drive, otherwise there could be paper dust left inside which would not be good.

Step 1: Physical Recovery

The first step, as always, is the physical recovery. This means reading the stored data off the disk in its entirety – literally taking a full image of every user-accessible sector so as to be able to make a complete clone of the original cartridge. By doing this first-up, we minimise our time spent with the cartridge in the drive (reducing wear on the drive and the cartridge), and we eliminate the risk of things “failing” as we spend long periods on working with the files. Old equipment is fragile, and time is always ticking, as magnetic media slowly weakens and loses its magnetic orientation, this is always a first priority even if we’re not interested in immediately attending to the data on the cartridge.

Right as I was unboxing the cartridges, I was already booting up the recoverybox, a “half-old” machine caught-in-between generations that had the necessary PCI slots to work with the SCSI card which would talk to the SyQuest drive. Debian Linux was the operating system of choice, although any Linux will suffice as long as it has GNU DDrescue available. This is a free and very robust data recovery tool.


Within four minutes, I had an image of both cartridges with no errors whatsoever. This indicates the cartridges (and the drive) were in excellent health, and that the data is now secured. The “weak link” of the cartridge and the drive is no longer a factor in the continued recovery of the files.

In case you were wondering, this is what reading out a cartridge sounds like – a 44Mb cartridge is a little different from the others, with a louder “clicky” seeking between tracks, compared to the larger capacities.

At this stage, the raw images were archived into a ZIP file and electronically delivered as “raw copies” of the cartridges.

Step 2: Image Analysis

The next step was to analyze the disks. Because I do not own the data, I will speak generally about the data contained and the technical aspects, but not the contents of the data.

To analyze the data, I fired up my BasiliskII emulator with a System 7.6 image which I had made using HFVExplorer to create a virtual hard drive and installing from floppy images. This allowed me to mount the SyQuest images and examine them as if I had a “physical” Motorola 68k Mac to play with. I also had a SheepShaver emulator installation with a System 9.0.4 image which was installed from a CD image, to emulate a higher-performance PowerPC Mac. These emulators are not flawless – they crash frequently, they have compatibility issues from time to time, and require some settings tweaks to get things to work, but they’re the closest thing I have to a Mac of the time, without being chained to the limitations of period correct hardware. After all, I’ve dealt with all of these recoveries but don’t actually use a Mac at all.

As it turned out, the first disk contained solely PICT files, which was simple as no data conversion was necessary. You merely have to double click on the image file to mount the disk, and then view the PICT files using Preview or Photoshop, etc. The file format was robust enough to survive through to the present time, although I would still probably convert it to PDF or something else more modern and robust, as PICT is very much a “Mac” native format.

The second disk was more of a challenge, with a mix of files identified (type code and maker code):

  • APPL/PJ93 – MacroMind Director Projector files
  • APPL/MMPB – MacroMind Projector file (old)
  • MV93/MD93 – MacroMind Director files (newer v.3 format)
  • VWMD/MMDR – MacroMind Director files (older format, pre v.3?)
  • APPL/FISH – Hypercard Stack (creator code customized to reflect the stack author)

There were also AIFF audio files which are still accessible today, used as assets within one of the projects.

For those who aren’t aware, Director was a piece of software (originally conceived as VideoWorks) for creating interactive multimedia applications. It was originally created by the MacroMind company, which later became MacroMind-Paracomp after a merger with Paracomp, which then became Macromedia after merging with Authorware. Since then, it had been acquired by Adobe Systems, and mostly “left out in the cold” receiving very little care and support with Adobe Flash taking most of the market instead.

Of course, in order to access the Director files, one must have (MacroMind/Macromedia/Adobe) Director installed. In cases where it isn’t installed, a player could be used to view them and a copy of an early MacroMind v3 player was included on the disk which was good. However, many desired to make the files self-executable without the hassle of loading a player, then loading a project, so they instead compiled the player with an optimized copy of the project in a file known as a Projector. This is an executable file that plays the project, and that’s it.

The first step was to see if the Director files opened under Adobe Director (modern versions). I grabbed a copy of Adobe Director 11.5, but it would not install on a “Hackintosh”, so I actually had to borrow a real Mac to test it out. As for Adobe Director, it had a habit of not even allowing files to be selected (VWMD/MMDR):


If we do some changing of the file-type of either Projectors or Directors to say MV93/MD93, they can be selected, but still …

appl-pj93-errorOf the whole disk, only the one MV93/MD93 type file was open-able and directly convertible to the latest Adobe Director format, and exported as a Projector for both Windows and Mac (although the Mac one will not execute on Yosemite or above without option-click and Open due to code-signing requirements).

Unfortunately, other files were not as simple – as Projector files are executable “Classic” applications, they require the Classic environment which was depreciated after MacOSX 10.4, and not available for any Intel-Mac. There was also another file that was a compiled Hypercard stack that is also a Classic environment app.

Step 3: Data Conversion

Because of the previous discovery that the one MV93/MD93 type file was able to be converted, I first focused on the Director files and getting them from VWMD/MMDR to MV93/MD93 type.

From, I obtained a copy of Director 6.0, being the latest version available. After some fiddling, I got that into my emulator, but it wouldn’t open the files, complaining that they were too old.

As a result, I also had to obtain a copy of Director 4.0, which allowed me to update the files to Director 4.0 format:

Update-Movies-to-4The updated files had MV93/MD93 as their file type, so I mounted the hard disk image on MacOSX and tried to load them in Director 11.5:

mv93-md93-v4-error… which promptly failed. As a result, I was sort of back to square one. The lightbulb moment came seconds later, when I realized that I should probably do an incremental upgrade, and upgrade from 4.0 to 6.0.


This produced a file of type MV97/MD97, which Director 11.5 happily could deal with.


From there, it was possible to save updated Director project files, and create modern versions of Projector files that should run under modern PCs. Unfortunately, one needs to pay attention to bundled assets, as I wasn’t able to embed them properly within Projector files, so they need to be copied along to ensure the actual output works.

While this works for the Director files, the majority of the files were Projectors, and the solution was not so clear.

My first thought is that the Projector files might just be Director files with a header – a small stub application that plays it back. Examining the files in a hex editor didn’t reveal an obvious file signature or common “stub”, and in fact, it looks like the player has been compiled in with optimized memory chunk positioning, etc.

I tried searching for a solution to unpack the Projector files back to Director files, but everything I found was a dead end. A suggestion to use go movie “” only works for Director files, and any tools to unpack Projector files leads to dead ends.

The final solution was one that was least desirable but probably sufficient – to play the Projectors and film the output using a screen recorder. For this, I had the option of using a hardware screen recorder, or screen recording software. I opted to use the latter, because hardware screen recorders generally capture in compressed formats with chroma subsampling which will result in “smeared” edges and generational loss when edited. The small performance impact of the screen recorder software will be offset by the “very sharp” pixel-accurate output.

As I’m a bit of an “old-hat”, I used Camtasia Studio to record the screen with the audio looped back using Virtual Audio Cable, unpacking the .camrec files with 7-Zip, and editing the .avi files using VirtualDub. Finally, the exported .avi files were encoded using x264 with QP10 and tune for Animation, to ensure the sharpest compressed .mp4 output, compatible with most players.


This generally worked quite well, although it was time consuming and resulted in interactive files turning into “walkthrough” videos. The above frame was from a project by Lydia Ricci (used with permission).


Unfortunately, not all projects were co-operative, at least, under SheepShaver and System 9. I preferred to run projects on this emulator, as sound works well, and with JIT/DR enabled, it is much faster allowing for “real-time” emulation. Spurious errors turned up which imply a critical system error, potentially due to flaws in emulation. Other times, projects failed to quit and “hung” without explanation.

more-crashesOther projects did occasionally behave strangely with the time way-off. To combat these issues, it was necessary to restart the emulator after a few Projectors had been played, or when strange results were experienced. The reasoning is likely that the older Motorola 68k code within the Projectors did not expect a 32-bit clean system and may have used the upper bits for their own flag usage, which conflicted with real RAM in the emulator (as JIT/DR will only work for emulated 512/1024Mb RAM settings).

emucrashOne project had a tendency to crash the emulator outright, and eventually, despite all troubleshooting (i.e. turning JIT/DR off, ignoring illegal memory accesses), it came down to needing to run that particular file under BasiliskII under System 7.6 where it worked flawlessly, albeit a little slowly.

picky-modesAs a sign of the times, the compiled Hypercard stack didn’t understand “thousands of colours” or “millions of colours” and steadfastly refused to run unless 256 colour mode was selected. That was easily done through Apple Menu > Control Panel > Monitors.

Another nice option for System 9 emulation is to turn off the Control Strip entirely through the Control Panel – this stops the little “icon” from appearing in the corners of your screen-recordings.

My Conclusion

On the whole, things went quite well. The media was stored well, and was not a challenge to read-out with the right equipment, making physical recovery a breeze. The software side of things was a little more complicated, where old versions of software needed to be hunted down and worked on until they would install into emulated machines. For work like this, sites like prove to be invaluable, as does a little bit of “brain work” and data gymnastics. The Projector and Director files themselves had their own quirks, and the Projector format proved to be irreversible, hampering a “no-loss” conversion to a modern format and necessitating execution on an emulated Classic environment. This comes with the potential for non-realtime execution, graphical glitches and strange behaviour.

However, all things considered, when creating videos of the output of the emulator by screen capture, it produces a “robust” ISO/MPEG-4 video which is likely to outlive any executable file or proprietary format file for longevity while reaching much higher levels of compatibility. The thing that is lost mainly is the interactivity. However, having access to the data in some way, is much better than looking at a binary blob and not being able to appreciate it, even if imperfectly.

The whole process took a matter of a few days for me to hammer out all of the logistics, file-types, versions of software, and plan of attack. Given the resources available to me at present, I don’t think there’s much I could have improved on, as some of the resources which may have been formerly available to attack these issues have turned into dead-ends as link-rot consumes resources from the early internet.

So if you have copies of old Director 3.x projects, the plan of attack is to upgrade them to Director 4.0, then Director 6.0, then to Director 11.5 (or whichever version you have available). This multi-step upgrade path is required because of the “break” in version upgrade compatibility within the Director app itself. If you don’t have the source Director project, then you are left with the final (less desirable) option of playing it in an emulated environment and screen-recording it.

If you have a Syquest 44/88/200Mb 5.25″ disk that you would like explored, my offer of a free (optional donation to cover time) data recovery and data exploration/conversion still stands – contact me directly if interested. All you have to do is post the cartridges to me, with no expectation of return, and I will do my best for you and return the data to you electronically (no liability accepted).

Response from Prof. Dan Boyarski

After two years spent searching for a solution to recovering digital files from old SyQuest disks, I was about to give up and dump the disks, when I happened upon a blog post by Gough Lui. That was in early March, 2016. I wrote to Gough, telling him of my needs and my willingness to wait till he was finished with current work. He contacted me in late June and in a few days, I FedEx’d two SyQuest disks to him. In a matter of a couple of days he received the disks and extracted the data, and in another two days had results and MP-4 files to send me. Viewing those “kinetic typography” pieces from 1994 was mind-boggling, as I had given up hope of ever seeing them again. (Adobe, take note!)

Our work to recover other Director projector files continues and I’m confident he’ll perform as professionally as he’s done to date. If I had three words to describe Gough Lui, they would be: knowledgeable (he really knows his stuff and if not, he knows where to go for answers), thorough (details don’t elude him), and responsible (he treats the files with respect and I fully trust him). This young man is as adventurous a problem-solver as I’ve seen and it’s that willingness to try other options when the first one fails that led him to recover and breathe new life into these dormant files. I’m forever grateful!

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.

5 Responses to SyQuest-ered: Two 44Mb Cartridges Stacked with Directors & Projectors

  1. Natalia Portillo says:

    Applications on Mac OS resided on the “Resource Fork”, so most of that kind of “an application that just shows a single document” just contained the data in the “Data Fork” (only fork existing outside Mac OS). For example a self-extracting zip will be the same zip file in Data Fork, datatype as Application, with the extraction code in the Resource Fork.

    Some others, very rare, copied the document to the resource fork (storing it in a resource whose type was usually the same type as their document type) and added the application resources. These are very rare because the size of a single resource entry is limited to 64Kbytes afaik.

    In any cases, ResEdit can interpret most known resources, hexedit the resource and data fork, and change the file types.

  2. cheapie says:

    I wrote this “SCSI Tools” thing mostly for my own personal use, but you might find it interesting:

    It’s mostly just a frontend to some other tools, so it expects lsscsi, lsblk, sginfo, smartctl, badblocks, sg_raw, fio, and gnome-disks to be present. It’ll run without those, but some functionality won’t work. It also expects at least some knowledge of SCSI, especially of the “START STOP UNIT” and “FORMAT UNIT” commands.

    Please note that the default device name is /dev/sda, so it’s rather easy to accidentally clobber your boot drive if it lands there. You can edit line 11 to change the default if you want, or remove everything between the quotes if you don’t want a default at all.

    It’s written in Lua and expects to be run as root, so you’ll likely want to run it with something similar to “sudo lua scsitools.lua” (or whatever you saved it as).

    Once it’s running, use option 1 to select a drive. If you want to hot-add a drive, use option 98 first to rescan the bus for devices. You can then use the other options to start/stop the drive, check if it’s ready, view the defect lists, view SMART data, format the drive, check for bad sectors, benchmark it, open gnome-disks (automatically restarts udisks2 first to reset its device list), or even prepare the drive to be removed from the system.

    For starting/stopping drives (“START STOP UNIT” command, option 3), it allows individual control of the START, LOEJ, and IMMED bits. For formatting (“FORMAT UNIT” command, option 6), you can specify custom values for CMPLIST, FOV, DPRY, DCRT, STPF, and IMMED.

    Keep in mind that I wrote this over the course of just a few hours. While I can’t find any major bugs in it, I have only tested it on my hardware, and on Debian sid. As such, there may be undiscovered, possibly even destructive, bugs. Also, as with any program capable of manipulating disks, user error has the potential to cause major data loss. As such, I highly recommend that this program only be run on machines that do not have any drives with valuable contents attached. Anything even remotely important should be backed up prior to use as well. I, of course, provide absolutely no warranty as to any of its behavior or lack thereof.

    That said, anyone that finds it useful and wants to redistrubute/modify/etc. it may do so as allowed by the Unlicense (

    • lui_gough says:

      Thanks for the message and the tool – I’ll take a look into it, although seeing as I’m quite comfortable with the command line tools, it looks more of a convenience factor I suppose.

      – Gough

    • cheapie says:

      I’ve done a bit more work on it, and the following new features have been added:
      * IP (Initialization Pattern) support
      * DLIST support (specifying additional bad sectors at format time, not even sg_format can do this)
      * REASSIGN BLOCKS command support
      * PREVENT ALLOW MEDIUM REMOVAL command support
      * Probably some other stuff I forgot

      The new version can be found here:

  3. This appears to be a really old post and I’m not entirely sure what about, but it appears that you were trying to get the movies out of a Director Projector. It is true that a Projector is just an executable on top of a movie file, although the movies are annoying to extract out of the Projectors since the addresses in them are all relative to the beginning of the executable, rather than the beginning of the movie, so you can’t just copy paste them out. I’ve written my own little utility in NodeJS to get around this in fact.

    Also, the Windows version of Director will load movies made on the Mac, if for whatever reason you ever run into this situation again.

Error: Comment is Missing!