Copyright © 1995, &a.wilko;.
The ESDI interface uses two cables connected to each drive.
One cable is a 34 pin flat cable edge connector that carries
the command and status signals from the controller to the
drive and vice-versa. The command cable is daisy chained
between all the drives. So, it forms a bus onto which all
drives are connected.
The second cable is a 20 pin flat cable edge connector that
carries the data to and from the drive. This cable is radially
connected, so each drive has its own direct connection to the
controller.
To the best of my knowledge PC ESDI controllers are limited
to using a maximum of 2 drives per controller. This is
compatibility feature(?) left over from the WD1003 standard
that reserves only a single bit for device addressing.
On each command cable a maximum of 7 devices and 1 controller
can be present. To enable the controller to uniquely
identify which drive it addresses, each ESDI device is equipped
with jumpers or switches to select the devices address.
On PC type controllers the first drive is set to address 0,
the second disk to address 1.
The daisy chained command cable (the 34 pin cable remember?)
needs to be terminated at the last drive on the chain.
For this purpose ESDI drives come with a termination resistor
network that can be removed or disabled by a jumper when it
is not used.
So, one and
Why is ESDI such a pain to get working in the first place?
People who tried ESDI disks with FreeBSD are known to have
developed a profound sense of frustration. A combination of
factors works against you to produce effects that are
hard to understand when you have never seen them before.
This has also led to the popular legend ESDI and FreeBSD
is a plain NO-GO.
The following sections try to list all the pitfalls and
solutions.
As briefly mentioned before, ESDI comes in two speed flavors.
The older drives and controllers use a 10 Mbits/second
data transfer rate. Newer stuff uses 15 Mbits/second.
It is not hard to imagine that 15 Mbits/second drive cause
problems on controllers laid out for 10 Mbits/second.
As always, consult your controller
Mainstream ESDI drives use 34 to 36 sectors per track.
Most (older) controllers cannot handle more than this
number of sectors.
Newer, higher capacity, drives use higher numbers of sectors
per track. For instance, I own a 670 Mb drive that has
54 sectors per track.
In my case, the controller could not handle this number
of sectors. It proved to work well except that it only
used 35 sectors on each track. This meant losing a
lot of disk space.
Once again, check the documentation of your hardware for
more info. Going out-of-spec like in the example might
or might not work. Give it a try or get another more
capable controller.
Most ESDI drives allow hard or soft sectoring to be
selected using a jumper. Hard sectoring means that the
drive will produce a sector pulse on the start of each
new sector. The controller uses this pulse to tell when
it should start to write or read.
Hard sectoring allows a selection of sector size (normally
256, 512 or 1024 bytes per formatted sector). FreeBSD uses
512 byte sectors. The number of sectors per track also varies
while still using the same number of bytes per formatted sector.
The number of unformatted bytes per sector varies,
dependent on your controller it needs more or less overhead
bytes to work correctly. Pushing more sectors on a track
of course gives you more usable space, but might give
problems if your controller needs more bytes than the
drive offers.
In case of soft sectoring, the controller itself determines
where to start/stop reading or writing. For ESDI
hard sectoring is the default (at least on everything
I came across). I never felt the urge to try soft sectoring.
In general, experiment with sector settings before you install
FreeBSD because you need to re-run the low-level format
after each change.
ESDI drives need to be low level formatted before they
are usable. A reformat is needed whenever you figgle
with the number of sectors/track jumpers or the
physical orientation of the drive (horizontal, vertical).
So, first think, then format.
The format time must not be underestimated, for big
disks it can take hours.
After a low level format, a surface scan is done to
find and flag bad sectors. Most disks have a
manufacturer bad block list listed on a piece of paper
or adhesive sticker. In addition, on most disks the
list is also written onto the disk.
Please use the manufacturer's list. It is much easier
to remap a defect now than after FreeBSD is installed.
Stay away from low-level formatters that mark all
sectors of a track as bad as soon as they find one
bad sector. Not only does this waste space, it also
and more importantly causes you grief with bad144
(see the section on bad144).
Translations, although not exclusively a ESDI-only problem,
might give you real trouble.
Translations come in multiple flavors. Most of them
have in common that they attempt to work around the
limitations posed upon disk geometries by the original
IBM PC/AT design (thanks IBM!).
First of all there is the (in)famous 1024 cylinder limit.
For a system to be able to boot, the stuff (whatever
operating system) must be in the first 1024 cylinders
of a disk. Only 10 bits are available to encode the
cylinder number. For the number of sectors the limit
is 64 (0-63).
When you combine the 1024 cylinder limit with the 16 head
limit (also a design feature) you max out at fairly limited
disk sizes.
To work around this problem, the manufacturers of ESDI
PC controllers added a BIOS prom extension on their boards.
This BIOS extension handles disk I/O for booting (and for
some operating systems
Most ESDI controllers offer the possibility to remap bad sectors.
During/after the low-level format of the disk bad sectors are
marked as such, and a replacement sector is put in place
(logically of course) of the bad one.
In most cases the remapping is done by using N-1 sectors on
each track for actual data storage, and sector N itself is
the spare sector. N is the total number of sectors physically
available on the track.
The idea behind this is that the operating system sees
a 'perfect' disk without bad sectors. In the case of
FreeBSD this concept is not usable.
The problem is that the translation from
The preceding section leaves us with a problem. The controller's
bad block handling is not usable and still FreeBSD's filesystems
assume perfect media without any flaws.
To solve this problem, FreeBSD use the
ESDI disks are handled by the same
I successfully installed FreeBSD onto a ESDI disk controlled by a
ACB-2320. No other operating system was present on the disk.
To do so I low level formatted the disk using NEFMT.EXE
(
I successfully installed FreeBSD onto a ESDI disk controlled by a
WD1007 controller. To be precise, it was a WD1007-WA2. Other
variations of the WD1007 do exist.
To get it to work, I had to disable the sector translation and
the WD1007's onboard BIOS. This implied I could not use
the low-level formatter built into this BIOS. Instead, I grabbed
WDFMT.EXE from www.wdc.com Running this formatted my drive
just fine.
According to multiple reports from the net, Ultrastor ESDI
boards work OK with FreeBSD. I lack any further info on
particular settings.