Extracting files off “unknown” 8 inch disks. Any thoughts…

[Fred Cisin]

On Thu, 23 Mar 2017, Terry Stewart via cctalk wrote:
> Guys in the building next door to me (a Science lab) have found some 8 inch
> floppy disks.  They want to see what’s on them, or at least to archive
> them.  They have no idea what machine these disks were used with, or the
> software was used to write the files.  They may be CP/M, or some other
> format entirely.
> Anyway, has anyone else faced this kind of challenge and what are your
> thoughts?  I don’t want to start unless I at least have some chance of
> success.  I’m not hopeful.  The more I read the more you seem to need real
> forensic skills and something like Kyroflux that works at low-level.

How much work are you willing to put into it?

I used homemade tools to read and display sectors, but
you can accomplish quite a bit with whatever tools you have.

The PC is a relatively known quantity, and easy enough to work with.
Your CP/M machine, unless you are real lucky and it's the same or 8" SSSD, 
is going to be a little harder, until you know what FDC your CP/M machine 
uses, at what addresses, etc.


On machines with a Western Digital disk controller, such as TRS80 
(try using Trakcess), it is possible to do a TRACK READ, and look at that.  On 
machines with a flux transition board (kryoflux, catweasel, Central Point 
Option board), you can look at the raw image of the track.


On the PC, try to read a sector.   Even an MS-DOS DIR command gives some 
clues.
If you get BIOS error #2 (Address Mark not found), then you have the wrong 
density or encoding.

If you get BIOS error #4 (Sector Not Found), then you've got the right 
density.  That means that it sees what it recognizes as being sectors; 
they just aren't the one that you asked for.

If it is SD (FM) then SOME PC FDCs can read it, some not.
If it is DD (MFM) and 128 bytes per sector, then some PC FDCs can read it, 
some not.
If it is DD (MFM) and not 128 bytes per sector, then most PC FDCs can read 
it.
If it is MMFM, GCR, or something else, then PC FDC can not do it.  But a 
flux transition board (kryoflux, catweasel, etc.) might be able.

With 22Disk, XenoCopy, ImageDisk, etc. try various formats.  You MIGHT get 
lucky, particularly if it is 8" SSSD, but assuming that you don't 
get instant success, looking at what errors you get, you may be able to 
ascertain the bytes per sector, based on which formats don't balk at 
reading a sector.

If it happens to be 512 bytes per sector, then you can write some minor 
code with INT13h to read sectors.
If it is not 512 bytes per sector, then you will also need to hit INT1Eh.


Once you know the bytes per sector, check for the number of sectors per 
track.  There will only be a few possibilities for any given sector size.
Check whether any sectors are readable on the second side of the disk.
You can normally tell whether it is single or double sided by the position 
of the index hole on the disk, but there are some exceptions.

Watch out, that some disks number sectors from 0, some from 1, and some 
have special numbering, such as numbering from 81h or having an invalid 
value in the head number field of the sector header (particularly on the 
second side).  (All of which could give you BIOS error #4, but not error #2)


Once you can read sectors, the very first sector is always interesting. 
It will typically contain the bootstrap loader, which often has a text 
message to display!


Start looking for what might be the directory.
On MS-DOS, that will USUALLY start in the first track, with a boot sector, 
FATs, then directory entries.

On CP/M, it will USUALLY be in the first 3 or 4 tracks more often on the 
first side, but not always.

On "Microsoft Stand-Alone BASIC", it will be near the "seek center".
Don Maslin once sent me copies of sectors near the middle of an NEC 8" 
disk.  It was surprisingly easy to calculate from their content which 
sectors would contain each file.

You may not find a recognizable or decipherable directory, in which case, 
you copy every sector, and start by looking for any strings of text.
If no text, then look to see if any of it makes sense as machine language 
of whatever processor might be in the source machine.

Be aware that a few disk formats, such as Superbrain, invert all of the 
bytes of each sector.



Once you've got sectors, speak up, and we'll give you more things to look 
at.