The term "computer archeology" has two meanings. One meaning is the art of using computers in archeology. But that's only because they haven't found a computer in a dig--yet. Here, we're using the term in the way such science fiction writers as James P. Hogan and Vernor Vinge use it: the art of recovering data from defunct, possibly alien, computers.
This article explains how to recover data from an Atari ST hard drive, using PC hardware, Linux and a bit of care. The effort benefits from two design decisions the Atari ST designers made that show the benefits of open standards. First, the Atari ST can use a standard SCSI I hard drive with an Atari-specific host adapter. Second, the ST uses 12-bit FAT filesystems, so I did not have to develop a filesystem driver. Linux's open architecture, open-source nature and excellent native development tools would have made it the ideal platform for such a project.
The target hardware consists of a 234MB Quantum ProDrive LPS hard drive (large in those days) originally connected to the Atari by an ICD host adapter.
Recovering the data from the hard drive was easy. I already had installed a SCSI host adapter on a PC. All I needed to do was check the SCSI address of the hard drive, add it to the SCSI cable and provide power. Upon firing up Linux, I found the hard drive associated with a device file in /dev. As I already had two other SCSI drives on the computer, the Atari drive showed up as /dev/sdc. So far, so good. The first thing to do was read the master boot record to make sure I was accessing the correct drive. In UNIX, everything is a file, even memory (/proc/kcore), so I was able to get the data from the hard drive with a one-line command:
dd of=table if=/dev/sdc bs=512 count=1
Examining the file table in Emacs' hexl mode (Listing 1) convinced me I was in the right place. The first several bytes are 68,000 instructions which make an operating system call, not the Intel 808x CLI and branch instructions one would expect in a PC MBR. (See the LILO and/or GRUB documentation for the gory details of a PC MBR.) Listing 2 shows a partial Forth disassembly (in Forth's Reverse Polish notation) I later made of the MBR. Second, the word GEM, the name of the Atari graphical user interface, or GUI, shows up in the region where the partition table should be.
Convinced I was in the right place, I copied the entire hard drive to a file:
dd of=quantum if=/dev/sdc bs=512
That gave me a file image of the hard drive. Now I could shut down, remove the Quantum hard drive from the PC, put it back in its static-free bag and boot to Linux.
One problem with the Atari ST is that hard-drive partitioning, if done at all, had to be done by a driver specific to the host adapter. Unfortunately, this means that every host adapter provided a different partitioning scheme. Fortunately, back when this Atari ST was my active machine, Mike Yantis had reverse-engineered the ICD partition table and had written code in Forth to access the table. I had ported his code to my Atari, and it was in a file on the hard drive. So, I had to recover the partition table so I could read the file that has the code I need in order to recover the partition table. Great.
There is, however, a workaround. I tried reading the entire hard-drive image into that great programmers' Swiss Army Knife, Emacs, but Emacs balked at the size of the file. So I made a copy of the first 64MB:
dd if=quantum of=test bs=1024 count=61440
I loaded that into Emacs, switched to hexl mode (M-x hexl-mode) and searched for the word "partition". That didn't work. I tried the same thing with the next 64MB:
dd if=quantum of=test bs=1024 count=61440 skip=61440
That file contained the code I needed. I now knew the layout of the partition table: each entry was twelve bytes long. The first one, for C:, started at an offset of 454 (0x1C6) bytes. It was followed by three more. The entry for G: started at 342 (0x156), and it was followed by five more partitions. The ICD partition scheme could support up to 13 partitions, but I never used more than 10, so that was as far as my code went.
There are no extended or logical partitions here as there are in PC MBRs; thanks, Murphy. Whoever named them logical partitions had a vicious sense of humor; they aren't.
Each partition table entry consists of the following:
A byte of binary data. At a guess, bit 7 may indicate this partition is to be booted, while bit 0 says it has a valid filesystem.
Three characters of text indicating, possibly, the filesystem or OS that uses the partition. The Atari used the string "GEM". There is no zero termination in this field.
A four-byte value (in 68000 byte order, which also happens to be in network byte order) indicating the location of the first sector of the partition. As SCSI drives are addressed in a strictly linear fashion, a simple sector number is sufficient. As with IDE's LBA addressing mode, cylinders, heads and sector manipulations are internal to the drive.
Another four-byte value indicating the size in sectors of the partition.
|Jarvis, Please Lock the Front Door||Aug 31, 2016|
|Contrast Security's Contrast Enterprise||Aug 30, 2016|
|illusive networks' Deceptions Everywhere||Aug 29, 2016|
|Happy Birthday Linux||Aug 25, 2016|
|ContainerCon Vendors Offer Flexible Solutions for Managing All Your New Micro-VMs||Aug 24, 2016|
|Updates from LinuxCon and ContainerCon, Toronto, August 2016||Aug 23, 2016|
- Jarvis, Please Lock the Front Door
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Contrast Security's Contrast Enterprise
- illusive networks' Deceptions Everywhere
- Happy Birthday Linux
- All about printf
- New Version of GParted
- What I Wish I’d Known When I Was an Embedded Linux Newbie
- Tech Tip: Really Simple HTTP Server with Python
- Blender for Visual Effects
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide