Article 11010 of comp.sys.apple2.programmer:
Newsgroups: comp.sys.apple2.programmer
Subject: Re: Apple ][ DOS Loader?
From: dempson@actrix.gen.nz (David Empson)
Date: Mon, 15 Nov 1999 10:17:50 +1300
Message-ID: <1e1b22z.186waem1w9hhwoN%dempson@actrix.gen.nz>
References: <80m9i4$4sl$1@nnrp1.deja.com>
Organization: Empsoft
User-Agent: MacSOUP/2.4.2
NNTP-Posting-Host: 202.49.157.176
X-Original-NNTP-Posting-Host: 202.49.157.176
X-Trace: 15 Nov 1999 10:17:22 NZST, 202.49.157.176
Lines: 129
Path: news1.icaen!news.uiowa.edu!news.physics.uiowa.edu!hammer.uoregon.edu!newshub.northeast.verio.net!newspeer.monmouth.com!newsfeed.clear.net.nz!usenet.net.nz!news.iprolink.co.nz!news.actrix.gen.nz!dempson
Xref: news1.icaen comp.sys.apple2.programmer:11010

OberonZ <OberonZ@hotmail.com> wrote:

> I've been trying to figure out how DOS gets loaded on an apple //.  I
> read that it looks at track $00 sector $00 and copies that into $0800.
> What then?  I'm assuming that whatever was in T$00,S$00 is what loads
> either DOS 3.3 or ProDOS (or whatever).  Is this true?

OK, lets start with a 5.25" disk.

Each operating system has its own unique code in track 0, sector 0.  In
all cases, this sector gets loaded at $0800.  The first byte is a count
of the number of physical sectors which are supposed to be read into
memory, but the interleave technique prevents this from being useful, so
it is always supposed to be set to $01.  The actual code starts at
location $0801.


For DOS 3.3, the code in this sector loads the second-stage boot loader,
which occupies sectors 1 through 9.  The second-stage boot loader
includes RWTS and code to load the rest of DOS.

The second stage loader reads track 0 sectors 12 through 15, all of
track 1, and the first five sectors of track 2.  This is the rest of
DOS, and it can now take over the boot process.

(The above description applies to a slave disk.  A DOS 3.3 Master disk
also uses code in track 0 sectors 10 and 11, which contain a relocator
to move DOS into the correct location given the amount of RAM in the
machine.)


I haven't looked at the boot process for a Pascal disk in detail, but
the main point is that the boot sector loads SYSTEM.APPLE and
SYSTEM.PASCAL into memory, and ends up invoking code in one of these,
which includes starting up the P-Code interpreter.  The boot sector
reads the directory to locate these files, and each file must be stored
in a consecutive range of logical blocks on the disk (this is a
restriction of the Pascal file system, not the boot code).


For ProDOS, the boot sector reads in logical sector 1, which forms the
second half of block 0.  Between them, this block contains code which
searches through the root directory for a file called PRODOS.  This file
must be a "sapling" file (one index block and up to 256 data blocks).
It is loaded into memory at location $2000 (standard for a SYS file) and
executed.  The file does not need to be stored in consecutive blocks.

For a 3.5" disk or other devices (e.g. a hard disk), ProDOS uses the
same boot code, but it gets loaded as a single 512 byte block by the
disk firmware.  The boot code identifies that it is not running on a
Disk ][ controller (or equivalent), so it doesn't need to load the
second half of the block itself, and can use the ProDOS block driver
provided by the firmware to load the PRODOS file.

Pascal 1.3 probably has similar code in its boot block.

> On a DOS 3.3 disk, the first 3 tracks are occupied by these
> instructions, is that the entirety of DOS?

Yes.  In fact track 2 only has five sectors used, so there is some
wasted space which can be recovered by modifying the VTOC.

Track 17 contains the VTOC (volume table of contents) in sector 0, and
the rest of the track is normally stored in sectors 1 through 15
(starting at sector 15 and working backwards).

> On ProDOS, the fist track is not completely used up (I'm assuming that
> this is because there is a file ProDOS in every disk), then are there
> leading bytes denoting it's size?

Nope.  Block 0 contains the boot loader.  Block 1 is used for the boot
loader on an Apple /// (the Apple /// SOS operating system was the basis
for ProDOS, and they share the same file system).  Blocks 2 through 5
are the root directory.  On a 5.25" disk, block 6 is the volume free
space bit map and block 7 is free.  (On a larger volume, the bitmap may
occupy more than one block.)

PRODOS is a normal file, which can be copied onto the disk using any
file copying utility.  It has no special rules as to placement.  The
only restrictions are that it must be of file type SYS, must be
assembled to run at location $2000 (or relocate itself to the
appropriate location after it loads), must be in the root directory, and
must be a "sapling" file (2 to 257 blocks, with one level of index
block).

(ProDOS also supports a single block "seedling" file, which has no index
blocks, and a "tree" file, which has a two level index, but neither of
these forms can be used for booting.)

You can create an alternate operating system or self-booting application
with no operating system by writing an appropriate SYS file and calling
it PRODOS.

For example, GS/OS when running on the ProDOS file system also uses a
boot application called PRODOS in the root directory.  In this case,
PRODOS is just a second-stage OS loader, which loads the Start.GS.OS
file and a few other files in the SYSTEM folder, before handing control
to Start.GS.OS to do the main bulk of the OS loading.

ProDOS-16 had a similar arrangment, with the PRODOS file just being the
second-stage OS loader.

> Why am I interested?  I'd like to write something that'll load my own
> OS on an apple //.  What better way to learn about OS design than to
> try to write one? :)  Besides, I learned programming on this machine,
> it only seems fitting to give something back to it. :)

I suggest you get hold of a copy of either Beneath Apple DOS or Beneath
Apple ProDOS (or both), which describe the boot process (and most of the
other details) of these operating systems in quite some detail.

Both are probably still available from Byte Works (E-Mail
MikeW50@aol.com).


If you are intending to write your own boot sector or boot block code,
there are quite a few details you need to know, particularly the use of
certain zero page locations to keep track of which slot is being booted.

It will be a lot easier if you avoid supporting 5.25" disks, since you
can use the SmartPort or ProDOS block driver provided by the firmware
for all other cards, and you don't need to write your own equivalent of
RWTS (low level sector read and write, plus track stepping and disk
initialization).

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P O Box 27-103, Wellington, New Zealand