Any way to identify disk type from flux?
#1
I'm working on saving some old source code and data from back in the day and some of the disks are 'unknown' as to what system they were written from (which, in turn, makes it tricky to figure out what's on them).  Any ideas how I might narrow the possibilities?

A lot of the software was for the Atari 8-bits, but there's some some C64 and Amiga as well, maybe Atari ST (we supported 'em all at various times).  Earlier versions were definitely Atari, but my Atari drives won't read the later version floppies... I vaguely remember having cross compilers (well, assemblers) involved, possibly on a PC, but it could have been on a C128 or something else.  It also blurs together with all sort of other stuff we were doing back then, so I'm just not sure anymore.  Any suggestions for an (easy-ish) way of telling what's what?

Thanks!
-Clay
Reply
#2
There is no single super-easy way to do this. Especially since even a single "standard" computer system could often have multiple oddball formats (often for different OSes, formats that squeeze more space out of a disk, or copy protection)

The easiest way at the moment is probably to view SCP or Kryoflux dumps under the HxC disk tool. It will automatically find and decode sectors from multiple encodings (FM, MFM, CGR, and of various sector sizes) and you can compare those to known formats. It shows you all of this information in a nice pretty series of graphs and plots. If the data it finds is in a format that it supports, you can save it directly to an emulator image file.

A couple of bugs though, the HxC tool often crashes or hangs on images with gibberish in blank/unused tracks, often treats 40-track 2 sided SCP images as 80 track single sided, doesn't handle images with "flippy" data in them, and I think there are still some formats or encodings it doesn't recognize.

Another tool I have found useful are the PCE emulator tools (PRI, PFI, and PSI). They are command line tools, and much harder to use, but they are much more flexible, can find and decode any arbitrary sized sectors, and are great for automatically decoding images. However these tools are geared more for use with FM/MFM encoded disks.
Reply
#3
You can use SuperCard Pro's editor/analyzer and select between GCR and MFM. It's really easy to determine ISO-PC (IBM) disk format - that will always be MFM and have two sets (within close proximity) of three 4489 sync marks in a row, per sector. Amiga disks are typically 3.5", not 5.25". Those have one set of two 4489 sync marks, per sector. Anything made on 3.5" is going to have either Amiga or ISO-PC format.

C64 format is GCR, and uses a series of five FF's in a row for syncs. Atari format is typically FM.

You can always make an image file of the disk and send it to data@cbmstuff.com. I can tell you what format it's in.
Reply
#4
(10-04-2015, 08:16 AM)admin Wrote: You can always make an image file of the disk and send it to data@cbmstuff.com.  I can tell you what format it's in.

I'll take you up on that offer!  I tried the HxC tool, but I'm not sure if I'm using it right-- when looking at known FM images in an Atari-like format (40 track/18 sector/SS) the track viewer didn't seem to show any decoded data, but I notice that there's a distinct lack of Atari 8-bit support in that tool too, so maybe it's just not its forte.

I'll email a compressed image-- the disk is labeled 'DD' and should be Atari software, but none of the DD drives I have recognize it.  IIRC, Atari's XF551 was DD but not the same as the DD units from 3rd parties, so that's a possibility.  Or it could be a a PC disk for all I know. I remember 5.25" drives on our Atari ST's for sure (PC Emulator/file exchange) and since this was pretty late in the game for 8-bit stuff, who knows if they were cross-assembling on something else or just transferring and taking advantage of the higher disk capacities for backup...

Thanks!
-Clay
Reply
#5
Your disk image is a single sided, double density MFM format. It is not index'd, which leads me to believe it is a SSDD Atari 400/800 disk. ALL ISO-MFM formats except the Atari 400/800 are index'd (unless otherwise deliberately not index'd for copy protection). So, I don't think this was an ST disk - but it definitely uses the same 4us/6us/8us (double density) format - but so does the TRS80, TI-99/4A, and a slew of other ISO-MFM based systems.

The HxC tool shows the sectors decoded correctly for a MFM disk. I just don't see any type of ASCII data that is common when looking at decoded data.
Reply
#6
Atari disks XOR all of their data for some weird reason.

I'm not familiar with Atari disk hardware, but there are both FM and MFM formats. As I recall, the MFM formats also use 128 byte sectors, which most PC disk controllers (even the ones that support FM) can't handle in MFM mode (Some Adaptec ISA SCSI cards with the National Semiconductor FDC instead of the Intel FDC can read that). And to make things weirder, they don't use or don't have to use the index pulse, which trips up PC FDCs because they won't read any data that occurs during the index.

Anyway, HxC or the PCE Tools should be able to save the decoded data to an ImageDisk IMD file. Although HxC is likely to barf if the disk is "flippy" because it sees the back side as junk, and SCP doesn't want to read a single side only. There is a tool out there called "imd2atr.exe" that can then convert the IMD image to an Atari emulator .atr format.
Reply
#7
(10-04-2015, 01:14 PM)SomeGuy Wrote: Anyway, HxC or the PCE Tools should be able to save the decoded data to an ImageDisk IMD file. Although HxC is likely to barf if the disk is "flippy" because it sees the back side as junk, and SCP doesn't want to read a single side only. There is a tool out there called "imd2atr.exe" that can then convert the IMD image to an Atari emulator .atr format.

Thanks for the help!  I'll monkey around with the tools mentioned above. Looks like I need to get a DJGPP environment working to build imd2atr.

Jim's assessment would make *sense* (being that it's in with all the other Atari format source code disks and is labeled DD) and it's possible it was written with an XF551 drive which is why none of my 3rd party drives will read it.

Thanks again for the assistance.

-Clay
Reply




Users browsing this thread: 2 Guest(s)