Path: utzoo!mnetor!uunet!portal!cup.portal.com!flex
From: flex@cup.portal.com
Newsgroups: comp.sys.atari.8bit
Subject: Re: Booting up without AUTORUN.SYS
Message-ID: <4254@cup.portal.com>
Date: 1 Apr 88 09:16:28 GMT
References: <284@buengc.BU.EDU>
Distribution: na
Organization: The Portal System (TM)
Lines: 69
XPortal-User-Id: 1.1001.4063


Hmmm, didn't know that there were any Atari 8-biters left out there...!

Anyways, concerning creating Boot Load Disk programs. The best place for a
technical reference is The Atari Technical Reference Notes -- a collection of
usage notes written by the creators of the Operating System themselves. This
pre-dates the acclaimed De Re Atari and of course OSS's Inside Atari DOS. In
fact these reference notes were internal Atari Corp documents, later released
to the public. 

Oh well, here's the "Great Secret". Heh.
    
The normal Atari disk format (single density) consists of 720 sectors, of
which only 719 is used by DOS (a boo-boo, but dats another story!). When the
Atari is Cold-Booted connected to a disk, the OS will attempt (among other
things) to "boot" from the disk drive. The OS will read in Disk Sector #1 into
its Cassette Buffer at $0400 (yea crazy, but so what.)

Of this 128 byte record, only the first SIX bytes have any initial signi-
ficance: 

 BYTE #1    Boot Flag     Thrown away by the OS due to meaness, stored at 
                          DFLAGS $0240 for fun while its at it.

 BYTE #2    Rec to read   The number of sequential disk sectors (records)
                          to read in after this initial read. DBSECT $0241

 BYTE #3,4  Load Address  Where to move this boot sector (#1) in memory
                          following the Lo,Hi 6502 word address format.
                          Saved in BOOTAD $0242.

 BYTE #5,6  Init Address  The Initialization Address (Lo,Hi) for this prog.
                          Saved in DOSINI $C

So after the Atari looks at these first SIX bytes of Disk BOOT Sector (#1)
then it goes like how you expect. This first record (#1) is moved to the
address specified by BOOTAD. Then the OS will read in sequentially (like
Disk Sector #2 and on...) the number of sectors (also called records) as
specified by DBSECT. As one can figure out, DBSECT is decremented
internally by one till a BEQ state exists. So an initial value of ZERO for
DBSECT allows 256 sectors to be read in. Remember this is jus a boot load,
and a small program can be read in to read in additional disk sectors in
any order, to any address. This is called a multi-boot process.

As a side note, you may be a wonderin how in the world one can write a
program to read in additional disk sectors after the inital boot process,
without DOS present?

Well, how da ya think the OS can read in the boot sector in the first
place...? Yup, there is a Resident Disk Handler in the OS that is a low-
level access of a disk (lower than CIO... actually called SIO for Serial
Input/Output, but dats still another story).

So dats about it. The OS reads in the required amount of sectors and
stores it anywhere in memory, as specified by BOOTAD. When Atari DOS 2.0
gets booted in, the BOOTAD is set at $700. But as you have seen, it can
be anywhere in memory a programmer chooses.

Oh yea. After the initial boot disk load ends, what happens? Well, FIRST
the OS will AUTOMATICALLY jsr to BOOTAD+6. This "feature" to befuddle the
masses is called a multi-stage boot. Jus do a CLC/RTS combo to get it
outta here correctly. After this, the OS will then jsr to DOSIN.
And dat is where your boot loaded program should be!

Opps, in the jsr to DOSIN coding, a RTS will push the OS to JMP to
DOSVEC ($A), so ya better set DOSVEC in ya code to an address. However,
a RTS in your DOSIN coding ain't necessary.

If anyone has anymore questions about this, or about Atari 8-bits in
general, jus leave a note!