hull@hao.ucar.edu (Howard Hull) (03/26/89)
This is a long article about the Quantum Q80S/A2090A PREP and Format.
In summary, thanks to net articles by several contributors, I was able to
figure out what to do, and I now have a working 80 meg hard drive in my
Amiga 2000. Though too numerous to mention individually, these other net
submittors will no doubt recognize their various contributions in this
summary. I want to thank you all for the invaluable help.
If this is boring to you, you'd best hit n now, as I'm not asking many
questions at this point. If you are interested in interfacing this hard disk
to your Amiga 2000, or you feel that you are the guardian of such matters,
then by all means read on. As usual, the knowledgeable are invited to pounce
on this with applicable critique - particularly if it saves someone else
some trouble. So:
Having read Computer Shopper for four months, I decided to take the plunge
and get a hard disk for my Amiga 2000. I decided that the GVP controller
was the best for autoboot (since it can boot from/to an FFS partition) but
that the Amiga 2090A would be a better prospect if I ever wanted to install
an A2620 '020 card and have DMA access to its 32-bit memory. Also, since
I have the A2058 2 meg fast ram, I wouldn't have any trouble with the A2090A
DMA contention with the blitter accessing the A2000 slow-fast memory and
chip memory. (See the note below in the MountList part of the discussion.)
Of course, I did manage to get this done almost the very day before the new
GVP 25MHz 030 card was revealed - sort of makes me feel like I jumped off the
balcony at the right time, but before I could get down there, somebody moved
the dadgum horse.
Anyway, I broke down and got the Amiga A2090A controller from a local dealer
who had it in stock (that was nice of him). As I am not an (IBM) 5.25 fan, I
thought it would be justice to get an 80 meg 5.25 inch SCSI drive and put it
in the 5.25 inch Amiga floppy bay. With all the roar about spin-up failures
in Seagate drives, and the news about Miniscribe's inability to autoboot due
to the long startup times associated with the drive's need to read its own
waffleware off the hard disk before it could do anything on the SCSI bus, I
wanted a fast spin-up no nonsense robust and reliable drive. I had decided
that the Quantum Q280S rather well filled the bill; but then nobody seemed to
have any in stock (except for used and/or reconditioned ones). As it turned
out, Hard Drives International in Texas (they advertise in Computer Shopper)
had the Quantum 80S in stock (the only one they carry from Quantum). It is
a new technology 3.5 inch 80 meg drive intended to be an advanced product
beyond the the Q280S. It is supposed to have an access time in the range of
19 to 11 milliseconds, which is faster than the Q280S. There have been a
couple of articles on the net concerning how to prep and format the Q280S,
as well as several about the Q80S.
When I telephoned the HDI guy, we discussed the problem of mounting this
drive in the Amiga. He finally said "Then you'd want this drive in a 5.25
frame." I said "Yeah!" I then asked if there was documentation with the
drive. He said "We ship documentation with all our drives." (These turned
out to be benchmark statements if ever there were any...) He promised that
the drive would be delivered in seven to ten days by UPS Ground. So I
ordered the Q80S from HDI, and sure enough, nine days later I had it in my
sweaty palms. "It" is what I had, all right. It had not been put in a 5.25
inch frame as he had implied it would. It had no bad block list nor any
other manufacturer's documentation. It was much as listed on the invoice,
a "bare drive", except that it had a black plastic front panel with a green
LED window at the bottom left side. The LED was soldered to the bottom-side
PC board, and positioned with a plastic clamp. Although the bottom-side PC
board exposed a number of MSI chips to view, there were no ventilation holes
in the front of the drive, such as are commonly found with full-height and
half-height drives I have seen. The only other documentation supplied with
the drive was a fairly good set of instructions on how to install a Seagate
or a Miniscribe drive in a PC XT or AT. Phooey. As I expected this would be
about the best I could do anywhere by mail order ($775 + $9 S&H) I decided
I might just as well act like a satisfied customer, at least until I found a
more serious problem.
To begin, I went through the exercise of reading the 2090A manual, and got
net articles on how to prep and format the Q80S. These articles pointed out
that the Q80S is "weird" in that it has two zones, an inner zone that's been
compensated for "28 sectors per track", and an outer zone that's compensated
at "35 sectors per track". In any case, the drive is rated for 164058 blocks
at 512 bytes per block (formatted); total tracks are supposed to be equal to
5004. One net submitter (who noted in passing that he was not so much a
mathematician) gave what he thought to be a workable formula, 882 cylinders,
6 surfaces and 31 sectors per track, resulting in 154052 blocks total. Of
course, he was mildly miffed about not being able to get at the last 6 blocks.
Another suggested using 739 cylinders, 6 surfaces and 37 sectors per track,
resulting in the requisite 164058 blocks. I tried both, along with MountList
entries provided by the various netters, and they all worked - but only after
much slutching about in the A2090A HD Install/Prep quicksand, I might add.
Most of the problems I had were attributable to the fact that the drive
arrived from HDI strapped for address "6" (of the three jumper positions on
the drive (A0/A1/A2), A1 and A2 were jumpered). When I first tried the Prep,
the drive light just came on, and then stayed on. In accordance with two
earlier net articles, each of which mention one half or another of what I
just related concerning the jumpers, I removed the two jumpers and the Prep
then completed properly. Also as reported earlier, there were no diagnostics
except "Device not PREPed." In fact, I did so much slutching about that
I've decided to list a detailed procedure below in order to save others of
you (who may be brave enough to try this) some of the agony and frustration,
and for the event that I cannot remember all this the next time I have to
do it.
In any case, the first thing I did was to try to determine how many tracks
were mapped at 28 blocks, and how many were mapped at 35 blocks. I did this
in spite of the information in previous net articles that point out that the
SCSI interface doesn't care a wit about how the tracks are formatted, since
the SCSI interface merely returns data in accordance with block address
requests. However, a look at this question produced a very curious result:
If we enumerate the 28 block track count as x and the 35 block track count
as y, then we can see that
28x + 35y = 164058 total blocks
and
x + y = 5004 total tracks
make a simultaneous linear equation set; the solution turns out to be
x = 1583.142857 and y = 3420.857143
Now if I weren't a Hard Drives International customer, I'd swear there was
something peculiar here. We _are_ dealing with integral tracks, are we not,
and we thus ought to get an integral result for this little exercise, should
we not, unless some low down good for nothing sub-canine cretin _lied_ to us
about something somewhere... What goes on in this blasted drive, anyway?
It would seem that either 28 is wrong, or 35 is wrong, or 5004 is wrong or
164058 is wrong, or maybe it has something to do with the format, and 164058
is for some other format... I decided the latter was the simplest to test.
I tried some other combinations, and came up with the result that it might be
164052=(1584x + 3420y), or perhaps 164094=(1578x + 3426y), maybe. But then
164094, which when divided by 6 results in 27349 blocks per surface, is then
thereafter indivisible by anything that might be a real track count. While
164052 can also be divided by 6, to give 27342, and that has lots of divisors
(651 and 882 for example) it is not what I'd hoped to see. The value 164059
=(1583x + 3421y) is a basket case since it starts out by not being divisible
by 6. When I try to work the problem backwards by using 739 tracks on the
164058 block disk, I need 27343 blocks per surface. I can try to solve the
simultaneous set:
28x + 35y = 27343 blocks (one surface)
and
x + y = 739 tracks (one surface)
but that comes out even more strangely:
x = -211.1428571 and y = 950.1428571
Non integral tracks were bad enough. But NEGATIVE tracks?!!! Unnnnngnh.
However, the drive _will_ format with the 739 track specification and 37
sectors per track on 6 surfaces; this seems to yield the best result: To
wit, using the 31 sector per track figure (which is surely wrong for the
part of the disk where the Mount wants to find the RES2: device), produces
the complaint "handler not found" unless one starts the first partition after
RES2: from cylinder 3 rather than cylinder 2 (see below). Using 37 sectors
per track allows the first partition to begin at cylinder 2. It also seems
that in an FFS partition the "Reserved = 2" in the MountList entry chews up
the first two blocks of that partition anyway. What does the "Reserved = 2"
entry do, and why is it needed? The RES2: device is specified to use cyls 0
and 1, but that's independent. The way I figure it is that with the 31 track
recipe not only does one not get the last 6 blocks (164052 vs 164058) but one
also loses an entire cylinder (31 x 6 = 186 blocks) at the start of the first
partition. This may be summed up as expressed by 3 x 31 x 6 + 6 = 564 in one
case, and 2 x 37 x 6 = 444 in the other, and that says one comes out better
with the 739 track method by some 120 blocks. I know. Big Deal. But I'm
really bummed by not having a physical model with which to describe what's
truly going on in the drive. There is also something arbitrarily weird with
needing the first two cylinders of an 80 meg drive to store the handlers
when they will as well fit on the first two cylinders of a little 20-meg
17-sector-per-track drive.
As you install the A2090A controller card, do not bother to connect the Hard
Disk LED plug to the board (more on that later) and DO remove the U50 and U51
ROM chips if you DO NOT have V1.3 AmigaDOS KickStart ROMS installed in your
Amiga 2000. If you have had the V1.3 KS ROMs installed, then leave the U50
(HI) and U51 (LO) ROMs in their sockets - and be sure to read the A2090A
Addendum documentation so you'll be informed about the circumstances of the
A2090A's autoboot. Note that there was one more net article by one fellow
who described the experience of three Q80S buyers and who felt that they had
discovered that the A2090A timeout was right close to the spin-up time of
the Q80S (so I may yet have the equivalent of the Miniscribe waffleware
problem in spite of my efforts to avoid it!).
Now some things about the A2090A Prep program... One is encouraged in the
CBM supplied manual to read through the whole chapter on installation of the
software before proceeding. Doing so helps some, but what you'll probably
end up doing is an initial HD Install followed by at least one manual Prep
and one or two format invocations. The manual warns that one is to invoke
the HD Install icon only once, as the resultant script execution will write
files to the workbench disk each time it is brought into use. As another
netter advised earlier, you should use a fresh _copy_ of an original CBM
workbench disk for the HD Install. The program knows the difference between
a V1.2 Workbench and a V1.3 Workbench; it begins by copying a number of
June '87 vintage AmigaDOS commands and HardDisk software modules to ram:.
When that's done, the program warns that continuing will destroy any data
on the disk (not necessarily so, see below), and posts a N option so that
just hitting a carriage return dumps you out of the HD Install. If so, no
harm done, you can just start HD Install over again at this point. If you
forge ahead and answer Y, and add a carriage return, the program THEN
copies the HardDisk software modules to the workbench (along with several
AmigaDOS commands if you happen to have used a V1.2 WB disk). Another
netter reported that HD Install will help you in selecting stuff to remove
(i.e. Demos) in order to get room for the new stuff. (I recommend doing
the HD Install with a copy of a V1.3 Workbench if you possibly have one.)
The program then proceeds to invoke the Prep routine (it really ought to give
you a break here, let you change the MountList and either let you do the Prep
manually, or provide another icon for you to invoke the Prep). I mean, it is
very disconcerting to be advised (in the documentation) that you will likely
have to change your MountList entries, but then never be given an opportunity
to do so until the Prep is over. Perhaps Prep does not access the MountList
file? Certainly Prep asks enough questions that it doesn't need to look at
the MountList file if only somehow the hard disk could get magically mounted.
As you can see by the instructions below on how to do a manual Prep, a Mount
of at least RES2: and a mount of any partitions following the first one will
also need to be done, either manually or by Binddrivers in Startup-Sequence.
So this implies to me that the HD Install prep uses the uncorrected MountList
data unless you are smart enough to have a CLI open in advance so that you
can change the Mountlist as soon as you can determine that the sample mount
entries have been placed in it, and the script is about to call Mount. I yet
do not know if it is possible to do this, so I think the best thing to do is
a preliminary prep in which you supply information that you will again later
use in a manual prep with the corrected MountList.
The HD Install prep begins by asking if one wants to do a manual prep (0),
a prep on an SCSI drive (1) or a prep on an ST506 drive (2). It should be
ok to do (0) as described above, or (1) and then select the Quantum Q40S
from the list just to get it over with. The main thing you get done by all
this is the installation of the hddisk and hddisk.info files into your WB
Expansion directory, the Prep command installed in the c: directory, and
perhaps the update of your V1.2 workbench with some V1.3 commands. If you
are one of the lucky ones that got AmigaDOS V1.3 boot ROMs when they were
available (my dealer tells me they are back-ordered into April), then you
supposedly don't have to copy the hddisk or its icon over to the workbench,
as the A2090A's on-board ROMs will see to it that the proper drivers are made
available for the autoboot sequence. Otherwise, you must remove the ROMs
from the A2090A board to keep them from trying to do the autoboot in the
absence of the needed AmigaDOS 1.3 KickStart code.
Now it's time to have a look at the MountList entries:
Except for the first partition, you can invent whatever names you like
for the partition device tags; I recommend three character names so that
the Info command will tabulate neatly. You can also name the first partition
anything you like, but beware - if some program decides to access device
DH2:, bad results will surely follow. Just as the system knows about the
reserved two cylinder SCSI handler partition RES2:, it also knows DH2: to
be the first partition of the first SCSI hard disk. If you or anything
else (such as binddrivers in a Startup-Sequence with no Mount commands
prior to the binddrivers line) references DH2: you will get the message
"Not a DOS Disk" and will find (using the AmigaDOS Info command) a process
"Validating DH2:" that's hung in a loop.
So I strongly advise that you name the first SCSI hard disk partition DH2:
in any case. One more thing to think about is the BuffMemType selection.
I believe that if you select BuffMemType = 1 (as I did in the Fast File System
MountList entry below (Example B), the driver must use fast ram for the
transfer, and that will get rid of the much maligned A2090A DMA contention
problems. However, if you have a 1 Megabyte A2000 you will have to use
BuffMemType = 0 and there will be times when you will either suffer or
be forced to use Left-Amiga-N to bring to front a two plane workbench
screen in order to get the DMA over with in a reasonable time:
Example A: a small 29 megabyte AmigaDOS partition followed by a large
54 megabyte AmigaDOS partition.
[Remember that the largest AmigaDOS partition allowed is limited
to 54 Megabytes (54,525,952 bytes) due to the imposition of 26
(maximum) bitmap pointers, each of which points to 4096 512 byte
blocks which for AmigaDOS, anyway, each contain up to 488 bytes of
data. This represents a maximum of 51,970,048 bytes of data, minus
any blocks used for Amiga DOS directories, bit maps, or file header
blocks.]
/* MountList for V1.3 */
/* SCSI drives are units 3 and up */
RES2: Device = hddisk.device
Unit = 3
Flags = 0
Surfaces = 6
BlocksPerTrack = 37 /* or alternatively, 31 */
Reserved = 0
Interleave = 0
LowCyl = 0 ; HighCyl = 1
Buffers = 1
BufMemType = 0
#
/* SCSI AmigaDOS 29 Meg File System partition */
DH2: Device = hddisk.device
Unit = 3
Flags = 0
Surfaces = 6
BlocksPerTrack = 37 /* or alternatively, 31 */
Reserved = 0
Interleave = 0
LowCyl = 2 ; HighCyl = 258 /* or alternatively 3, and 308 */
Buffers = 64
BufMemType = 0
#
/* SCSI AmigaDOS 54 Meg File System partition */
DP2: Device = hddisk.device
Unit = 3
Flags = 0
Surfaces = 6
BlocksPerTrack = 37 /* or alternatively 31 */
Reserved = 0
Interleave = 0
LowCyl = 259 ; HighCyl = 738 /* or alternatively 309, and 881 */
Buffers = 128
BufMemType = 0
#
Example B: A small 22 megabyte AmigaDOS partition for the inside of the disk
followed by a large 61 megabyte Fast File System partition.
On the inside tracks of the disk, reliability may at some later
date become a problem. (The heads fly closer here due to lower
air velocity, and this initially gives better data reliability
in spite of probably increased bit density. But when crumbs of
junk start to appear on the surface due to various accidents,
the situation deteriorates on the inside tracks first. Built-in
redundancy of the AmigaDOS file system may allow better hard-error
recovery by Haynie's DiskSalv program? (for instance)). Note
that in the line below containing "FileSystem = l:FastFileSystem"
the character in front of the colon is an "el" and _not_ a "one".
/* MountList for V1.3 */
/* SCSI drives are units 3 and up */
RES2: Device = hddisk.device
Unit = 3
Flags = 0
Surfaces = 6
BlocksPerTrack = 37
Reserved = 0
Interleave = 0
LowCyl = 0 ; HighCyl = 1
Buffers = 1
BufMemType = 0
#
/* SCSI 23 Meg AmigaDOS File System partition */
DH2: Device = hddisk.device
Unit = 3
Flags = 0
Surfaces = 6
BlocksPerTrack = 37
Reserved = 0
Interleave = 0
LowCyl = 2 ; HighCyl = 199
Buffers = 32
BufMemType = 1
#
/* SCSI 60 Meg Fast File System partition */
DP2: Device = hddisk.device
FileSystem = l:FastFileSystem
Unit = 3
Flags = 0
Surfaces = 6
BlocksPerTrack = 37
Reserved = 2
Interleave = 0
LowCyl = 200 ; HighCyl = 738
Buffers = 128
GlobVec = -1
BufMemType = 1
Mount = 1
DosType = 0x444f5301
StackSize = 4000
#
I have done preps with the FFS as the first partition by swapping the FFS/DOS
MountList entries in Example B (except for the device name tags) and adjusting
the cyl boundary to 538/539 and have seen only one problem due to something the
stock V1.3 Startup-Sequence likes to do, which is call Binddrivers without
having mounted anything. If you are going to do that, you'd best use an
AmigaDOS format for the first partition, or try some variant of the pre-mount
Startup-Sequences included as examples below.
Once you have modified the MountList to contain something like either of the
above two examples, you are ready to re-do the prep manually. I recommend
that the prep be done directly from the DF0: boot configuration _before_ the
Amiga has had a chance to read anything from the Startup-Sequence. Put the
workbench disk in DF0:, Control Amiga Amiga (or Control Cluck Cluck) and then
start hitting Control D repeatedly until the boot CLI announces BREAK. Now
you have to Mount the reserved device (RES2:) and all partitions _beyond_
the first partition, and then call binddrivers. For the examples above,
it would look like this:
SetPatch >NIL:
SetClock >NIL: Load
Mount RES2:
Mount DP2:
Binddrivers
The Binddrivers command should result in a short disk access. Then you must
issue the command
Prep RES2:
to get the following dialogue:
PREP Version 33.34
0) User defined
1) SCSI
2) ST506
Select drive type [1]: 0
Number of heads [4]: 6
Number of cylinders : 739 /* or 882 */
Number of sectors per track [17]: 37 /* or 31 */
Write pre-comp cylinder [739]: 739
/* or ... cylinder [882]: 882 */
/* for ex A. with 882 tracks */
Do you want the heads parked automatically after
3 seconds of inactivity ? [Y/N] : N
/* The Q80S seems to park the heads after 30 seconds or so on its own */
Last cylinder used by first partition
(range 2 to [default]) [738]: 258 /* ex A. or 199 for ex B. */
/* or ...to [default]) [881]: 308 ex A. 882 tracks */
Number of AmigaDOS sector buffers [30]: 128 /* anybody's guess? */
/* Maybe 32 per 20 Megabytes, eh? */
Would you like to mark any blocks on the disk as bad ? [Y/N] : N
/* Unless, of course, you have a bad block list... */
Continuing will destroy any information on the
entire physical device, and the system will have to be rebooted.
Do you wish to proceed ? [Y/N] : Y /* You must override N to proceed! */
One long flash on the green LED, followed by a buncha short ones would be
a normal prep response here - shouldn't take more than a few seconds.
After that, Prep announces success, tells you that you must reboot the
machine before proceeding, and bails out. I have found that I can
repeat the Prep command even after formatting the disk and copying in files,
without losing files AS LONG AS THE RESPONSE TO ALL THE PREP QUESTIONS IS
COMPARABLE TO THE ORIGINAL PREP and THERE HAVE NOT BEEN ANY CYL CHANGES IN
the MountList. But you can't adjust the partition width or cylinder counts
without going through the whole works from the beginning - Prep, Format,
Copy, grind grind...
Since the MountList is at this point correct (hopefully) and the Prep is
done, the only thing left to do (before ordinary formatting) is fix the
Startup-Sequence. As stated above, if you use the Startup-Sequence that
comes with the Workbench, it will binddrivers and will mount RES2: and the
first partition, (DH2:). You will get a "Not a DOS Disk" response if you
try to do anything with DH2:, and AmigaDOS will hang the Validator on it if
there is anything there at all (such as a former FFS partition). So either
fix the Startup-Sequence before you do the reboot, or Control D the reboot
and issue the following instructions in order to get to where you can then
format the partitions:
SetPatch >NIL:
SetClock >NIL: Load
Mount DH2:
Mount DP2:
Binddrivers
Format drive DP2: name HD1 /* or whatever you want */
/* This will take some fraction of an hour */
Format drive DH2: name HD0 noicons /* or whatever you want */
/* This also will take some fraction of an hour */
The file system name you choose above will appear under the disk icon
on the workbench as soon as you do anything to access the partition
(i.e. Dir HD0: ). But remember in the future that you may go so far as
to Mount partitions and Binddrivers without them showing up in either the
Info command tabulation, or on the workbench until they have been accessed
by an AmigaDOS command. Once the partitions are formatted, I recommend
that you examine the V1.3 Workbench s/Startup-Sequence.HD as an example
of how to handle a hard disk with an AmigaDOS first partition. If your
first partition is an FFS partition, you may want to do something like
what I have in the following examples:
DF0:s/Startup-Sequence :
; Startup sequence for Hard Disk users...checks for hard disk, then
; transfers control if it is present. (The script assumes DH2:)
; TO USE: copy your normal startup-sequence files (Startup-Sequence,
; and StartupII to the S: directory of your hard disk.
; Then rename your normal Startup-Sequence file
; as Startup-Sequence.f in the S: directory of the floppy, just in case.
; Now replace the Startup-Sequence file on the floppy with this file.
;
SetPatch >NIL:
Dir >NIL: RAM:
Mount DH2:
Mount DP2:
Binddrivers
Assign >NIL: DH2: exists
IF NOT WARN
; hard disk is present
Assign sys: DP2:
Assign c: SYS:c
Assign L: SYS:l
Assign FONTS: SYS:fonts
Assign S: SYS:s
Assign DEVS: SYS:devs
Assign LIBS: SYS:libs
If EXISTS ram:tr
Assign t: ram:tr
Else
Makedir ram:tr
Assign t: ram:tr
EndIf
Execute s:Startup-Sequence
ELSE
; no hard disk
Execute s:Startup-Sequence.f
EndIf
HD1:s/Startup-Sequence :
Echo "A500/A2000 Workbench disk. Release 1.3 version 34.20*N"
SetClock Load
arun Bar_Mon NOIO
cd c:
List >NIL: DH2:.info
List >NIL: DP2:.info
FF >NIL: -0 ;speed up Text
Mount SPEAK: ;just mounting doesn't take much ram at all
Mount AUX:
Mount PIPE:
SYS:System/SetMap usa1 ;Activate the ()/* on keypad
Path ram: c: sys:system s: add ;set path for Workbench
CD sys:
Copy Disk.info ram:
LoadWB delay ;wait for inhibit to end before continuing
Shell c:.login
Of course you can tell that these sequences are oriented toward use of the
V3.01 CSH Shell and the arp.library rather than NewShell and the AmigaDOS
Resident commands. It shouldn't be too difficult to imagine what they'd
look like if they were written to use StartupII. I don't think I need to
comment concerning the content of Startup-Sequence.f, as the example in the
s directory of the V1.3 Workbench can be modified to whatever are your
default desires should come the sweet day that your Q80S no longer responds
to the kind and gentle probing of Binddrivers...
So what about the LED, you ask... Weeeellll... I did some looking around
on the A2090A with an oscilloscope to see what the complaints concerning
the J4 and J5 attachment of the green A2000 HARD DISK indicator were all
about. As has been reported earlier by some of those close to CBM, the
J5 position is for an installation with an ST506 hard disk. I can't now
remember which one is which, and I don't want to take my A2000 apart again.
I don't know what you do if you have both ST506 and SCSI either, because
I don't have an ST506 disk to use to find out. What I did find out is that
if I attach the LED plug so that the red wire is on the upper terminal of
the front pair of posts and black wire is on the the lower terminal of the
front pair of posts, I can see the LED come on _weakly_; it would be ok
in a room with dim lighting (such as is needed to combat flicker) when the
SCSI disk is accessed. From that I surmise that the top front post is being
driven by a low power gate of some kind (I didn't bother to trace it out).
It is conceivable that with extended service of this sort the gate could
fail with a LED for a load - though I think it's not too likely to fail.
The main objection is that it is just not bright enough to use that way.
It is the correct LOGICAL signal (goes to +4.7v during accesses, drops to
below 1.2v during idle). However, it needs to be followed by a buffer and
some other parts in order to drive the A2000 "HARD DISK" LED properly.
When I can get around to it (and if I get more hard disks, possibly an
ST506 hard disk), I'll glue an OC buffer/inverter to the back of the
indicator platform, send +5v and ground up there for pins 14 and 7 of the
buffer/inverter, respectively, put the red plug wire on pin 1, tie a 150 ohm
1/4 watt resistor from +5 to the LED's red wire, and connect the LED's black
wire to pin 2 of the OC buffer/inverter. That should solve the problem.
For now I decided to do what a number of others have done - connect across
the Q80S hard drive LED terminals.
Of course I had to chop the LED out of the drive, and that will do it for my
Q80S warranty, unless I can figure out how to get another LED back in there
without it being ever so noticeable. :-) So let me wish you GOOD LUCK if
you want to try this adventure on your own, and I hope this write-up does
you all some good!
Howard Hull
hull@hao.ucar.eduandy@cbmvax.UUCP (Andy Finkel) (03/30/89)
In article <1654@ncar.ucar.edu> hull@hao.ucar.edu (Howard Hull) writes: >This is a long article about the Quantum Q80S/A2090A PREP and Format. >In summary, thanks to net articles by several contributors, I was able to >figure out what to do, and I now have a working 80 meg hard drive in my Thanks for the article. I plan to pass it on to the documentation group. They should find it interesting as well. andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "Give me a Standard large enough, and a Committee to discuss it, and I will prevent the Earth from moving." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.