6

Back in the day, SCSI was the way to go. I remember my high school having a single 5Mb Sider hdd connected to an Apple //e - which seemed awesome after endlessly swapping floppies. Not long after, I lusted for and purchased a 20Mb Xebec 9710 (or 9720?) for my Amiga 1000.

More recently however, I've managed to acquire two First Class Peripherals Sider hard disks for my Apple //e, and a Xebec 9710 to pair with my Amiga 1000; but before I start connecting and terminating and formatting and troubleshooting and pulling out my hair, etc. I wondered what might still be lurking on these drives.

Conveniently, I also have a working Pentium III with both Jaz and Syjet drives connected via a Buslogic FlashPoint SCSI card. So I started to think it might be possible to connect the Sider/Xebec drive(s) one at a time to the Buslogic card via the external connector and (assuming the drives still work, and the termination is correct, and drive id doesn't conflict) I might be able to 'query' the drives in some fashion. This of course leads to my question, would it be possible to actually 'detect' what file system the drives were/are formatted with?

I'd hazard a guess the Sider drives are probably formatted for use with ProDOS? - but the Xebec drive could potentially be anything. It might be interesting to do some detective work before trying to flatten the drives and start over. It's a long shot, but you never know what kind of history you might find lost on a seemingly random drive from 30+ years ago.

Speculating, I suspect if this is possible it would require a version of Linux (maybe a bootable CD like Knoppix) because I doubt Windows 98 and or MS-DOS is going to get me very far.

Is what I am asking even possible?

Improve this question
2
  • 1
    If the drive is visible under Linux (or BSD), you can take an image of it with "dd" and use "file" to try if it can detect what it contains or open it in a hex editor to see anything.
    – Justme
    Nov 21, 2020 at 19:52
  • And if file or binwalk doesn't do the job, do a hexdump -C. See if you can find ASCII text, and inspect the first sector closely, if you have experience in how those things look like (or acquire experience by reading it up, and looking at real world examples) one should be able to identify quite a few variants.
    – dirkt
    Nov 22, 2020 at 18:14

1 Answer 1

Reset to default
14

Yes, this is possible.

The file utility can recognise many disk partition layouts and file systems. If you connect your drives to your Pentium III system, running a version of Linux, they should appear as /dev/sd? devices. To simplify further analysis, you should copy their contents to a file:

sudo ddrescue /dev/sdX backup.img backup.map

(replacing X as appropriate), then file backup.img will tell you what you have.

This uses ddrescue which will allow as much data as possible to be recovered from marginal drives; the map file allows rescue attempts to be interrupted, resumed, and analysed (using ddrescueview).

Once the data is copied, you can chown the backup file to your regular user, and use other tools to analyse the backup.

Improve this answer
7
  • 2
    Probably you can just do file /dev/sda, and for each partition, file /dev/sda1 etc
    – Lorraine
    Nov 21, 2020 at 20:10
  • 3
    binwalk too can identify many more things in a disk image than plain file can
    – lights0123
    Nov 21, 2020 at 20:30
  • 1
    I'd be really surprised if cp worked on a device file. I'd think you need dd
    – JeremyP
    Nov 21, 2020 at 21:21
  • 1
    @OmarL you’d need file -s /dev/sda, and /dev/sda1 etc. will only be meaningful if (a) the drive has partitions and (b) the Linux kernel knows about the partition table in use (which I doubt would be the case for an Apple IIe drive). Copying to a file before analysing it means that the analysis can be done without privileges and that the drives can be put to use in their target systems while the analysis is ongoing.
    – Stephen Kitt
    Nov 21, 2020 at 22:08
  • 2
    I always recommend ddrescue for these situations because, on the off chance that the drive is so marginal that it's going to die, you're already using the tool optimized to read as much as possible A.S.A.P. before retrying the problem zones. It's a good habit to get into. ...plus, it you specify a log file in your ddrescue command, you can interrupt, resume, and retry the process as many times as you want, building on previous reads, and there exists ddrescueview to visualize progress similar to a Windows defragmenter GUI.
    – ssokolow
    Nov 22, 2020 at 14:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .