22 Mar
2017
22 Mar
'17
4:42 p.m.
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.