Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!voder!apple!landon
From: landon@apple.UUCP (Landon Dyer)
Newsgroups: comp.sys.atari.st
Subject: Re: Spinning disk HD boot
Message-ID: <7232@apple.UUCP>
Date: 21 Jan 88 02:34:51 GMT
References: <593@ihnet.ATT.COM>
Organization: Apple Computer, Inc., Cupertino, USA
Lines: 49
Keywords: Spinning

In article <593@ihnet.ATT.COM>, bryan@ihnet.ATT.COM (b. k. delaney) writes:
> 
> When you use AHDI to boot off of a hard disk you should have a floppy disk
> in drive A.  The ST will not boot off of this disk unless it has a boot 
> sector on it.  With a formated disk in drive A the ST will boot Very quickly
> from the hard disk. I usually keep a copy of "SHIP.PRG" on drive A, which
> I usually run before I turn off the HD.  Note be sure there are no open
> windows to the Hard Disk when you run SHIP.PRG.  As for why the light stays
> on, I can only guess it has to do with the fact the ST is trying to read
> drive A when no disk is in drive A, and therefore is getting some sort of
> read/drive error.

The vbl routine that does floppy-disk deselection checks if the DMA
chip is in use.  If it's busy, the vbl can't do the deselect.

Also, some drives don't return INDEX pulses unless a disk is inserted.

> Unlike MS-DOS system The ST looks for a BOOT sector first at the Cartridge 
> Port then on Drive A, Drive B then it looks for a Boot sector on DMA Logical
> Unit 1 (The Hard Disk), If it finds a boot sector on drive A it boots drive A
> and If It Does not Find a boot Sector on Drive A it looks else where until it
> finds a Boot Sector.  When you Instal AHDI you are actually installing a Boot
> Sector on the Hard disk.

Not quite.  The startup sequences goes more like:

	<various ways of starting up a cartridge, too baroque to mention here>
	<attempt to boot from drive A>
		(it might load and execute code, then continue, or it could
		 take over the system)
	<attempt to boot from ACSI devices 0..7>
		o the first one "wins", because:
		o non-blitter ROMs have a nasty boot bug that causes the
		  system to lock-up when reading device 1, if device 0
		  exists.  "Fixed" by boot-stopper code written to device
		  0's boot sector that halts booting on the first device
		  with this code.
	<run the AUTO folder on the boot drive>
	<bring up the desktop>

In bootable AHDI, the last two steps are actually performed by the
driver loaded from the hard disk.  I also forget when RAM packages are
executed (just before the AUTO folder, I think) but I know that they
don't happen with AHDI, but they do with the ROM.  Allan?


-Landon
-- 

I speak for me.