Last edit for this document Mar 26 2005
Other Documents, links
Old computer newsgroups often discuss converting old CP/M systems from 8-inch and
5.25-inch floppy drives, to 3.5" drives and media. Issues raised included support of
FM or single density; finding old media; choices of formats. I decided these
discusssions were worth preserving, as these issues come up over and over. For
more technical information on floppy drives and floppy disks, go to
our technical page on floppy drives and media.
For specific discussions about converting from 8-inch, 5.25 inch, and 3.5
inch, look for links on this section of that page.
This document is currently:
http://retrotechnology.com/herbs_stuff/8inch_cctech.txt
The following is an edited version of a Feb 2005 discussion from the
"cctech" and "cctalk" maillists of classiccmp, on the subject of 3.5" drives as
replacement for 5.25" and 8-inch drives. This document (c) 2005 by Herb
Johnson, content from and edits with the permission of those posting.
The original posters retain their rights to their original posts.
Randy McLaughlin is continuing this discussion, and starting an effort to create
some standards, on a "disk drives" page
on his Web site.
Herb Johnson
Index
------
Randy and Herb debate issues
HD convenient but not compatible
FM, SD is OK for HD drives
300 RPM vs 360 RPM
Reading SD/DD disks, interpreting formats
Randy and Herb debate issues
----------------------------
Summary of exchanges Feb 1-6th
From: "Randy McLaughlin" (not indented with >>'s)
>> From: "Herb Johnson"
>> I think Randy is looking for a CONSENSUS, not a "quorum", but in any
>> event he is looking for an acceptable standard. He did not get a lot of
>> responses because 1) it's only been a few days, and 2) it's a
>> technically tough subject, and 3) it's an OLD subject over the years.
In fact I am hoping to put togather a quorum, I want a select group of
technically minded people to come together and have their own opinions and
ideas. CP/M on 3.5" drives exist. 3.5" HD media has technical issues that
are unique to it. If we can get a quorum then a consensus can be formed.
> Randy suggested in his comp.os.cpm posts that it's basically OK to write
> in single density FM format on 3.5" high-density (HD) media, as he says
> the "flux changes in FM and MFM" are at the same rate. For the oldest
> computers, FM is the ONLY format option you may have. I did not respond
> to Randy's post. But I think the problem of that scheme for use at 3.5"
> HD will be two-fold. First, the actual data rates of old single density
> FM 8-inch FDC's are much slower than standard data rates for HD 3.5"
> media; the same applies for the read/write electronics of the DRIVE.
[Herb's note: this became a non-issue.]
> 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 calls to mind a classic problem on IBM compatibles,
> namely reading old 5.25" 360K SINGLE density diskettes (like Osborne
> diskettes). The FDC chip and/or decoder does not "expect" an FM encoded
> data stream.
I agree that finding a PC that can handle FM is basically impossible for a
new off the shelf system, which is why I keep an old PC that does handle FM.
In this case it does not matter what drive and media is used if all you have
is FM then 3.5" FM is accepatble While you won't be able to use it on most
PC's that applies for any FM disk (3.5", 5.25", or 8"). Note I am not
recomending anyone stop using 8" I just am recomending standardizing how we
use 3.5" when we do use it.
>> One personal note. This took a few hours to write. It takes time to make
>> a good, technical "argument". It took time for me to complile all the
>> info on my site, and time for THOSE people who wrote it to do their
>> work. It does not take long to propose a popular idea, and it's fun;
>> it's less popular (and more work) to say "here's why it may not happen".
> [So,] Randy will have to wait for more than a few days to build
> whatever "consensus" or "quorum" or "select group" will construct his
> standards. And, a standard, or now standardS PLURAL (FM and MFM) will
> take some time and technical care to construct and VERIFY. Already, it's
> clear there would have to be at least two standards: one for
> single-density/FM only systems, one for double density. Oh, those older
> systems may need a single sided standard too...
I appreciate your comments, I agree that no standard is in site and may
never be agreed upon by enough people. I also agree we need Amardeep and
other to pipe in.
I expect a large base to fight using 3.5" media but I find that 3.5" media
is so much easier to deal with on a variety of levels. - Randy McLaughlin
> "Easy" does not make it possible. And explaining the technical limits is
> not "fighting". But there are other reasons not to put 3.5" drives on
> the oldest systems. One "reason" is more of a preference: to run systems
> with all original hardware, including the original 8-inch disks. Another
> reason, which I mentioned previously, is to make sure that your system's
> disks can be read and written by ANOTHER IDENTICAL system of the same
> brand and model. (You may get an offer of software from another owner of
> your brand & model of system; too bad you can't read their disks...)
> I think the problems of a set of "standards" for using 3.5" drives and
> media fall into two categories. First, the technical limits of the
> oldest systems. Already it appears that single density will need its own
> standard - that's one example of technical limits. Reliability is a
> technical issue also: if you use odd formats at odd data rates, you may
> not get reliable results. Like, using HD disks at DD formats: it may
> work, sort of. Second, the general issue of cross compatibility. When
> you use new disks on old systems, you'll have "funny" formats that will
> be very unique, to the point that NOBODY BUT YOU can read your disks.
> Backups that can be read by only one computer are not backups, when that
> computer dies. - Herb Johnson
From: Herb Johnson
Date: Feb 10? 2005
... a classic issue of design differences, is the fact that HD
and 80-track drives have heads which create thinner tracks. That's why a
disk formattted for 40 tracks on an 80-track drive may be UNRELIABLE
when read on a 40-track only drive. Thinner tracks means poor erase of
old thick tracks; and less signal when the thin track is read by the
"thick" head.
What I've heard over the years about uses of HD drives and media for
"earlier" formatting and controllers, suggests there may be problems at
least in the long term, as well as in the short term. Specifics, when I
come across them, I'll add to my site, and some of that information and
discussion is already there.
http://retrotechnology.com/herbs_stuff/drive.txt
This is why I believe it is better to keep older systems with original
drives and media whenever possible; or at least to make such drive
changes that are CLOSEST to original drives and media. Old drives and
old media are still available. New media and unused old stock are still
available with some searching. USed stock, by my experience, is often in
good shape if stored well and if bulk-erased.
HOWEVER some of the oldest diskettes like 8-inch do fail or perform
poorly - why is not clear to me. And old 8-inch drives can just wear
out, or fail and destroy media. It's a bad feeling when a disk drive
head SCRAPES UP A DISK to bare plastic. So the issue of replacment and
upgrade is a reasonable one. - Herb Johnson
HD convenient but not compatible
-----------------------------------
Date: Sun, 06 Feb 2005 15:11:29 -0500
From: Herb Johnson
I've recieved two comments to my [previous posts]. One [comment]
suggested that 3.5" HD diskettes are convenient to find and buy. That
may be true but 1) convenience does nothing if HD disks won't work; and
2) you can still find DD 3.5" diskettes for sale via the Web - just not
at your local stores.
Date: 10 Feb 2005
From: Herb Johnson
A Google search for '3.5" 800K diskettes' provided many sources for
unused old stock, and I think a few new stock. Prices ranged but some
were quite low.
But please note: I'm talking about whether HD media and drives will
ACTUALLY WORK RELIABLY on the "non-modern" hardware I described.
"Convenience" and "abundance" does not help if the disks don't work. As
for buying DD 3.5" diskettes, I understand the issue, I sell such disks
myself. But A Google search on 3.5" DSDD diskettes found a number of
suppliers, here and now. In any event, people who use and maintain old
hardware should not be surprised that there may be limits as to how far
they can upgrade, yet maintain compatibility and reliability.
Moving from 5.25" drives to 3.5" drives is less of an issue, almost all
of those earlier systems supported double density (MFM). But not all,
such as the original Osborne 1 with single density, singled sided 5.25
inch drives. There are still other issues with this change, but they can
be mananged for the most part.
A search of old comp.os.cpm archives will find prior discussions of all
this. Some of those discussions are archived on my site as I noted, some
data on drives and media are on my site.
Date: Sun, 06 Feb 2005 02:12:00 -0600
From: Doc Shipley
[It's] Not too bad [to find 3.5" DD media]. I troll ePay for them on and
off, and have bought about 350 disks in the last year, averaging about $0.40 shipped.
Tongue-in-cheek:
I might argue that it's easier to find viable DD 3.5" media than
viable HD media. All the new 3.5" floppies I've bought in the last
couple of years have had an atrocious failure rate.
All kidding aside, I don't see 3.5" HD floppies being "current" for
much longer either. And since AOL started distributing CDs instead of
floppies, the damn things are expensive. - Doc
FM, SD is OK for HD drives
--------------------------
Date: Sun, 6 Feb 2005 22:02:11 -0500 (EST)
From: Dan Lanciani
[Herb's note: Quotes of Dan Lanciani are as per his terms: quote:
"Again, my permission extends only to complete unaltered copies of my
comments. Anything else would have to be done on a case-by-case basis."
end quote. I choose to leave his remarks unaltered.]
|[Herb Johnson posted:]
|Randy suggested in his comp.os.cpm posts that it's basically OK to write
|in single density FM format on 3.5" high-density (HD) media, as he says
|the "flux changes in FM and MFM" are at the same rate.
More than that, a correct FM data stream is indistinguishable from a
correct MFM data stream that happens to have no clock bits since every
other "data" bit is "1".
|For the oldest
|computers, FM is the ONLY format option you may have. I did not respond
|to Randy's post. But I think the problem of that scheme for use at 3.5"
|HD will be two-fold. First, the actual data rates of old single density
|FM 8-inch FDC's are much slower than standard data rates for HD 3.5"
|media; the same applies for the read/write electronics of the DRIVE.
No, the rates are the same.
|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
Date: Mon, 7 Feb 2005 13:10:28 -0600
From: "Randy McLaughlin"
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
Date: Wed, 9 Feb 2005 16:31:08 -0500 (EST)
From: Dan Lanciani
[Herb's note: Quotes of Dan Lanciani are as per his terms: quote:
"Again, my permission extends only to complete unaltered copies of my
comments. Anything else would have to be done on a case-by-case basis."
end quote. I choose to leave his remarks unaltered.]
|[Herb posted:] You mentioned HD media, the thread subject is "HD drives", so I thought
|that was your proposed "standard". But it is more likely that 3.5" DD
|media and drive settings will work for FM/single density/8-inch systems,
|than HD.
No, a DD 3.5" disk uses a 250kb/s data rate just like a 5.25" DD disk. An
HD 3.5" disk uses a 500kb/s data rate just like all 8" disks. FM vs. MFM
is transparent to the drive (except of course that MFM requires twice the
temporal resolution of the flux transitions). An HD 3.5" disk will look
to an 8" controller much like an 8" disk with tracks that are 1.2 times
longer than normal. I expect it should be possible in many cases to use
existing formatting software unchanged to produce 8" formats on 3.5" HD
disks.
It was suggested that formatters would fail in attempting to produce 77/26/128
FM formats on 3.5" HD drives, but I'd like to know the details of the failure
modes. All the formatters that I'm familiar with check (if at all) only that
the index hole does not come around again before they finish. They do not
attempt to time the track to make sure that the index hole comes "soon enough."
I suppose it would be possible that some formatters give up on padding too soon
and note some sort of data underrun error. For such systems it might be
easier to use 5.25" HD drives which exactly mirror 8" track timing. It might
also be possible to get very unlucky and have garbage in the unwritten area
of the track look like valid sector headers, but this could probably be avoided
by bulk erasing before formatting.
|I think the problems of a set of "standards" for using 3.5" drives and
|media fall into two categories. First, the technical limits of the
|oldest systems. Already it appears that single density will need its own
|standard - that's one example of technical limits. Reliability is a
|technical issue also: if you use odd formats at odd data rates, you may
|not get reliable results. Like, using HD disks at DD formats: it may
|work, sort of.
Happily, there really are no "odd data rates" involved. Ignoring 2.88M
drives and the special 300kb/s rate used to read 5.25" DD disks in HD
drives without altering the motor speed, the controller technology has
remained largely unchanged. The 250kb/s and 500kb/s rates persist from
the earliest floppy controllers to the present. The drives themselves
have no notion of the higher-level aspects of the format, so track layouts
suggested by drive manufacturers can generally be taken as safe _maximums_
rather than required formats.
|Second, the general issue of cross compatibility. When
|you use new disks on old systems, you'll have "funny" formats that will
|be very unique, to the point that NOBODY BUT YOU can read your disks.
|Backups that can be read by only one computer are not backups, when that
|computer dies.
This is a problem, but it isn't really a function of the new drives. I've
had problems with 8" MFM/77/26/256 formats being incompatible between CP/M
systems even though I had thought that everybody agreed on the extent
parameters for such disks. As far as I can tell, FM/77/26/128 is the only
format for which most everybody agrees on the logical parameters (and I'll
bet there are exceptions even to that). I would think that if you were
going to do an 8" on 3.5" format, FM/77/26/128 would give you the best
compatibility bang for the buck. In the meantime, I'm not about to dump
my 8" drives. :) - Dan lanciani
Date: Thu, 10 Feb 2005 12:59:05 +0100
From: Bjorn Vermo
>> [Herb Johnson posted on 06 Feb:] Briefly, I posted that I doubt that
>> a single density (FM) only system, such as the earliest CP/M systems,
>> could read and write successfully AND reliably to HD diskettes. Also, I
>> suggested the consequences of an old system owner who converted to this
>> "standard" and then found that noone else could read his disks. In
>> short, for the oldest of systems, there may be good reasons to continue
>> to use old, but well-known, formats, drives and disk media. My Web site
>> has pages of technical info and articles compiled from previous postings
>> on these technical issues.
I had some experiences of this when early HD disks arrived. They could not
be reliably written on older drives because the write heads did not create
a sufficiently strong magnetic field. Reading was never aproblem.
Bulk erasing the HD disk, then formatting and writing was workable. While
the old drives were not able to erase something written by a HD drive,
they were able to write sufficiently strong bit patterns that they could
be read reliably. Actually, I think the flux in the read heads would be
just as strong as from an old diskette.
Different brands of diskettes will behave differently. I was doing my
tests back then with Rhone-Poulenc diskettes, which are probably not on
the market anywhere today. Modern diskettes also seem to be of lower
quality (and a lot cheaper) than in the eighties. -- BjA,rn
300 RPM vs 360 RPM
-----------------
From: "Sellam Ismail"
Sent: Sunday, February 06, 2005 12:21 PM
>> Here's a suggestion...
>>
>> The Epson PX-8 had 3.5" drives available as an add-on. The PX-8 was of
>> course a CP/M machine. Why don't you start by investigating what Epson
>> did?
Date: Sun, 6 Feb 2005 13:30:50 -0600
From: "Randy McLaughlin"
This is an example of missing the primary assumption:
The 3.5" drives used on most CP/M systems are driven at 250K MFM.
3.5" DD (125K FM, 250K MFM) are simple extensions of 5.25" 48tpi drives.
I am concerned about 3.5" HD (250K FM, 500K MFM). This environment has the
same transfer rate as standard 8" drives but it uses a different rotational
speed. This means that you can not simply extend an existing format.
One other point that keeps coming up is using 3.5" DD exclusively. Many
systems can not handle this data rate other systems would require hardware
modifications, another point is the storage would be 1/2 of HD.
For systems running 250K FM (8" single density) would normally use 26
sectors at 360 RPM, 32 sectors at 300RPM. This is the issue, given that new
formats are required. The question is can enough people agree what formats
are appropriate?
To me 250K FM would obviously be best to use 32 128 byte sectors even though
going by Teacs FD235HF manual you can use 18 256 byte sectors or 10 512 byte
sectors. This is the closest to the 8" SSSD standard available. - Randy
Date: Sun, 6 Feb 2005
From: Fred Cisin
NO. NO. NO. [to Sellam's suggestion of the Epson's PX-8 drive]
A very good idea, except,...
The Epson Geneva PX-8 disks that I have seen used a
67.5 tpi 3.5" drive (40 tracks per side).
THOSE drives are VERY hard to find.
"Normal" 3.5" drives are 135 tpi.
YES, you could "double-track" it, and introduce track width problems.
But, to use that otherwise good idea, consider other 3.5" CP/M formats:
CPT
Digitech
HP CP/M (77 track, but still 135tpi)
Jonos
Mountain Side MSC-ICO
NEC 8201
Netway 1500
Olivetti ETV-250
Sony M35 CP/M
Sony SMC70
XScribe
Reading SD/DD disks, interpreting formats
-----------------------------------------
[note: Dave Dunfield describes his work on reading SD(FM) and
DD (MFM) Osborne 1 and Cromemco CDOS 5.25" diskettes. His descriptions,
and the replies from participants, suggest the kinds of problems you may
have when you try to read "foreign" diskettes. - Herb Johnson]
subject: Osborne-1 SD format
From: Dave Dunfield
Sat Feb 19 09:37:22 CST 2005
Hi Guys,
Here's a question for the diskette gurus - I'm using my Osborne-1
Single-Density disks as an example, however I have observed this
with a number of different machines.
I would like to backup images of these disks - as they are soft-
sector disks, I was hoping I could use Teledisk.
Teledisk does read the disks, however it reports them as 5 sectors/
track, 1024 byte sectors, which doesn't seem right to me - if you
attempt to recreate a disk from the image, it is unreadable.
I thought Teledisk must be out to lunch, and not really likeing
the fact that it uses an undocumented image format, I've been
meaning to write my own replacement for some time.
This morning I wrote some simple test routines to check it out,
basically, just selecting the drive and data rate, recalibrating
and seeking the head, and issuing the READ-ID command to identity
the sectors and type on a track - with "pc" disks, the results are
correct, and exactly what I expected.
With my Osborne-1 single density disks, I can only read Id's with
MDM (ie: DoubleDensity) selected, and ... I read 5 sectors/track
(numbered 1-5), and they are reported as 1024 byte sectors -
exactly the same results that TeleDisk has been reporting.
In a HD drive, I must select a data rate of 300kbps, and in a DD
drive I must select a data rate of 250kbps in order to be able to
read them at all...
I've tried several systems, two of which have 37C65 controllers
with the dual (9.6 & 16Mhz) crystals, which are believed to properly
support single-density operation.
Can anyone tell me what is going on? Can anyone confirm the actual
diskette format of an Osborne-1 single-density diskette?
Why do they "appear" to read at [M]FM 1024 byte sectors (with correct
1-5 sector numbers/ordering)?
Regards,
Dave
subject: Osborne-1 SD format
from: Dave Dunfield
date: Sun Feb 20 10:08:09 CST 2005
"fred" posted:
>It would appear that your "single density" Osborne diskette is
>really a "double density" Osborne diskette.
>
>But there are a few other possibilities. I have seen quite a few
>single sided format diskettes that were reformatted from other
>double sided formats, leaving a readily readable different format
>on the back side.
Hi Fred,
Thanks for the info - It's interesting that a DD O1 disk would match
what I am seeing - I grabbed this disk from the faceplate bin of my
single-density O1, and I'm pretty sure that it was last formatted on
that machine - however evidence would suggest that I may be seeing
a DD disk - so I'll double check that I got it out of the right
Osborne (my other ones have the DD option), and that it does read on
that machine... Perhaps I have been engaging in the persuit of an un-
domesticated ornithoid!
In the meantime, I have been looking at a Cromemco CDOS disk (5.25"),
another disk that Teledisk cannot copy, and it is equally perplexing...
This disk has track-0 at single-density (both sides) and the remainder
of the disk in double-density.
It reads fine in my System-3, and I *CAN* read all of the sectors
from it on various PC's, however not reliably at all. They do always
show correctly that they are single-density on track 0 and double-
density on the remaining tracks (some PC's can't detect the single-
density sectors at all), however repeated read-id's on a track fail
to turn up all of the sector numbers, unless I let it go for a long
time. Even 50 revolutions of the disk will not always turn up all
the sector numbers (but they are there and will sometimes reveal
themselves - often different sectors are better on different PC's).
With a PC format disk, and most other DD disks, I can simply issue
a "read id" with the wrong data type - this times out at the index
hole after two revolutions, at which point I set the right data type
and perform repeated "read id"s until I see the same id again - on
most disks, this quite reliably gives me the sector interleave pattern
on the track.
With the Cromemco disk, this does not work, as often I won't see all
of the sector id's until I have reissued the "read id" many times,
often seeing some sectors 30-40 times before seeing one occurance of
the "tough" sectors. Clearly even if I do eventually get all the
sector Id's, I cannot determine what the interleave is at all..., not
to mention that this makes the "analysis stage" a but lengthy.
Repeated attempts to read all id's on a track will often/usually
turn up different sectors (but not all of them in one go).
Attempt to read these sectors will usually fail, but will sometimes
work - again, very unreliable.
Read-track appears to work, however I have not yet determined if it
is simply "missing" some sectors or not - since I don't know the
sector interleave, and read-track does not provide any information
about the order in which it ecountered the sectors (read-track seems
pretty useless on the 765 series).
This most interesting about all this (at least to me) is that the
symptoms occur on the double-density portion of the disk, as well
as the fact that it is intermittant (ie: not a complete
incompatibility) - Again, it looks like there might be something
slightly non-standard about the CDOS disk format... (anyone know?)
Regards,
Dave
from: Dave Dunfield
date: Mon Feb 21 12:38:57 CST 2005
subject: Osborne-1 SD format
It's interesting with the Cromemco CDOS disk - the DD area is formatted
to 10 512 byte sectors/track, and in the DD(360k) drive, I can't read
them at all - For this test, I pulled the actual Teac drive that I have
been using on the System-3 (which reads it fine) - it looks like the PC
controller has touble with the tightly spaced sectors.
It (the DD drive) can however read all of the SD sectors in track-0
just fine!
The HD drive reads the entire disk perfectly, EXCEPT for Sector-1 of
Track-0 (the SD track) - it quite reliably refuses to read the first
sector of the SD track. The remaining sectors of the SD track and all
of the DD tracks read OK.
So - I can read the entire disk, however I have to do it on two separate
drives - Unless I can reliably resolve these problems, I think I will
make an option in my disk imager to merge images read of different
drives - In some cases (like this one), it may allow a complete image
to be constructed where it otherwise might not be.
The :-( for the day is that it appears that NONE of the PC controllers
that I have will format a single-density track - I can recreate the DD
tracks just fine (Even with 10 sectors/track), but so far no joy on
formatting and writing that SD system track.
Regards,
Dave
subject: Osborne-1 SD format
from: Steve Thatcher
Mon Feb 21 15:33:24 CST 2005
At 01:38 PM 02/21/2005, Dave Dunfield wrote:
>... it looks like the PC controller has touble with the
>tightly spaced sectors [of the Cromemco CDOS disk].
a technical note...
This comment regarding tightly spaced sectors twinged my memory.
Anything based on the 8272/765 (in other words, all normal PC [FDC chip]
controllers) was not able to keep the "spacing" between sectors as small
as the Intel [bit] slice [based floppy controller] board did. Even the
1793 series was not able to handle this. I had started work on a DD
Intel ISIS controller back then and did a fair amount of research on
this back issue. The only controller chip I found that was capable of
doing both SD and Intel DD was a TI TMX99XX chip (the actual # escapes
me at this time). The chip had very good control of the bytes between
sectors and would have been able to handle the small spacing in the
Intel DD format. Not that this helps Dave's problem, but I figured I
would throw out the comment because it related in a way.
best regards, Steve Thatcher
Message: 5
Date: Mon, 21 Feb 2005 02:02:46 -0800 (PST)
From: Mike Stein
Subject: Cromemco CDOS format (was Osborne-1 SD format)
A little more about Cromemco disk formats, from my limited
knowledge:
In case it isn't obvious, the reason for the "non-standard"
format (was there a "standard" format in those days?) is to
be able to read/write all four formats interchangeably.
Track 0, side 0 is formatted to the lowest common denominator,
SS/SD, so all systems can read it no matter what the format of
the rest of the disk may be. At the end of sector 1 (78-7Fh)
it finds the format information for that disk (5" or 8",
single/double sided,single/double density, and CDOS or Cromix,
conveniently in ASCII, e.g. SMDSDD=SMall (5 1/4", CS if it's
Cromix) DS,DD. Then it can read/write the rest of the disk
accordingly.
Hard disks are handled similarly, although density is irrelevant:
The system finds the hard disk id at the same offset as on the
floppy, and the hard disk configuration (cylinders, surfaces,
sectors per track, bytes per sector and location of the alternate
track table) immediately preceding it; thus you can plug in any hard
disk with a compatible interface and the system can read the
geometry etc. off the disk by reading the first sector regardless
of the disk layout, since no hard disk will have < 128 bytes in
the first sector.
mike
Date: Mon, 21 Feb 2005 16:56:02 -0600
From: "Randy McLaughlin"
Subject: Re: Cromemco CDOS format (was Osborne-1 SD format)
Cromemco kept a text string in the first sector to specify what the disk
format was. If it was missing it was assumed to be 8" SSSD.
I was always disappointed that they used such a crude method. It is simple
enough to determine what the format is.
All they ended up doing was create disks with two different formats on one
disk.
I [should also] mention something very important about Cromemco systems:
They are very very picky about disk rotational speed.
I sent Gaby a shareware PC-DOS program I use (RPM), she posted it here:
http://www.gaby.de/edownl.htm
I use it for 3.5", 5.25", and 8" drives. It makes it a snap to adjust
drives. - Randy
Message: 8
Date: Mon, 21 Feb 2005 18:55:40 -0500 (EST)
From: Dan Lanciani
Subject: Re: Osborne-1 SD format
|Dave Dunfield:
|With a PC format disk, and most other DD disks, I can simply issue
|a "read id" with the wrong data type - this times out at the index
|hole after two revolutions, at which point I set the right data type
|and perform repeated "read id"s until I see the same id again - on
|most disks, this quite reliably gives me the sector interleave pattern
|on the track.
|
|With the Cromemco disk, this does not work, as often I won't see all
|of the sector id's until I have reissued the "read id" many times,
|often seeing some sectors 30-40 times before seeing one occurance of
|the "tough" sectors. Clearly even if I do eventually get all the
|sector Id's, I cannot determine what the interleave is at all..., not
|to mention that this makes the "analysis stage" a but lengthy.
[Dan Lanciani:] Try adding an increasing small delay after the read id you use to
synchronize with the index hole.
| Yeah, I tried that earlier on with mixed results, and didn't seem to
| really get anywhere - but I've cleaned up a few other things now, so
|I'll revisit it.
|(read-track seems
|pretty useless on the 765 series).
It is. Your best bet would be to get a 1797 family controller.
|Believe me, I've thought of that - problem is that I want to be able to
|send this to people to make disks - but it looks like the pee-cee controller
|(or the design) is just not up to snuff, and all I see a people having
|problems - single-density on a pc is very problematic.
|
|I've also toyed with the idea of building a very small embedded controller
|with a 1797, few tracks worth of buffer storage, and a reasonably fast serial
|link to the PC. This is basically what I am doing now to archive/restore North-
|Star disks (which are hard-sectored), except that since the N* controller
|is well defined, I can just put my code into any N* system (user supplied his
|uart routines).
|
|(or if you wanted to be super-flexible, have just a DSP - but thats a tad more
| software work than I feel like undertaking right now...)
|It's interesting with the Cromemco CDOS disk - the DD area is formatted
|to 10 512 byte sectors/track, and in the DD(360k) drive, I can't read
|them at all - For this test, I pulled the actual Teac drive that I have
|been using on the System-3 (which reads it fine) - it looks like the PC
|controller has touble with the tightly spaced sectors.
!Date: Mon, 21 Feb 2005 18:20:04 -0800 (PST)
!From: mhscc@canada.com
!
!mhscc@canada.com: Well, I've usually had no trouble copying files back and forth
!PC<>CDOS using Uniform with various standard PC controllers
!WD, Compaq, no-name).
!
!Of course I can't format track 0 side 0 on the PC (although the
!Compaticard might solve that problem) but if it's initially formatted
!in CDOS, no problems. If you subsequently ask Uniform to format the
!disk it skips track 0 side 0 and just formats the DS tracks. - mike
[Dan Lanciani:]
It has trouble with various kinds of back-to-back operations, but I
wouldn't expect that to make the tracks totally unreadable. Something
else is going on. Is it possible that the BIOS thinks you have an
80 track drive and is double-stepping? That would let you read track
0 but no other.
|[Dave:] I'm not using BIOS at all - I'm communcating directly with the FDC and
|DMA controller. It simply does not see Sector-1 on the SD track, almost
|all the time!
|It (the DD drive) can however read all of the SD sectors in track-0
|just fine!
|
|The HD drive reads the entire disk perfectly, EXCEPT for Sector-1 of
|Track-0 (the SD track) - it quite reliably refuses to read the first
|sector of the SD track. The remaining sectors of the SD track and all
|of the DD tracks read OK.
[dan:] Try covering the index hole cutout on the disk or otherwise blocking the
drive's index sensor. The controller does not like to start a read too
close to the index hole, but it will mostly work without any index pulses.
(It won't format or timeout of course.) - Dan Lanciani
|Interesting idea - I'll give that a try, at least it might shed some more
|light on what exactly is going on. -Dave Dunfield
Message: 9 Date: Mon, 21 Feb 2005 16:18:30 -0800 (PST)
From: "Dwight K. Elvey"
Subject: Re: Osborne-1 SD format
Hi Steve
As I recall, the M2FM also had a different sector header.
Unless you could program the header format, just the spacing
problem was only half the issue.
Dwight
Message: 18
Date: Mon, 21 Feb 2005 17:42:48 -0800 (PST)
From: "Dwight K. Elvey"
Subject: Re: Osborne-1 SD format
Hi Dave
Here is another idea. Most of these machines are designed
to have multiple drives. One disconnects one of the drives
and runs the wires to a simple board on the parallel port.
That board has maybe 5 or 6 TTL's. All it does is pass
serial data from the parallel port to the read data
and possibly the read clock of the controller on the
old computer. In the PC, you configure the port to
be in the DMA mode so that it can do high speed transfers.
The board has a simple clocking from a Xtal can oscillator.
Things like single and double density are simply the bit
stream information. This is all premade in the buffer that
you are doint the DMA transfer from.
I'm not saying I've worked out all the possible problems
but I think it can be done. Things like the data rate for
5-1/4 and 8 inch can be jumper selects on the board or
maybe even encoded in the data sent.
Anyway, it needs more thought
Dwight
From: "Eric Smith" Subject:
Re: Osborne-1 SD format
Steve Thatcher wrote:
>> all Intel did was to use the same basic 3270 format and double the number
>> of sectors to make the OS changes easy. The gaps between real data did not
>> get as big from SD to Intel's DD.
Intel made more changes than that. In addition to the use of M2FM and
and different gap sizes, the index mark, ID address mark, data mark, and
deleted data mark don't match standard FM or MFM. The gap and PLO sync
bytes are different as well.
It's documented in the disk controller manuals. For instance, see
pages 4-25 through 4-31 of the iSBC 202 manual:
http://bitsavers.org/pdf/intel/iSBC/9800420A_SBC202hwRef_Sep77.pdf
Or pages 1-4 through 1-11 of the Intellec Double Density Diskette Operating
System Harndware Reference Manual:
http://bitsavers.org/pdf/intel/MDS2/9800422_M2FMdskCtl_Jun79.pdf
DEC, on the other hand, really did just subsitute a slightly modified
MFM data field for the FM data field on their RX02 disk system. The
details are in the RX02 Floppy Disk System Tecnical Manual, pages 1-10
through 1-14:
http://www.chd.dyndns.org/rx02/ek-0rx02-tm-001.pdf
Eric
Message: 19
Date: Mon, 21 Feb 2005 18:10:56 -0800 (PST)
From: "Dwight K. Elvey"
Subject: Re: Osborne-1 SD format
Hi Eric
I'm almost sure that the headers of the sectors have something
different in them as well. I recall looking at it and thinking
that it was just something else that needed special handling.
Dwight
Message: 30
Date: Tue, 22 Feb 2005 06:34:14 -0500 (GMT-05:00)
From: Steve Thatcher
Subject: Intel DD format differences
make that 3740 format... as for the marks, yes they are different and I don't recall that being a problem with the TI controller I was looking at (I have one of them, but my data sheet to go with it has been lost...). the headers (other than the ID address mark being different in value) contain the same number of bytes in the same order. Intel's format had 0 in the byte location (third byte) that said which side it was supposed to be (in other words side 0) and they had 0 in the location that defined the sector length (fifth byte - 1 for 128 byte sectors). Unless Intel did the CRC different, these should be the only differences. Eric, the gap and PLO sync bytes are in the DD system 34 format. They are not in the 3740 format that I was talking about. best regards, Steve Thatcher