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.

2016070413047963

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.

2016070413047964

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.

2016070413047965

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.

2016070413057966

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.

2016070413057968

There were no changes on the underside either.

2016070413057967

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.

ddrescue-recovery

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):

file-selection-greyed

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 MacintoshGarden.org, 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.

update-to-6

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

update-to-11d5

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.

single-frame-projector-playback

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).

finder-type10

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 MacintoshGarden.org 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!

Posted in Computing, Tech Flashback | Tagged , , , , | 1 Comment

Quick Review: Arduino/Genuino 101 Board

I was lucky enough for element14 to send me a little surprise “care package” just last week. As it turned out, it contained a Genuino 101, the latest release from Arduino. This board has been slated to be the “next Uno”, featuring an Intel Curie SoC that contains an ARC core and a Quark (x86) core clocked at 32Mhz, along with onboard IMU containing an Accelerometer and Gyroscope and onboard Bluetooth Low-Energy radio. It features 3.3V I/O with 5V tolerance, and the same connector layout as the Uno.

2016061513327811

You can read the quick review over on my blog at element14 here.

Posted in Electronics | Tagged , , | Leave a comment

Power Bank Endurance Test – Hillo Power Jin Gangxia (Part 14)

Almost two years ago, I started an experiment to see just how well a random no-name power bank would survive under repeated cycling, and to chart its “demise”. While I had some notion that it might have failed early due to its unknown heritage, and some other preconceptions that it might conform to the 300-500 cycle “rule of thumb”, the reality had been quite different.

The cycle experiment continues, with the 14th installment of results representing a cumulative cycle count of 700 since the experiment had begun, or 716 since new.

Results

effective-capacity-graph27From the last report, the trend seems to be holding mostly steady, with a post-rest downward trajectory that is slightly steeper and mostly “holding” along the trajectory. However, the past ten cycles or so have seen a slight “bump” occur where the capacities have trended upward slightly, but still within my margin of error of ~100mAh. This may be potentially related to the recent cold weather being winter, but is probably just a temporary deviation. The capacity lows and highs are still roughly headed downwards, although the mean capacity is still about 100mAh above the 80% “failure” point.

effective-capacity-graph28

We can see on zero-scaled plot just how much capacity remains, and how much is lost.

Conclusion

The experiment continues, with another report to be posted in 50 cycles. The resilience of the power bank is rather astounding, for it indicates the cells, as well as the connectors, charging IC, etc are all functioning well with so many cycles despite the “average” looking design. I’m surprised my test-rig didn’t break either, although I suspect connector wear may have caused some increased variations in readings due to connector resistance.

I think this goes to show that lithium-ion/lithium-polymer cells aren’t strictly going to fail based on a high cycle count alone, and can outlive the “rule of thumb” 300-500 cycle count. They likely accumulate damage due to poor charge/discharge protection, as well as ageing and storage. Regardless, their mode of failure is reported to be increasing internal resistance, indicating the inability to service and sustain high load currents. As power-bank currents are relatively modest by comparison to other loads, it likely indicates that cells in such situations may last considerably longer than expected.

It also lends credence to the whole idea of using Li-Ion chemistry for electric vehicles, and once unsuitable, using them for stationary power situations where larger bulk and weight is not a problem, and having racks of them can reduce instantaneous peak current demands to something the packs can still handle to eek more life out of them.

Posted in Electronics, Power Bank | Tagged , , , | Leave a comment