Z4648252@SFAUSTIN.BITNET (Z4648252) (05/04/89)
Mr. Pratt writes [in respone to a letter regarding new TOS 1.4 and
"auto hard drive" sequencing during power up:
"Might be a good idea, but how long do you wait? If the computer and the
drive both power up at the same time, the hard drive may not reset
properly. Some drives need to be allowed to do the whole power-up
sequence before they can take any commands or data, even just
request-sense (status) commands."
Typically, the SH204 takes no longer than 15 seconds and I've seen one
ready to run after only eight seconds. The sequencer that I've been
referring to has user-adjusted time delays for those users who want to
chop off the 15 second wait.
When a power failure occurs, the hard drive and computer come back on-
line, with NO operator/user intervention.
"If you put AHDI.PRG in the \AUTO\ folder
of a floppy, and put another program BEFORE that in the AUTO folder
which delays by 30 seconds (or whatever it takes), you could be in
business without any sequencer."
"The ROMs will look for a hard disk, not
find one, and boot off the floppy. By the time the delay has elapsed
and AHDI loads, the drive is ready. Give that a try."
Sure wish that it would work that way, but it doesn't, at least on
my SH204 and Mega2 and on three BBS's that I tested all of this on. Besides
that, you would have to keep a 'startup' disk in the floppy drive.
C'mon, we've got one of the fastest hard drive systems on the computer
market, why can't we auto sequence the thing within the OS?
When the user powers-up with both the hard drive and the ST on, and
with AHDI.PRG in the \AUTO\ folder of a system floppy and so forth, the
two pieces of equipment will duke it out with each other. You will get
a hard-drive-less desktop and a frozen red light on the hard drive.
There is no way around it. The user HAS to power up first the hard
drive and no later than 15 seconds later, power up the ST.
I am amazed that the new TOS 1.4 can't detect on a data line during
the hand shake sequence that the drive is not ready. Other computer
systems allow this (IBM clones). For BBS operators, the requirement for
operator intervention is a pain especially if a power failure occurs
and he wants the system to come back on-line automatically.
Other than the use of the hard drive sequencer which I've mentioned
earlier, one can try taking a text file, rename it as an accessory, and
then try it as a cold booter. With luck, the text file will mess things
up so much that the system will indeed cold boot. Have the accessory on
a system floppy dedicated for cold booting. After about three reboots,
the hard drive will be up to speed and will then intervene and all will be
right with the world.
I've used this with no problem but hate it. I prefer using the hard
drive sequencer which DOES work and is in use on several STs. But, I'd
prefer TOS 1.4 doing all of this instead via data line detect.
Sorry about the rambling letter but I use many different computers
including a mainframe and think that the ST has a very workable hard drive
setup. We just need to make it automatic like the others. SIGH
Larry Rymal <Z4648252@SFAUSTIN.BITNET>apratt@atari.UUCP (Allan Pratt) (05/10/89)
I give in. Please report us to the Better Business Bureau for Abuses and Criminal Neglect of Hard-Disk Start-up Sequences. Yes, we could issue the "Test Unit Ready" command to the controller, and if there's no response, then there's no controller. If there is a response, and it's negative, we can keep asking until it's positive. However, there's still a timeout -- it may be that the controller is getting power but the drive unit is not, so it'll NEVER be ready. How long do you propose we wait? At any rate, it's too late for TOS 1.4. Sorry. Use your "text file causing reboot" trick. Or, you can do it properly: ; This program causes a warm boot. ; Un-comment the clr.l for a cold(er) boot. move.l #0,-(sp) ; get into supervisor mode move.w #$20,-(sp) trap #1 ; clr.l $420 move.l $4f2,a0 ; a0 -> OS header move.l 4(a0),a1 ; a1 -> reset handler jmp (a1) ; jump there. That's a reset. That's all there is to it. No guessing, just a warm boot. If you want a cold boot, un-comment the clr.l instruction. This will run in the AUTO folder, as an accessory, or as something you can double-click from the Desktop or start from a shell. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
kloppen@gmdzi.UUCP (Jelske Kloppenburg) (05/13/89)
Before I here read the discussion about the harddisk startup
procedure I tried to solve the Problem. I think I can contribute
some facts.
All four SH204 Harddisks I know answer to the Test Unit Ready
command. Since months I have an own program similar SHIP.PRG
which parks the harddisk and loops with Test Unit Ready until
the harddisk is switched off.
So I tried the following: Write a bootsector for A: which loops
with Test Unit Ready until the harddisk answers, then returns
and let the ST read the bootsector of C:. On my SH204 at home
that worked fine and I was very proud having solved the problem.
Also the COLDSTRT.ACC method proposed here worked.
But (!) with two other SH204 both methods failed. So at last
I tried a bootsector which only waits half a minute - the
Test Unit Ready could have disturbed the spinup. But no,
these two SH204 did not spinup, even a reset didnt help, I had
to swich off. Apparently, as Mr.Pratt suggested, the reset
instruction in ROM start disturbs some harddisks and some as mine
endure even a looping Test Unit Ready at spinup.
When spinnig up it does not answer and then all status bits are zero.
Kloppenburg@kmx.gmd.dbp.de
UUCP: kloppen@gmdzi
In real life: Jelske Kloppenburg.