10 Jun
2014
10 Jun
'14
1:47 a.m.
As far as I know there wasn't any "standard" CP/M 8-inch double-density
disk format, with many vendors doing their own, incompatible formats, but
was there any reason to prefer any one of those formats over any other? If
I hack my own BIOS, I can obviously do it however I want, but it seems like
it might be nice to be compatible with something.
The Quay boot ROM wants track 0 head 0 to contain eight 1KB sectors, but
since I'm hacking my own boot ROM anyhow, I'm not necessarily tied to that.
10 Jun
10 Jun
8:47 a.m.
On 06/10/2014 01:47 AM, Eric Smith wrote:
As far as I know there wasn't any
"standard" CP/M 8-inch double-density
disk format, with many vendors doing their own, incompatible formats, but
was there any reason to prefer any one of those formats over any other? If
I hack my own BIOS, I can obviously do it however I want, but it seems like
it might be nice to be compatible with something.
The Quay boot ROM wants track 0 head 0 to contain eight 1KB sectors, but
since I'm hacking my own boot ROM anyhow, I'm not necessarily tied to that.
A quick survey of my library shows the 26x256 (IBM System/34) was a
common format, particularly among Japanese CNC makers. 15x512 and
8x1024 are also common. And there's the occasional 9x1024 and 17x512.
However, I do recommend that you not go with 128-byte MFM sectors--NEC
765-based controllers have a real problem with those due to an internal
bug. And do remember to include an IAM.
Other than that, remember that a larger sector size will require a
larger in-memory blocking/deblocking buffer. If you intend to equip the
unit with a hard disk, it's probably prudent to use the same sector size
on both floppies and fixed disks.
As to the logical organization of those sectors, there seemed to be no
consistently-used single one.
--Chuck
13 Jun
13 Jun
12:58 p.m.
On Tue, 10 Jun 2014, Eric Smith wrote:
As far as I know there wasn't any
"standard" CP/M 8-inch double-density
disk format, with many vendors doing their own, incompatible formats, but
was there any reason to prefer any one of those formats over any other?
Well, my personal preference is 8 x 1024, or 15 x 512 (which makes life a
little simpler for interchange with systems that require extra work to
switch out of 512 byte sectors).
But, in 1979?, I asked Gary Kildall what he would recommend as a standard
format for 5.25". He replied, "The standard format for CP/M is 8"
SSSD."
I tried, with NO success to convince him that because DS, DD,
and 5.25" WERE going to happen, that specifying secondary standards
(DS, DD, 5.25" SSSD, 5.25" DS, 5.25" DD, 5.25" DSDD) would go a
long ways towards preventing a situation of thousands of mutually
incompatible formats. He politely made it very clear that he had NO
interest in creating secondary standards.
"The standard format for CP/M is 8" SSSD."
--
Grumpy Ol' Fred cisin at xenosoft.com
1:31 p.m.
On 06/13/2014 12:58 PM, Fred Cisin wrote:
Well, my personal preference is 8 x 1024, or 15 x 512
(which makes life a
little simpler for interchange with systems that require extra work to
switch out of 512 byte sectors).
What, not 48x128? (There were systems that did that).
And sectors/size per track completely avoids how the data is logically
organized among those sectors.
Sector interleave (i.e. physical->logical equivalence), cylinder/side
ordering (e.g., one side then the other in reverse) have provided me
with endless hours of amusement. Oddball cylinder and side skewing are
fun in particular.
Where does the directory go? (e.g. the middle of the disk) How do you
order allocation units from there? (e.g. first, cylinders above the
directory, then cylinders below--or alternating above/below)
How about the boot tracks? If your controller can handle unity
interleave, why not speed up the cold boot process by avoiding any
interleave on those tracks?
How about your allocation unit size (e.g. absurdly large)? Directory
size (e.g. absurdly small)? Full or half-full directory entries (in an
attempt to keep 128 128-byte logical sectors as the limit for a single
directory entry).
Figuring the number of sectors and size of those on a track is only a
very small beginning.
CP/M in practice distinguished itself by the incredible number of disk
organization variations.
--Chuck
2:37 p.m.
> Well, my personal preference is 8 x 1024, or 15 x
512 (which makes life a
> little simpler for interchange with systems that require extra work to
> switch out of 512 byte sectors).
On Fri, 13 Jun 2014, Chuck Guzis wrote:
What, not 48x128? (There were systems that did that).
Yeah, but NEC FDCs weren't always happy!
And sectors/size per track completely avoids how the
data is logically
organized among those sectors.
Yes, there are both PHYSICAL format, and LOGICAL format (use of the
sectors). Even the physical format can be more that just bytes per sector
and sectors per track. Some formats, such as even Kaypro, put invalid
numbers in the head number field (although fortunately, MOST that did that
did not choke on disks that had been formatted elsewhere with correct
values), and sometimes sector numbering was not the same front and back;
0 - 9 on one side and 10 - 19 on the other was not a bad idea on systems
that switched sides before incrementing the cylinder.
And, of course, a different physical interleave could make an enormous
improvement in performance on systems that could not process a sector
before reaching the next sector.
Sector interleave (i.e. physical->logical
equivalence),
that could provide the interleave necessary while still keeping the
physical sector numbers in sequential order. At the expense of the
confusion that physical sector number 2 was NOT the next sector to be used
after physical sector number 1.
In terms of PREFERENCE for designing a new format, I prefer that
interleaving, IF needed, be done by the physical sequence, with no
translation involved.
cylinder/side
ordering (e.g., one side then the other in reverse) have provided me
with endless hours of amusement. Oddball cylinder and side skewing are
fun in particular.
and there are some doozies!
Many formats that started off as SS, and then added on a DS variant
continued to use the entire first side before starting on the second side
(in various different directions and starting point).
Again, PREFERENCE calls for, if designing DS from scratch, to increment
head before incrementing cylinder. It is faster, and keep more of the
data in unfilled disks in the more reliable outer tracks.
Where does the directory go? (e.g. the middle of the
disk) How do you
order allocation units from there? (e.g. first, cylinders above the
directory, then cylinders below--or alternating above/below)
Directory on middle tracks is based on the assumption that it is faster to
get there than to an outer track (or god-forbid an inner track for
directory). For going to the directory from a RANDOM track, that would
seem correct. BUT, 1) it is often not truly random, or 2) more
importantly, some drives can seek to track 0 faster than they can do the
number of steps to get to the directory (average of 1/4 the number of
cylinders of the disk if the data is distributed randomly) 3) at least
for the earlier floppies, there was enough difference in reliability of
outer V inner tracks to make it desireably to put the directory in outer
track(s).
BUT, again, as PREFERENCE for a CP/M format, the norm (not necessarily
REQUIREMENT) for CP/M was to have boot/system tracks starting at 0, then
directory, then data. If this is a CP/M format being designed, let's
stick with the canonical organization, even if we COULD create something
absolutely unique.
How about the boot tracks? If your controller can
handle unity
interleave, why not speed up the cold boot process by avoiding any
interleave on those tracks?
If the interleave is handled by physical sequence, rather than
translation, that is easy to manage.
How about your allocation unit size (e.g. absurdly
large)? Directory
size (e.g. absurdly small)? Full or half-full directory entries (in an
attempt to keep 128 128-byte logical sectors as the limit for a single
directory entry).
Not to mention whether you want to add any optional extensions.
Figuring the number of sectors and size of those on a
track is only a
very small beginning.
Yep!
I was only talking about the first layer of physical format.
CP/M in practice distinguished itself by the
incredible number of disk
organization variations.
. . . and the possibilites for everybody to have a unique standard of
their own!
--
Grumpy Ol' Fred cisin at xenosoft.com
4:43 p.m.
On 06/13/2014 02:37 PM, Fred Cisin wrote:
. . . and the possibilites for everybody to have a
unique standard of
their own!
You really couldn't blame folks for devising their own formats. DRI
certainly offered no guidance whatsoever, so unless you wanted to copy
someone already in existence, you did the best you could.
For example, I figured that it would be convenient to tell single-sided
formats from double-sided (drives were introduced later, but it was
inevitable that they would appear). So I started single-sided sector
addresses with 128--and double-sided with 192. That way, no matter
where you were on the floppy, a simple Read ID would tell you what you had.
My hat is off to the OEMs who worked out rotational and head latency
(complete with settling times) when reading from successive
sectors/sides/cylinders and then devised their interleave scheme around
that.
A lot of OEMs didn't like the idea of dynamically allocating files block
by block as done by CP/M. I've seen several systems where files are
pre-allocated with the option of freeing any unused space.
I guess CP/M, like MS-DOS, is what it is and folks just figured out how
to press it into service.
--Chuck
16 Jun
16 Jun
2:32 a.m.
On Fri, Jun 13, 2014 at 5:43 PM, Chuck Guzis <cclist at sydex.com> wrote:
For example, I figured that it would be convenient to
tell single-sided
formats from double-sided (drives were introduced later, but it was
inevitable that they would appear). So I started single-sided sector
addresses with 128--and double-sided with 192. That way, no matter where
you were on the floppy, a simple Read ID would tell you what you had.
Clever. Since I'm apparently not going to try to be format-compatible with
anyone else for 8-inch MFM, I may as well do that. For 8-inch I could
assume that double-sided media is always formatted double-sided, but I may
as well allow for formatting a single side of a double-sided medium. For
FM I'll only support single-sided (on either single- or double-sided
media). I suppose I'll try the MFM read ID first, and an FM read ID if
that fails, to optimize for the "native" case rather than the interchange
case. It's too bad that the controller isn't capable of formatting a disk
with one small FM sector on a track that is otherwise MFM. I could
certainly hack up something to do that, but I really want the machine to be
able to format its own disks without needing a hardware mod.
I'm vaguely considering a format with eight 1024B sectors and one 512B
sector per track (68 logical sectors). That would have the drawback of
breaking the alignment of allocation blocks to physical sector boundaries,
except that I could put the "extra" sector at the end of even tracks, and
at the beginning of odd tracks. (Or, for double-sided, at the end of
tracks on side 0 and the beginning of tracks on side 1.) Taking into
account skew, the physical position of the "extra" sectors on the tracks
might vary.
I only need one reserved track, so I can put the directory at the start of
track 1. Hmmm... maybe I should tell CP/M that it's 154 tracks of n
sectors rather than 77 tracks of 2n sectors, so that I truly only need one
reserved track, and not a whole reserved cylinder.
9:29 a.m.
On 06/16/2014 02:32 AM, Eric Smith wrote:
I'm vaguely considering a format with eight 1024B
sectors and one 512B
sector per track (68 logical sectors). That would have the drawback of
breaking the alignment of allocation blocks to physical sector boundaries,
except that I could put the "extra" sector at the end of even tracks, and
at the beginning of odd tracks. (Or, for double-sided, at the end of
tracks on side 0 and the beginning of tracks on side 1.) Taking into
account skew, the physical position of the "extra" sectors on the tracks
might vary.
Why not 9x1024? It can be done--I just processed a few disks done just
that way. I don't recall if you mentioned the controller used in the
Quay, but formatting dissimilar-sized sectors on a track is a pain in
the neck for the NEC 765; easy on a WD 179xx though.
I only need one reserved track, so I can put the
directory at the start of
track 1. Hmmm... maybe I should tell CP/M that it's 154 tracks of n
sectors rather than 77 tracks of 2n sectors, so that I truly only need one
reserved track, and not a whole reserved cylinder.
CP/M doesn't care--you'll note that the BIOS interface has "set track"
and "set sector" dispatch points, but no "set side". I've seen
formats
where only *part* of a track was used for holding the boot
information--it's all in the address-translation code.
Secondly, consider keeping your directory on a single track--it makes
things faster. I've even seen code where the directory track is
interleaved differently from the data tracks (clever BIOS writers!).
Another thing to consider is doing track-at-a-time I/O. If you have the
memory, it really can speed things up, particularly if you're using a
1:1 physical interleave.
--Chuck
2:37 p.m.
On Jun 16, 2014 10:38 AM, "Chuck Guzis" <cclist at sydex.com> wrote:
Why not 9x1024? It can be done--I just processed a
few disks done just
that way.
Can you really cut the gaps short enough to do that reliably? I'd expect
to need really tight motor speed control.
I don't recall if you mentioned the controller
used in the Quay,
uPD765A
but formatting dissimilar-sized sectors on a track is
a pain in the neck
for the NEC 765;
Yes, probably more hassle than it's worth.
easy on a WD 179xx though.
Most everything is easy on those. Except formatting a disk with certain ID
field values betwen 0xF5 and 0xFF.
Another thing to consider is doing track-at-a-time
I/O. If you have the
memory, it really can speed things up, particularly if
you're using a 1:1
physical interleave.
The machine only supports 65KiB of RAM (64KiB DRAM and 1KiB SRAM), so that
would seriously reduce the TPA size.
3:26 p.m.
On 06/16/2014 02:37 PM, Eric Smith wrote:
On Jun 16, 2014 10:38 AM, "Chuck Guzis"
<cclist at sydex.com> wrote:
Can you really cut the gaps short enough to do that
reliably? I'd expect
to need really tight motor speed control.
On an 8" drive, I don't think it's a problem. At any rate, Digital
Group, Octagon and Wave Mate used the 9x1024 track layout. I'd be more
concerned with an early (belt-drive, open-loop tach) 5.25" drive.
Most everything is easy on those. Except formatting a
disk with certain ID
field values betwen 0xF5 and 0xFF.
Just get yourself a WD1781 and pick whatever address mark set suits you.
Not very easy to find those--WD had problems with them and dropped
them from the 1984 databook. I've still got a couple--very useful if
you want to do something like MMFM or other nonstandard encoding.
And the 765 is even less tolerant than the 179x when it comes to address
marks (and layout).
The machine only supports 65KiB of RAM (64KiB DRAM and
1KiB SRAM), so that
would seriously reduce the TPA size.
Ah, too bad--setting aside 9K for a track buffer might take a too-large
byte, but maybe not. To bad there's no bankswitching hardware in your box.
--Chuck
5:42 p.m.
On Mon, Jun 16, 2014 at 4:26 PM, Chuck Guzis <cclist at sydex.com> wrote:
I don't mean changing the address mark. If you want to format a disk with
a 177x/179x with sector numbers in the range of 0xf5 through 0xff, you're
going to have problems. Even the 1781 has that problem. The 765 doesn't.
On an 8" drive, I don't think it's a
problem. At any rate, Digital Group,
Octagon and Wave Mate used the 9x1024 track layout. I'd be more concerned
with an early (belt-drive, open-loop tach) 5.25" drive.
OK, I'll give it a go. Are there recommended gap lengths for that format
Most everything is easy on those. Except formatting a disk with certain ID
field values
betwen 0xF5 and 0xFF.
Just get yourself a WD1781 and pick whatever address mark set suits you. I've still got a couple
I know where I can get some. I've always wanted to try to use that to read
DEC and Intel M2FM formats.
Was there any published app note or the like for the 1781?
6:19 p.m.
On 06/16/2014 05:42 PM, Eric Smith wrote:
OK, I'll give it a go. Are there recommended gap
lengths for that format
I just calculate the gaps out. It's very straighforward. I could check
some of my samples and see if you're really interested.
I don't mean changing the address mark. If you
want to format a disk with
a 177x/179x with sector numbers in the range of 0xf5 through 0xff, you're
going to have problems. Even the 1781 has that problem. The 765 doesn't.
Oh, I gotcha now. About the closest I've seen are some Molecular
formats using 242 (F2) as a head number. Still, the WD does have a
neat feature that if the track data doesn't contain any of the
"reserved" values, you can format and write in the same rev. That
didn't come about in the 765 family until very late in the family.
I know where I can get some. I've always wanted
to try to use that to read
DEC and Intel M2FM formats.
It might be nice to have a couple of spares.
Was there any published app note or the like for the
1781?
As far as I know, just the data sheet (what I worked from back in the
day. The 1771 app notes were helpful to get the general drift of
things). I don't think the chip was ever very popular--and it had an
annoying habit of hanging without any reason, so we had to implement a
control register with a "reset" bit.
--Chuck
13 Jun
13 Jun
4:26 p.m.
But, in 1979?, I asked Gary Kildall what he would
recommend as a standard
format for 5.25". He replied, "The standard format for CP/M is 8"
SSSD."
I tried, with NO success to convince him that because DS, DD,
and 5.25" WERE going to happen, that specifying secondary standards
(DS, DD, 5.25" SSSD, 5.25" DS, 5.25" DD, 5.25" DSDD) would go a
long ways towards preventing a situation of thousands of mutually
incompatible formats. He politely made it very clear that he had NO
interest in creating secondary standards.
"The standard format for CP/M is 8" SSSD."
What would you expect from someone who turned out IBM? :)
5:01 p.m.
> "The standard format for CP/M is 8"
SSSD."
On Fri, 13 Jun 2014, Alexandre Souza wrote:
What would you expect from someone who turned out
IBM? :)
He was a man of strong principles. How many of us would have the cajones
to tell IBM, "Go wait your turn in line at the front counter with the rest
of the customers." (not in those exact words). Did he know how many
billions of dollars that meant? (was it the stupidest thing ever said,
or the most chutzpah?) Probably.
--
Grumpy Ol' Fred cisin at xenosoft.com
6:55 p.m.
He was a man of strong principles. How many of us
would have the cajones
to tell IBM, "Go wait your turn in line at the front counter with the rest
of the customers." (not in those exact words). Did he know how many
billions of dollars that meant? (was it the stupidest thing ever said,
or the most chutzpah?) Probably.
Strong principles or just plain dumb and antisocial? He turned off an
(HONEST) offer to become a billionaire.
7:49 p.m.
It was thus said that the Great Alexandre Souza once stated:
He didn't turn them down, as there was a version of CP/M-86 available when
the PC was launched. It's just that he didn't get back to them as quickly
as possible, thus alerting Bill Gates to the opportunity.
He did, however, charged too much for CP/M-86, compared to the price of
MS-DOS 1.0 (which pretty much *was* CP/M-86).
-spc
He was a man of
strong principles. How many of us would have the cajones
to tell IBM, "Go wait your turn in line at the front counter with the rest
of the customers." (not in those exact words). Did he know how many
billions of dollars that meant? (was it the stupidest thing ever said,
or the most chutzpah?) Probably.
Strong principles or just plain dumb and antisocial? He turned off an
(HONEST) offer to become a billionaire.
3841
days inactive
3848
days old
15 comments
5 participants
participants (5)
-
alexandre.tabajara＠gmail.com -
cclist＠sydex.com -
cisin＠xenosoft.com -
spacewar＠gmail.com -
spc＠conman.org