Path: info.curtin.edu.au!uniwa!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!sdd.hp.com!portal!cup.portal.com!ScottM
From: ScottM@cup.portal.com (Scott - Maxwell)
Newsgroups: comp.sys.apple2.programmer
Subject: Disk booting
Message-ID: <92720@cup.portal.com>
Date: Fri,  8 Oct 93 20:29:03 PDT
Organization: The Portal System (TM)
Lines: 13

Could someone describle the disk boot process for the Apple // to me?
(DOS 3.3 and ProDOS)
I know this information is most likely contained in one of the technical
manuals but I don't have them (yet).
Any help greatly appreciated.

/==============================================================\
|Scott Maxwell         * This is my mistake,                   |
|scottm@cup.portal.com *       let me make it good - R.E.M.    |
|Amiga 1000, 2000,     *---------------------------------------|
|1200, Pet 2001, Vic,  * I sit at my table,                    |
|64, 128D, 800XL, //e  *    and wage war on myself - R.E.M.    |
\==============================================================/

Path: info.curtin.edu.au!uniwa!munnari.oz.au!spool.mu.edu!uwm.edu!cs.utexas.edu!not-for-mail
From: robertf@pro-lep.cts.com (Robert Fletcher)
Newsgroups: comp.sys.apple2.programmer
Subject: Re: Disk booting
Date: 9 Oct 1993 07:35:13 -0500
Organization: The Texas Leprechaun BBS, Austin, Texas
Lines: 8
Sender: daemon@cs.utexas.edu
Message-ID: <1993Oct9.065534.936@pro-lep.cts.com>
NNTP-Posting-Host: cs.utexas.edu

  If you are talking about a keyboard boot, you could do the Control-Open
Apple-Reset.
_____

UUCP: cs.utexas.edu!wixer!pro-lep!robertf
ARPA: pro-lep!robertf@wixer.bga.com
INET: robertf@pro-lep.cts.com


Path: info.curtin.edu.au!uniwa!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!math.ohio-state.edu!magnus.acs.ohio-state.edu!valthoff
From: valthoff@magnus.acs.ohio-state.edu (Victoria M Althoff)
Newsgroups: comp.sys.apple2.programmer
Subject: Re: Disk booting
Date: 10 Oct 1993 03:52:35 GMT
Organization: The Ohio State University
Lines: 78
Message-ID: <2980u3$b84@charm.magnus.acs.ohio-state.edu>
References: <92720@cup.portal.com>
NNTP-Posting-Host: bottom.magnus.acs.ohio-state.edu


I don't have COMPLETE and DETAILED information, but I think I can give a 
GENERAL description of what happens in a Disk ][ (5.25") drive during a boot.  
Detailed data can be found in BENEATH APPLE DOS.  Note that my information is 
based on DOS 3.3.

For a cold start, the computer firmware checks the slots, beginning with Slot 
#7 and going backwards, searching for a disk controller card.  This is where 
the Autostart ROM (A][+ and up) differs from the old Monitor ROM; which simply 
dumped you into the Monitor and left you to figure out how to get started.  
Anyway, Autostart ROM beeps the speaker, clears the screen, displays "APPLE 
][", "Apple ][", "Apple //e", "Apple //c", or "Apple IIgs", depending on which 
system you have.  I can't vouch for the GS, but my system just says "Apple ][".
Having said hello, Autostart then looks at each slot, beginning with #7, 
searching for a disk controller.  If it doesn't find one, it JMPs to the 
Applesoft entry point.

If a disk controller exists, control is passed to the card firmware entry point
at $Cn00.  The controller firmware starts the motor in the disk drive, then 
moves the R/W head something like 88 steps toward the outside.  Since there are
only two steps per track, and only 35 tracks per disk, this guarantees that the
head will be positioned over Track #0.

At this point, the controller firmware starts to read information...a copy of 
DOS...into memory.  Among the first items to be read are the RWTS (Read Write 
Track Sector) routine.  Once RWTS is loaded, DOS can begin to function.  The 
firmware code cannot position the head at a particular track; RWTS can.
The DOS image includes the name of the greeting program, and, if the disk is a 
System Master (meaningless now that most all systems have 48k of non-switched 
memory), a bit of DOS Relocation code.  This code puts DOS as high as it will 
go in memory, with the limitation that it cannot extend above $D000, where 
bank-switching starts.  This little bit of code allows the same disk to 
function on any size system 16k or larger.  According to the DOS Programmer's 
Manual, DOS begins by loading itself into $800, loading through a 
denibblization buffer at $200.  Once the first stage of the boot is completed 
(loading RWTS), the rest of DOS is loaded in at $1D00, where it stays if the 
system has only 16k.  On the typical 48k system, DOS gets moved up to $9D00 at 
the end of the boot process.  DOS also connects itself to the I/O hooks at 
CSW/KSW, and I think it hooks into the RESET vector at $3F2.  The boot process 
finishes by parsing out the greeting program name (stored, by the way, on Track
#2, Sector #2), and issuing a file manager command to RUN, BRUN, or EXEC that 
filename.  If the file doesn't exist, or the command is wrong (attempt to EXEC 
an Applesoft program, for example), the File Manager will return an error.  Of 
course, by this time, the boot process is complete anyway.  Likewise, if an 
attempt is made to RUN an Integer BASIC program on a ][e/][c/IIgs or a ][+ with
no INTBASIC romcard, a "LANGUAGE NOT AVAILABLE" error will be returned.  Again,
the boot process is complete at this point.

Because DOS is connected to the I/O hooks, and is located in primary memory 
where switching languages in the $D000-$FFFF range can't hurt it (on a 64k 
machine or a ][+ with a Language Card), DOS is transparent at all times unless 
you execute a DOS instruction.  If a program is not running, DOS does parse 
commands before Applesoft gets a crack at them, to identify DOS commands, and 
to prevent certain Applesoft commands (i.e. PR#) from disconnecting DOS.

According to the authors of BAG OF TRICKS (a sort of "Norton Utilities" for 
Apple DOS 3.3), the physical arrangement of the sectors on a disk is optimized 
for the boot process with a '3-descending' sector interleave.  In other words, 
the sectors are arranged:
  $F - $9 - $4 - $E - $8 - $3 - $D - $7 - $2 - $C - $6 - $1 - $B - $5 - $0 - $A
This makes the disk boot VERY fast, but it's not as efficient for everything 
else.  By changing to a '9-descending' interleave, other access becomes 
faster--in fact, I think this is part of the reason ProDOS is faster than 3.3.
But it also makes the boot process excruciatingly slow.  I have a few disks 
that compromise by using a 3-d pattern on tracks $00-$02, and a 9-d pattern on 
tracks $03-$22.  Setting this up requires a fancy initialization routine found 
(of course) in the BAG OF TRICKS.  Which, incidentally, has a manual that goes 
into some detail about how DOS works.  In fact, I think it was written by the 
same folks who wrote BENEATH APPLE DOS, since B.A.D. includes full descriptions
of all the routines in B.O.T.

There is more to this; some things I know, others I don't.  As usual, if I made
any glaring mistakes (Mr. Empson 8-)) I won't feel bad if you folks correct me.

[disclaimer:  the above specifically refers to Steve Wozniak's unsung hero, DOS
3.3, published by You-Know-Who]
--Dave Althoff, Jr.
(never affiliated with Big Beige)

Path: info.curtin.edu.au!uniwa!munnari.oz.au!spool.mu.edu!wupost!cs.utexas.edu!not-for-mail
From: robertf@pro-lep.cts.com (Robert Fletcher)
Newsgroups: comp.sys.apple2.programmer
Subject: Re: Disk booting
Date: 10 Oct 1993 11:05:59 -0500
Organization: The Texas Leprechaun BBS, Austin, Texas
Lines: 8
Sender: daemon@cs.utexas.edu
Message-ID: <1993Oct10.102417.945@pro-lep.cts.com>
NNTP-Posting-Host: cs.utexas.edu

  You two guys know it all! Guess I am going to go back and work on those
Apple books again.
_____

UUCP: cs.utexas.edu!wixer!pro-lep!robertf
ARPA: pro-lep!robertf@wixer.bga.com
INET: robertf@pro-lep.cts.com


Newsgroups: comp.sys.apple2.programmer
Path: info.curtin.edu.au!uniwa!munnari.oz.au!spool.mu.edu!wupost!waikato!comp.vuw.ac.nz!actrix.gen.nz!dempson
From: dempson@swell.actrix.gen.nz (David Empson)
Subject: Re: Disk booting
Organization: Actrix Information Exchange
Date: Sun, 10 Oct 1993 06:37:49 GMT
Message-ID: <CEo532.32@actrix.gen.nz>
References: <92720@cup.portal.com> <2980u3$b84@charm.magnus.acs.ohio-state.edu>
Sender: dempson@actrix.gen.nz (David Empson)
Lines: 190

In article <2980u3$b84@charm.magnus.acs.ohio-state.edu> valthoff@magnus.acs.ohio-state.edu (Victoria M Althoff) writes:
> 
> I don't have COMPLETE and DETAILED information, but I think I can give a 
> GENERAL description of what happens in a Disk ][ (5.25") drive during a boot.  
> Detailed data can be found in BENEATH APPLE DOS.  Note that my information is 
> based on DOS 3.3.

An excellent description, IMHO.  I have a few details/corrections to add:
 
> [early disk booting up to RWTS load]

> According to the DOS Programmer's Manual, DOS begins by loading
> itself into $800, loading through a denibblization buffer at $200.
> Once the first stage of the boot is completed (loading RWTS), the
> rest of DOS is loaded in at $1D00, where it stays if the system has
> only 16k.  On the typical 48k system, DOS gets moved up to $9D00 at  
> the end of the boot process.

I just wanted to add that this only happens on a DOS 3.3 Master disk.
On a slave disk (created with the INIT command), DOS and RWTS are
loaded directly to the appropriate memory position ($9D00 if the disk
was initialized on a 48k system).

To create a master disk, use the MASTER.CREATE program on the DOS 3.3
system master.  I doubt that there are any Apple IIs with less than
48k of RAM, so it probably not worth worrying about...


> The boot process finishes by parsing out the greeting program name
> (stored, by the way, on Track #2, Sector #2), and issuing a file
> manager command to RUN, BRUN, or EXEC that filename. 

It doesn't do any parsing - the filename is pre-loaded into the DOS
3.3 filename buffer, and the cold start code is hard-coded to do a RUN
command on the filename that is already in the buffer.

If you want to do a BRUN or EXEC, you have to patch the command code
used by the cold start code.

> According to the authors of BAG OF TRICKS (a sort of "Norton Utilities" for 
> Apple DOS 3.3), the physical arrangement of the sectors on a disk is optimized 
> for the boot process with a '3-descending' sector interleave.  In other words, 
> the sectors are arranged:
>   $F - $9 - $4 - $E - $8 - $3 - $D - $7 - $2 - $C - $6 - $1 - $B - $5 - $0 - $A
> This makes the disk boot VERY fast, but it's not as efficient for everything 
> else.  By changing to a '9-descending' interleave, other access becomes 
> faster--in fact, I think this is part of the reason ProDOS is faster than 3.3.

Partially.  The main reason for the extra speed is that ProDOS reads
two sectors at a time, and it does the de-nibbilizing while reading
rather than going through a buffer and then doing a de-nibbilizing pass.

> There is more to this; some things I know, others I don't.  As usual,
> if I made any glaring mistakes (Mr. Empson 8-)) I won't feel bad if
> you folks correct me.

[I started replying before I read that line.  :-)]

Good description overall!


I may as well add an abbreviated summary of how ProDOS boots.


The early stage is the same as DOS 3.3: the Autostart ROM searches the
slots for something that looks like a disk drive.

[An aside: the ID bytes searched for are:

$Cn01 = $20
$Cn03 = $00
$Cn05 = $03
$Cn07 = $3C

The last byte is only checked on the II+ and unenhanced IIe.
SmartPort devices have a $00 in this byte, which is why they won't
auto-boot on a II+ or unenhanced IIe.]

For a 5.25" drive, track 0, sector 0 is loaded.  This is the first half
of ProDOS block 0.

For other devices, all of block 0 is loaded.

The ProDOS boot code checks which sort of disk drive it booted from
(by looking at $CnFF, which contains $00 for a 5.25" drive, and a
non-zero value for any disk device with a ProDOS block driver).

If it was booted from a 5.25" drive, only half the boot sector is
present.  It patches itself and uses the disk boot code to read
sector 2 (the second half of block 0) at $0900.  The code that was
loaded from the first sector is then re-used, but the patch causes it
to bypass the code which loads the second sector.

The entire contents of block 0 are now in memory.  For a 5.25" drive,
further code is now executed which takes a copy of the disk read code
from the controller card, and patches it.  There is some code in the
boot block which performs track stepping, and this is combined with
the code from the controller card to form a routine which can read any
block from the disk.

This is not needed for other devices - there will be a ProDOS block
driver on the card which is called directly.

[Another aside, regarding byte 0 of sector 0:

On a 5.25" disk, this byte is used by the boot code to specify how
many sectors are to be read by the boot process.  It is normally 1.
Note that physical sector numbers are used, which means the sectors
are not loaded into memory in the same order as they would be if
loaded by RWTS or ProDOS.

On a 3.5" disk, this byte must be $01, or the boot code in the card
will not recognise this as a bootable disk.

On the IIc and IIgs, and certain SmartPort cards, if the disk is
unreadable or doesn't contain $01 in the first byte, then the boot
code will cause the next slot to be scanned by JMPing back to the
autostart boot code in the monitor.]

For all devices, the boot block now reads the directory blocks (2
through 5) into memory (I can't remember the address) and searches
through the directory for an active entry which has the filename
PRODOS and filetype $FF (SYS).  The PRODOS file _must_ be a SAPLING
file (one level index block) but I don't think the boot code checks
this.

If this entry is found, the key block of the file is read into memory,
and each block from the file is read in turn into memory starting at
$2000.  The boot code then does a JMP $2000, and the PRODOS file takes
over.

If the PRODOS file wasn't found, the "unable to load PRODOS" message
is printed and the boot code goes into an infinite loop.

[The following applies to ProDOS 1.1 and later.  ProDOS 1.0.x was able
to relocate itself to the top of the 48k memory space as well as the
language card.]

I am not all that familiar with the interior workings of the PRODOS
file during the boot process, but the various tasks it performs include:

- identifying the machine on which it is running
- building up the system global page at $BF00
- copying the various components of the ProDOS Machine Language
Interface into the language card, along with the drivers for /RAM and
the appropriate clock (ThunderClock or IIgs clock [1.2+]), the 5.25"
driver, and the appropriate version of the Quit code [1.9+].
- building the device driver list in the global page.

With ProDOS-8 2.0 and later, PRODOS also checks that the computer has
a 65C02 microprocessor, and searches for SmartPort devices.  If any
are found, and they have more than two devices, then the extra devices
are added in spare unit numbers in the device driver table.  An
internal table, used to map the unit numbers back to SmartPort device
numbers, is also updated.

Any error during the configuration steps will result in a
"relocation/configuration error" message being displayed.

PRODOS now reads the directory and searches for the first SYS file
(type $FF) with name ending in ".SYSTEM".  It loads this file into
memory at $2000, sets up the program's pathname at $0280, and does a
JMP $2000.

For BASIC.SYSTEM, it will relocate itself up to the top of memory
($9E00 to $BEFF), hook itself into various system vectors (CSW, KSW,
reset vector, etc.) and initialize Applesoft.

When Applesoft has finished (by printing the ] prompt), BASIC.SYSTEM
regains control, turns on Applesoft TRACE mode (used to keep track of
program execution) and loads the startup file.

With BASIC.SYSTEM 1.1 and later, the name of this file is stored in a
buffer near the start of BASIC.SYSTEM.  It is STARTUP by default.
BASIC.SYSTEM checks that the file exists, and if so executes it using
the equivalent of the "smart run" command.

If the file does not exist, BASIC.SYSTEM just prints up a title and
returns control to Applesoft.


I think that about covers it.  If anyone has any corrections, feel
free to add them.

GS/OS is much more complicated (and its PRODOS file is completely
different).  I can exlain that if anyone is interested.
-- 
David Empson                                                               
dempson@swell.actrix.gen.nz                                                
Snail mail: P.O. Box 27-103, Wellington, New Zealand 

Path: info.curtin.edu.au!uniwa!munnari.oz.au!mel.dit.csiro.au!its.csiro.au!dmssyd.syd.dms.CSIRO.AU!news.cs.uow.edu.au!news.cs.uow.edu.au!not-for-mail
From: david@wraith.cs.uow.edu.au (David E A Wilson)
Newsgroups: comp.sys.apple2.programmer
Subject: Re: Disk booting
Date: 11 Oct 1993 12:07:30 +1000
Organization: University of Wollongong, NSW, Australia.
Lines: 17
Message-ID: <29af52$qiq@wraith.cs.uow.edu.au>
References: <92720@cup.portal.com> <2980u3$b84@charm.magnus.acs.ohio-state.edu> <CEo532.32@actrix.gen.nz>
NNTP-Posting-Host: wraith.cs.uow.edu.au

dempson@swell.actrix.gen.nz (David Empson) writes:

>PRODOS now reads the directory and searches for the first SYS file
>(type $FF) with name ending in ".SYSTEM".  It loads this file into
>memory at $2000, sets up the program's pathname at $0280, and does a
>JMP $2000.

>I think that about covers it.  If anyone has any corrections, feel
>free to add them.

All that I can see missing is that before PRODOS searches for the first .SYSTEM
file it tries to open and read ATINIT. If it can and it is of type $E2 it
JSRs to it (@ $2000). This sets up Appletalk if you have a //gs or a //e with
workstation card. This is for P8 v1.2 and higher.
-- 
David Wilson				+61 42 213802 voice, +61 42 213262 fax
Dept Comp Sci, Uni of Wollongong	david@cs.uow.edu.au

Path: info.curtin.edu.au!uniwa!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!portal!cup.portal.com!ScottM
From: ScottM@cup.portal.com (Scott - Maxwell)
Newsgroups: comp.sys.apple2.programmer
Subject: Re: Disk booting
Message-ID: <93129@cup.portal.com>
Date: Thu, 14 Oct 93 00:53:28 PDT
Organization: The Portal System (TM)
References:  <1993Oct10.102417.945@pro-lep.cts.com>
Lines: 9

Thanks to all who responded. You've been a great help.

/==============================================================\
|Scott Maxwell         * This is my mistake,                   |
|scottm@cup.portal.com *       let me make it good - R.E.M.    |
|Amiga 1000, 2000,     *---------------------------------------|
|1200, Pet 2001, Vic,  * I sit at my table,                    |
|64, 128D, 800XL, //e  *    and wage war on myself - R.E.M.    |
\==============================================================/

Newsgroups: comp.sys.apple2.programmer
Path: info.curtin.edu.au!uniwa!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!tarpit!bilver!vicstoy!aphelps
From: aphelps@vicstoy.UUCP (Austin Phelps)
Subject: Re: Disk booting
Message-ID: <1993Oct14.010105.14669@vicstoy.UUCP>
Organization: vicstoy public access Unix, Orlando, FL
References: <92720@cup.portal.com> <2980u3$b84@charm.magnus.acs.ohio-state.edu> <CEo532.32@actrix.gen.nz> <29af52$qiq@wraith.cs.uow.edu.au>
Date: Thu, 14 Oct 1993 01:01:05 GMT
Lines: 14

In article <29af52$qiq@wraith.cs.uow.edu.au> david@wraith.cs.uow.edu.au (David E A Wilson) writes:
>All that I can see missing is that before PRODOS searches for the first .SYSTEM
>file it tries to open and read ATINIT. If it can and it is of type $E2 it
>JSRs to it (@ $2000). This sets up Appletalk if you have a //gs or a //e with
>workstation card. This is for P8 v1.2 and higher.

Does this work on a GS using System 6.01 or is Appletalk already set up
under System 6?

-- 
  Austin Phelps - aphelps@vicstoy.oau.org -or- tf3@delphi.com 
           UUCP - {peora,ge-dab,tous,tarpit}!bilver!vicstoy!aphelps
                - vicstoy Public Access Unix, Orlando FL
                - (407)299-3661  1200/2400/9600 V.32  24 hours  8N1

Newsgroups: comp.sys.apple2.programmer
Path: info.curtin.edu.au!uniwa!munnari.oz.au!comp.vuw.ac.nz!actrix.gen.nz!dempson
From: dempson@swell.actrix.gen.nz (David Empson)
Subject: Re: Disk booting
Organization: Actrix Information Exchange
Date: Fri, 15 Oct 1993 12:55:34 GMT
Message-ID: <CExvwn.IAE@actrix.gen.nz>
References: <CEo532.32@actrix.gen.nz> <29af52$qiq@wraith.cs.uow.edu.au> <1993Oct14.010105.14669@vicstoy.UUCP>
Sender: dempson@actrix.gen.nz (David Empson)
Lines: 30

In article <1993Oct14.010105.14669@vicstoy.UUCP>
aphelps@vicstoy.UUCP (Austin Phelps) writes:
> In article <29af52$qiq@wraith.cs.uow.edu.au>
> david@wraith.cs.uow.edu.au (David E A Wilson) writes:
> >All that I can see missing is that before PRODOS searches for the
> >first .SYSTEM file it tries to open and read ATINIT. If it can and
> >it is of type $E2 it JSRs to it (@ $2000). This sets up Appletalk if
> >you have a //gs or a //e with workstation card. This is for P8 v1.2
> >and higher. 
> 
> Does this work on a GS using System 6.01 or is Appletalk already set up
> under System 6?

Nope.  GS/OS has a completely different method of setting up
AppleShare, through several INITs.

When you launch ProDOS-8, the MLI vector is patched to the ProDOS
Filing System portion of the AppleShare code, which was loaded as part
of the GS/OS boot sequence.

If there is an ATINIT file in the root directory, it will be ignored
by GS/OS (and by ProDOS-8, if it was started by GS/OS).

I think GS/OS has its own copy of ATINIT in SYSTEM/SYSTEM.SETUP.  It
is used to store AppleTalk settings (such as user name, printer
network name, etc.)
-- 
David Empson                                                               
dempson@swell.actrix.gen.nz                                                
Snail mail: P.O. Box 27-103, Wellington, New Zealand 

