6 Oct
2000
6 Oct
'00
11:41 a.m.
From: Richard Erlacher <richard(a)idcomm.com>
well as
Allison suggests that the disk parameters are obscure
and hard to
locate,
but CORTESI's book on CP/M, among others, provides
a bit of software
that
In short simple sentences. If you have not done this you will be
surprized.
Cortesi write with the assumption that all bioses have the structure and
form
he uses as example. It is a defective assumption.
In those cases, among which one finds the CCS example,
wherein a simple,
"dumb" BIOS is loaded into a 20-K CP/M requiring a 32K memory in which
to
run, and subseqeuently used to run a
"smarter" and more fully developed
Not really.
version of the BIOS together with the OS loaded into
whatever memory it
finds available thereby making a 64K(actually 61K) CP/M quite
attainable,
This is not news, nor significant.
one would have to examine the autocommand that's
loaded in the "dumb"
system
in order to find the image that's going to contain
the "real McCoy" with
the
full-featured BIOS from which the parameters relating
to the directory
and
data areas of the diskette can be extracted.
Presuming there was an autocommand.
This strategy is particularly important in those rare
cases where one
has
actually done what the CCS folks recommend and format
the first two
tracks
of an 8" diskette single-density and the remainder
at double density.
Likewise, the remainder of the diskette can be two-sided. The reason
THEIR
CCS while a decent box is far from being the be all, say all of the bios
world.
What puzzles me is that, if this information is so
readily available,
why
hasn't the entire process been automated already?
I know there are lots
of
Becasue it's is not so readially available. You assume it is and proceed
that
way but once you get off that CCS box the world changes greatly. Look at
the 5.25 formats, look close at the similar but not the same formats.
For
example I have 5 different 5.25 781kb formats that are not even similar.
One uses 1024byte sectors, another has sector 1 on side one and side two
ends with sector 18 (512byte!). There is one that numbers the cylinders
sero thourgh 79 on one side and 80 throgh 159 on the second. The fifth
is like the first save for the skew is appied at format and not in the
bios.
Funny thing the DPH and DPB is exactly the same for all of them
should be done. There is always a bit of a guess as to
whether 4K or 8K
allocation blocks should be used when hooking up a hard disk. That's
not an
issue with floppies, however.
Yes it is. I have floppies that use 1k (most SD though some are DD!),
many
that use 2k and even some nut case using 4k(not me honest!).
> I have a fully documented CCS and it clasifies as
the early basic CP/M
> bios of low to average functionality. It's robust but closer to a
minimal
example.
True enough, but it's compatible with a front-panel and the software's
written for an 8080 so you can use their FDC with an 8080 or 8085 as a Z80. Moreover, it's rock-solid. The fact that
it uses a nearly
vanilla-flavored CP/M doesn't detract either. I've run into absolutely
no
CP/M programs that won't run on it, while there are
numerous utilities
that
won't work properly on the more modern MPM-targeted
boards I got from
Systems Group.
Sorta. It doesn't support type ahead, circular iterrupt driven buffers
for
fast serial devices and relies on CPU PIO. It's low end. The only thing
it does do is double density and SSSD 8" interchange (sometimes).
What you refer to as skew is what I call the
interleave, while a sector
skew
No I'm using the DRI term out of their books. I know its interleave.
is a difference in sector numbering from idex, used by
some systems
(mostly
early DEC actually, but some truly random-access
systems as well) to
Actually DEC has a two level one for VT180, interleaved 512byte physical
sectors
and interleave inside the sectors. It's one of three formats that were
used for that
though that was least common.
If it's not the stuff from DRI, it's not
relevant, since it's not CP/M.
Your really looking to ignore progress, and even DRI supplied mods?
I'll admit that's a weakness, but for now,
I'm happy to deal with CP/M
only.
AFAIK, DRI didn't issue any patches to v2.2. There
were several
enhanced
If you insist.
That's true, BUT, when you have a two-stage boot,
you can examine the
second
layer boot system, and, in fact, have to in order to
avoid getting
tangled
up in discrepancies between the boot tracks and the
directory and data
area.
Ok but what systems usually use a two stage boot? Few and nearly none.
> storage. You will have to figure out from that a
lot of things that
are
variable and can still end up as the same answer.
In fact, I don't believe they have to
be "figured out" at all. After
all
the diskette is in the drive. You just have to look at
it.
See my example of the 781k disks. Two of them would defy simple
inspection.
It does get much more messy when you try to squeeze
speed out of the
system
in ways the ultra-slow CPU doesn't let you
appreciate, but when I said
optimal, I meant for the technology of the time, which meant, at least
to
me, getting the most hard disk space to fit into the
parameters the
system
would allow, without overly restricting either
effective space
utilization
or directory space. That seems to have been the key
tradeoff of the
time
... allocation block size versus number of directory
entries. One other
Not really a big deal was made of it as few had real world expereince and
were trying to scare up a few more bytes of the drive they paid so dearly
for and then never filled more than 50%. The other half was hard disks
were new things to have to deal directly with so there was an aura of
mystery to setting values. The only thing that ever and still concerns
me
is the ALLOC vector as for a 8mb logical drive with 4k granularity there
will
be 256 bytes of ram for just for that, add 512 for a host buffer, 128 for
the
directory buffer local variables and you eaten 896 bytes for the first
drive
and about 256+ per drive and that is non recoverable space. That is the
only real problem. Add that to a featureless base driver and it's an
easy
2-3k of space for the bios more if it's a real bios.
factor was swtiching heads rather than moving the head
stack. The heads
take at least 3 ms to move from track to track, plus 8 ms on the
average, to
rotate half a rev, while switching heads took about
40-50 microseconds
on
More than that as the ST506 didn't do (nor did the controllers of the
time)
fast seeks. You had to wait for the ST225 for that. Stated average
access
time is 178mS for st506, St225 was a more resonable 73 and the Quantum
D540 took that to a mere 57. The D540 could look faster though with it's
8 heads as you didn't shuffle far and the voicecoil actuator was fairly
fast.
the early Seagate ST506's. The trick, to me, was
always finding a way
to
computer head, cylinder and sector from the CP/M sector
number you were
given by the BDOS without having to swallow up half a KByte in lookup
tables.
Floggin. One the drive was filled to about 30% and had been in use for a
while you were moving around a lot and there was little trickery that
helped
at the drive level.
I didn't kill space in lookup tables. It was simple to me. The 4 heads
and the 16 512 byte sectors per track were handled as SPT of 256 in
the DPB so the BDOS would hand back a logical sector on a track
with head number in there too. I treated the four sides as one logical
track. A few right and left shifts would give me a head (upper two bits)
physical sector (middle 4bits) and logical sector index into the physical
sector (lower two bits). The CYLINDER was passed as track by the BDOS.
Obviously it was quite compact.
If you build like DRI, Cortesi or Laird said you hit the wall every
16k as where ever you are your going back to the directory where
ever it happened to be and that took a long time.
The first drive I had(still have turns 20 next summer) was a 506. It was
slow, the controllers were slow and the only up side is some would
buffer a full sector for you saving CPU timing. I stopped using it
when I got my second hard disk a D540, in real life it was much
faster and introduced me to the problem of partitions. I moved up
as the drive was available and offered speed, even with 6mhz z80s
the ST506 was ponderously slow. It was only exceeded by an 8"
Memorex 102 I gave away working, CTRL-C was a real wait and
a kick to watch the head creap back.
Allison