Subject: RE: 8" floppy system needed to recover old game data
From: "Kieron Wilkinson" <Kieron.Wilkinson at paretopartners.com>
Date: Thu, 06 Oct 2005 13:59:35 +0100
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at
classiccmp.org>
My reasons for suggesting doing a track dump is so we can leave figuring
out the filesystem later... Which from my experience of other systems
means it is less likely we would get it wrong "on the day". It is bad
enough getting this done once, twice would not be too fun either. ;)
But of course, CP/M is not exactly part of my previous experiences.
CP/M file system is fairly easy to understand. It was fairly standardized
depite media variations. A dump of any form would be reconstructable
if there are no lost sectors.
For 8" systems they fell onto two major groups:
Hard sector: Altair and a Zilog used those. However _most_
hard sector 8" systems rarely carried CP/M.
Soft sector: Most common and there was a standard interchange format
for CP/M. That was 8" single sided single density (8"SSSD).
Other formats that existed were CP/M on Intel (M2FM) and
Odd sector sizes or double density. Likely formats in
the 8" realm were fortunatly fairly few (likely one of 5).
The two most common after SSSD was SSDD (single side
Double density) and DSDD (double sided double density).
The latter two SSDD was often seen and had a fairly similar
layout compared to SSSD. The DSDD was far less common and
there were a few different ideas how data should be laid down.
FYI: the M2FM (intel MDS) used conventional 8" drives but the FDC was really
The 5.25 worlds was chaotic as drive were developing and people needed to
push those minifloppies from the base of only 80k to a more useable 360
or even 780k. Where the base 8"SSSD was 256k from day one.
A "photocopy" of a disk is possible
using (MS)DOS, if you can
find a MicroSolutions Compaticard IV (I have one, and no, I
dont want to part with it).
This card works very well; I once generated a bootable MS-DOS
3.1 (or 3.20?) 8"
floppy.
Nice.
The only (in my opinion) good solution, is
software reading
the CP/M (or
whatever) disk, and decode the filestructure etc., so you can
write a nice, continuous file.
Absolutely, my only concern was getting that wrong. But perhaps it is
far simpler operation to work out the file system with CP/M than getting
a track dump the disk, in which case this method is probably more
appropriate.
Of course one reason (off topic!) to dump the whole disk (down to the
flux-transition level) is to ensure you get absolutely everything on the
disk. But of course, this is only really useful for retail software that
might have applied copy protection - not really applicable for a
developers old development system! :)
Thanks!
Kieron
============================
Pareto Investment Management Limited is a Mellon Financial Company. Pareto Investment
Management Limited is authorised and regulated by the Financial Services Authority (Firm
Ref. No. 416024), and registered in England and Wales with Number 03169281. Registered
Office: Mellon Financial Centre, 160 Queen Victoria Street, London EC4V 4LA, United
Kingdom. Pareto is the registered trademark of Pareto Investment Management Limited. This
message may contain confidential and privileged information and is intended solely for the
use of the named addressee. Access, copying or re-use of the e-mail or any information
contained therein by any other person is not authorised. If you are not the intended
recipient please notify us immediately by returning the e-mail to the originator and then
immediately delete this message.