blaine@worsel.UUCP (Blaine Gardner) (12/25/89)
Here is the review I wrote for the August 1989 AUSM disk. Please leave my
name attached if you spread this around.
***************************************************************************
Hardframe vs. A2090A comparison.
Since I've recently switched from the Commodore A2090A controller to the
Microbotics HardFrame, here's a short comparison of the features of the
two. (See below for speed benchmark details, here I'll just say the
HardFrame is considerably faster than the A2090A.)
A2090A
I've owned the A2090A for close to a year. It was the only DMA controller
available at the time, and it supports both ST506 (IBM style) and SCSI (Mac
style) interfaces. This was nice because ST506 drives are cheaper than
SCSI (though the SCSI drives are coming down in price now).
The A2090A is a bit odd in its requirements for device names. DH0: and
DH1: MUST be the names for the two possible ST506 drives. DH2: to DH8:
MUST be the names for the seven possible SCSI drives. If you mount a
partition with a device name (DHn:) that matches a possible physical drive,
the A2090A gets VERY confused. It took me a while to figure this one out,
since the manual does not make much note of it. In plain English: DO NOT
NAME ANY PARTITION WITH A DHn: DEVICE NAME. Once you've got that figured
out, things work ok. I named my Fast File System partitions FF0: and FF1:
(for FastFilesystem).
The A2090A will autoboot under 1.3, but it cannot boot the Fast File System
because it has to load the FFS before it can use it. So the typical setup
is to make the first partition that MUST be the Old File System (OFS) very
small. Mine was 2 cylinders on the ST4096, and that gave me about 300K.
More than enough to boot from. (The 1.3 Enhancer Manual section on the FFS
is very helpful with this, it gives a list of the minimum files required to
boot OFS and pass control to a large FFS partition.)
So now the setup is:
DH0: OFS 300K Boot partition
FF0: FFS 40M SYS: partition
FF1: FFS 40M Additional space
There is still one little gotcha. A number of slightly brain dead programs
have their file requesters hard coded with "DH0:", but DH0: is just a tiny
boot partition, not something suitable for working on. My "fix" was to use
NewZap (a binary file editor) to edit "DH0:" to "FF0:".
So now life is great, I've got an autobooting hard drive system, with a
fast ST506 drive. Not as fast as some of the SCSI setups, but worlds
better than floppies!
A2090A SCSI
I found a great deal on a very fast SCSI drive (CDC Wren III), so I bought
it and sold my ST506 drive (Seagate ST4096).
Now some annoyances start showing up. The A2090A can't cold boot the Wren
III. The Wren has a rather lengthy spinup and self-test sequence (actually
only about 20-25 seconds). And the A2090A has quit looking for a drive
before the Wren is ready. Reboots work fine, but a cold start from
power-on will always fail. (The Seagates suffer the same problem, and the
excuse has been that Seagate did it "wrong". Did a company like Control
Data also do it "wrong" or is the A2090A really at fault here?)
The drive activity LED connection on the A2090A has some problems. There
are two jacks, one for ST506 drives, and one for SCSI drives. The manual
only mentions J5 for the ST506, not J4 for SCSI. So you can only have one
drive light the LED on the front of the 2000. Also, with the Wren III
installed, the LED just barely lights. You can only see drive activity
when the room lights are out. The right voltage is there, but the pulses
are too short to light the LED up. It does light brightly during the reset
sequence though.
Now the killer. There is a bug in the A2090A's SCSI interface. With a
hires 16 color picture displayed, DMA contention causes the FIFO (First In,
First Out) buffer RAM to get overrun. So it has to retry, and then it gets
overrun, and has to retry, and gets overrun, and has to retry, and.......
The bottom line is that wonderful 500K/second transfer rate drops down to
about 30-50K/second. Nearly floppy speeds in other words. OUCH!
Commodore has acknowledged the problem, and promised a fix, but nothing has
been released as of August 1989. There is a program called Patch2090 that
attempts to bandaid this problem by cutting down the MaxTransfer value when
a hires image is displayed so that the FIFO doesn't get overrun. It does
work, but not as well as fixing the problem would.
HardFrame
The HardFrame is a SCSI only controller, and since it doesn't have all the
ST506 interface circuitry, it's both smaller (1/2 card length) and cheaper
than the A2090A. There is an aluminum frame mounted to the card, and a 1/2
height 3.5" hard drive can be mounted to the frame. The card can supply
power to the drive with a small adapter cable that is included. There is
no external connector on the back edge of the card (the A2090A provides a
Mac compatible DB-25 connector on the back of the computer) so any external
connections are up to you. Also, the frame didn't quite line up with the
mounting holes on the back of the computer, so a little bending and cussing
was required to get it to fit.
The HardFrame is billed as the fastest controller available for the Amiga,
and my results back that up. Just switching from the A2090A to the
HardFrame boosted reads from 570-650K/sec to 750-870K/sec, writes from
400-430K/sec to 430-480K/sec, and directory scans from 131/sec to 227/sec.
The Wren III was formatted at 1:1 interleave on both controllers.
The HardFrame setup is much easier than the A2090A. Instead of messing
with mountlist entries, the RDprep program queries the hard drive to see
what it is, then presents you with a list of parameters that you can accept
for a 1 partition setup, or modify as you wish. (It did goof on the blocks
per cylinder on the Wren III, it reported 36 instead of 35.) It stores all
the information in a Rigid Disk Block in a reserved area on the drive. And
all partitions defined in the Rigid Disk Block are automagically mounted
when the computer is booted.
Also the HardFrame can boot the Fast File System because it copies the FFS
into the Rigid Disk Block. Now I boot directly into a 60M FFS partition
called DH0: instead of having to mess with an OFS boot partition.
The Rigid Disk Block can be easily modified at any time with RDprep. I
decided that I didn't want my four floppy sized partitions mounted every
time I booted, so I just re-ran RDprep and deleted them from the Rigid Disk
Block. RDprep could be more intelligent about defaults, I had to re-enter
the same info several times because it persisted with its own defaults
instead of echoing what I'd used for the last partition. But that's nit-
picking, it's still far easier than setting up the A2090A.
The 2000's HD activity LED lights up nice and bright with the HardFrame
too, compared to the A2090A, I almost need sunglasses!
The crippling hires slowdown of the A2090A is not a problem on the
HardFrame either. The HardFrame does slow down a bit, but it's not
very noticable.
Lest you think I've sold my soul to Microbotics, the HardFrame is not
perfect. I've got a couple of very real problems, though at the moment
they don't matter at all.
The low level format program hung on the Wren III. It queried the drive,
and correctly reported the drive's type and size, and that it was already
formatted with a 1:1 interleave. But then it hung when it tried to do the
low level format. I have no idea why, but since the drive was already
formatted correctly I just skipped the low level format. This could be a
real problem in other circumstances.
I've got an A2620 card in my 2000, and I run in 68020 mode all the time.
But when I switched back to 68000 mode after installing the HardFrame I got
a continuous string of random Gurus at random times during the boot. As it
stands now the hard drive is completely unusable in 68000 mode. Since I
only use 68000 mode to play some brain-dead games that won't run on the
68020, this doesn't really affect me, but I will be contacting MicroBotics
to find out what the problem is. [Note: This was traced to other software
in the system, my mistake! BSG 12-25-89]
--
Blaine Gardner @ worsel UUCP: uunet!iconsys!caeco!i-core!worsel!blaine
utah-cs!caeco!i-core!worsel!blaine
UUCP at work: utah-cs!esunix!blgardne