Using 3.5" HD drives on CP/M systems

From: Randy McLaughlin <randy_at_s100-manuals.com>
Date: Mon Feb 7 13:20:08 2005

I accidently clicked on reply which sent this to cc-talk, I am reposting to
cctech.

From: "Dan Lanciani" <ddl-cctech_at_danlan.com>
Sent: Sunday, February 06, 2005 9:02 PM
<snip>
> |Second, no "modern" computer which uses 3.5" 1.4M drives is likely
> |CAPABLE of reading an FM encoded (single density) data stream, except by
> |accident.
>
> This is certainly a problem, at least for modern PC-class machines. Not
> only do recent integrated Intel floppy controllers fail to support FM mode
> but they have never had a read-track command which can sometimes be useful
> to read FM data in MFM mode. When I wanted to back up a large number of
> old single-density 5.25" disks that use a non-standard format I had to
> employ a machine with a WD1797, reading the FM tracks in MFM mode and
> bit-banging the result. Even that wasn't reliable because there is no
> way to guarantee that the controller exposes the correct bit slots without
> data marks. (The 1797 has a 16-bit shift register but passes every other
> bit to the host.) I had to add a circuit to double-up the pulses in the
> raw read data stream so that either alignment of the shift register would
> be correct. Of course, if the disks used a standard format I would have
> been able to read them in FM mode without all the trouble.
>
> In general, I don't think it is possible to come up with a scheme that is
> wire-compatible with old FM controllers yet produces media that can be
> read by "modern" PCs with MFM-only controllers that lack a read-track
> command. Given that, I suggest that a SS/SD/77/26/128 format on 3.5"
> disks
> might be the most useful standard for those wishing to replace physical 8"
> drives. Beyond that you might as well use whatever non-standard format
> you
> used on 8" disks. Keep in mind that tracks/heads/sectors/size is still
> not enough information to fully specify a CP/M disk format because vendors
> set up the extent mappings differently. I think I even came across a
> DS/DD/77/26/256 8" format that was logically incompatible with my system
> (until I DDT'ed the BIOS) even though I had believed that everyone was in
> agreement about this "base" double density mode.
>
> Dan Lanciani
> ddl_at_danlan.*com

Another problem with older systems that have mixed FM & MFM where the system
tracks may have the 1st track always FM or both system tracks always FM.

For me being able to read or write the disks from a PC would be a plus but
not the only reason to go with 3.5".

The biggest plus are for those people that need a drive, if they have no
working 8" drive they are able to use their systems.

Another point is that if they only have one 8" drive and are unsure about it
using 3.5" drives can be useful for testing.


SS/SD/77/26/128 format is non-standard for 3.5" drives which use 300 RPM.
The slower RPM means that most formatting programs do not work. Teac states
that for 128 byte FM sectors the track should be formatted with 32 sectors.
Of course the disk can be formatted physically as DS/SD/80/32/128 and just
ignore the second side and the last 6 sectors per disk.

I highly recommend staying with physical formatting schemes published by the
manufacturers of the drives.


I agree that while I've only been talking about the physical formatting
scheme that is simply a starting point, if no one can agree on how many
bytes per sector there is no reason to go further.

I personally slightly prefer two physical formats for 3.5" HD media: 32 128
byte FM sectors for each track and 18 512 byte MFM sectors. This just keeps
the PC standard formatting for MFM and specifies the simplest formatting
scheme for FM.


I also recommend starting the data area on the third track even on systems
like the Imsai Series Two's SuperIO that does not boot from the boot tracks.


So far one person with an extremely strong CP/M back-ground has strongly
suggested 1K sectors for MFM.


Randy
www.s100-manuals.com
Received on Mon Feb 07 2005 - 13:20:08 GMT

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:37:36 BST