I: Atari Boot Flowchart
PART III
THE ULTIMATE VIRUS KILLER BOOK APPENDICES
I - ATARI TOS COMPUTER BOOT FLOWCHART
During a power-up of your system, or after pressing its reset
button, the Operating System takes over and does a whole lot of
things that will eventually result in your being able to work on
a GEM desktop.
This appendix covers more or less exactly what happens. It will
also indicate the spots where viruses usually perform some of
their potentially dangerous perpetrations. This flowchart will
have slightly differing specs in the cases of MEGA STE, TT or
Falcon, but will largely be the same. Do note that this summary
is of a rather technical nature and that only some of the more
difficult phrases/words may be found in the glossary (appendix
J).
STEP 1 - RESET
The system is reset.
STEP 2 - DIAGNOSTIC CARTRIDGE TEST
The program counter (PC) gets a value of $FC0000 (or $E00000 in
the case of an STE, TT, Falcon or ST Book); the Supervisor Stack
Pointer (SSP) gets a value of $FC0004 (or, indeed, $E00004). All
interrupts are disabled and the RESET command is performed (this
is an 68000 mnemonic command for the hardware registers of the
peripherals).
Should a diagnostic cartridge be present in the cartridge
expansion port of your computer the program will load a 'return
address' in register A6 and execute the diagnostic software. A
diagnostic cartridge is recognised as such when the first
longword in memory space allocated to cartridges (which starts at
$FA0000 and runs up to $FBFFFF) contains the value $FA52255F.
This is the trick that many 'freeze frame' hardware and hacking
cartridges use. The Operating System has not yet bothered
clearing memory and all is still like it was when the reset
button was pressed.
When your computer is equipped with a 68030 or 68040 CPU, the
CACR, VBR, TC, TT0 and TT1 registers are initialised. If a
Floating Point Coprocessor (FPC) is installed, it is also
initialised.
STEP 3 - INITIALISATION OF THE MEMORY CONTROLLER
Here, the Operating System checks whether a 'warm reset' has
occurred. It establishes this by checking if two system variables
(memvalid on $420 and memval2 on $43A) have specific 'magic
longwords' in them ($752019F3 and $237698AA respectively). When
these are found, it assumes that memory has already been
installed properly (before a reset was done), and it will
transfer the value contained in the memcntrl system variable (at
$424) to the memory configuration registers at address $FC8001.
This does not happen if a 'cold reset' (power off/on, or [CTRL-
ALT-RIGHT SHIFT-DELETE] on TOS 1.04 and higher) has been
performed.
STEP 4 - EXECUTE RESET HANDLER
Next thing, the Operating System checks if the system variable
resvalid contains the 'magic longword' $31415926. If this is the
case, it will execute the routine at the address contained in the
system variable resvector, located at $42A. The 'return address'
will be in A6. You may thus notice that programs that manipulate
the reset vector are left by means of a JMP (A6) instead of the
usual RTS or even RTE.
This possibility is often used by viruses to enable them to
'survive' a reset.
STEP 5 - FURTHER INITIALISATION
Of course, the machine will have to initialise some its chips.
This happens during this step.
First the Programmable Sound Generator (PSG, Atari's miserable
excuse for a sound chip) will be initialised. Oddly enough, this
is also required to deselect the floppy disk drives, as some
sound chip ports are reserved for that purpose.
Second, the screen frequency is set to 50 Hz (meaning the screen
will be rebuilt 50 times per minute). This is done by setting the
syncmode register, located at $FF820A, to 50 Hz. In some
alternative TOS versions this may be 60 Hz - which gives a more
stable screen but which makes the screen unreadable (it seems to
'run' up and/or down) when using certain TV's and modulators. On
a Falcon the hertz rate is set in a different way and may be
quite different from 50, 60 or 71 Hz.
Third, the colour registers (addresses $FF8240 and further) will
be set to their default values. These default values are located
somewhere in ROM. On the STE, TT and Falcon, colour registers are
(at least partly) located elsewhere.
Fourth, screen memory is installed. This is the bit of memory
that is scanned and sortof digitally displayed on your monitor.
This is done by loading the video base registers (at $FF8201 and
$FF8203) with the value $10000. Ergo: Screen memory is then
located at address $10000. It will later be changed to another
address (i.e. $8000 below the physical top of RAM in ST mode).
This is different on Falcon and TT (and enhanced graphic cards)
unless they're using ST-compatibility screen modes during start-
up.
STEP 6 - 'COLD RESET' INITIALISATION
This step is only executed when no 'warm reset' is found to have
been executed (which is usually after power-up). Memory is now
cleared and installed.
First, it actually checks the amount of memory present in your
system. Second, it clears all of this. Third, it sets the 'magic
longwords' for memvalid and memval2, so as to enable a future
'warm reset' (see step 3).
STEP 7 - OPERATING SYSTEM INITIALISATION
This bit is always executed, unlike step 6, even after a warm
reset. That's why it seems to do something superfluous, i.e.
clearing RAM addresses $93A to $FFFF. After that, all Operating
System variables are initialised, and screen memory is set to the
location contained in the system variable phystop minus $8000 (32
Kb - this is different on TT and Falcon, as usual). This makes
sure it is located at the end of available RAM memory. All
interrupt vectors are set, even though they are not yet
functioning as they are disabled on CPU level. The Cookie Jar (if
any, according to TOS version 1.06 or higher) is also set.
The last bit of this step is the initialisation of the Operating
System's BIOS.
STEP 8 - FURTHER CARTRIDGE START POSSIBILITIES
Above, during step 2, we already encountered diagnostic
cartridges that could be plugged in your computer's expansion
port. Well, the other cartridges, 'standard' ones, get executed
during this eighth step. For them to be properly recognised, the
first longword at $FA0000 will have to have a value of $ABCDEF42.
The third longword (thus, the one at offset 8) is called c_init,
and is very important here: It determines at which moment during
this step the cartridge software should be run.
The three different times of execution are:
1) Before anything more happens.
2) After the screen resolution has been determined and
installed.
3) After the interrupts are enabled and the screen resolution
has been determined and installed.
4) After GEMDOS is initialised, the interrupts are enabled and
the screen resolution has been determined and installed (but
before step 9, the floppy booting procedure).
The starting moment is determined by specific values of c_init.
In all, step 8 entails the functions mentioned in the points
above.
STEP 9 - BOOTING FROM FLOPPY
If running TOS 2.06, 3.06 or 4.0x, the Fuji logo is displayed, a
memory test is executed and a hard disk spin-up sequence it
initiated.
When the value at the system variable _bootdev is smaller than 2
(i.e. when booting has to be done from device 0 or 1,
corresponding with floppy drives A or B), the Operating System
will load the bootsector off that particular floppy disk and
execute it when the checksum is $1234 (i.e. when the bootsector
is executable). This will be done by jumping through the hdv_init
and hdv_boot system variables.
This is how most bootsector viruses get into the system and
install themselves. As the bootsector is always executed in
supervisor mode, the programmer can easily gain access to
privileged addresses.
When the _bootdev value is bigger than 2, the ACSI (Atari
Computer System Interface) bus is checked to see if any
executable bootsector can be fetched from other media (i.e. from
hard disk). When found, this will be loaded and executed.
This is how auto-booting hard disks work (i.e. ones that do not
require software on floppy to install themselves and their driver
software).
Principally bootsector viruses can also be active here, but this
is generally quickly seen, as the hard disk will cease auto-
booting if it did before. Also, most partition size data will be
trashed by it.
STEP 10 - UNDOCUMENTED STUFF
The following step is not official, not documented, illegal to
use - yet it is often used for reset-proof RAM disks to remain in
memory or, indeed, for the non-executable bootsector viruses to
get themselves activated (see 'The Book' 2.2.2).
All memory is checked by the Operating System for the occurrence
of a 512-byte block from the physical top of RAM down to $600
(i.e. ending at $A00, $800, $600, etc.) that answers to specific
criteria. First, it has to start with the magic longword
$1212345. Second, the second longword should contain the address
where that magic longword is contained. Third, it should contain
a longword checksum of that 512-byte bit of memory.
If this happens to be true, the routine at the address plus 8
bytes (i.e. $A08, $808, $608, etc.) will be executed by means of
a JSR.
This is how non-executable bootsector viruses get executed in
memory, as they are already loaded in memory and just wait for
this particular Operating System to get to work.
STEP 11 - THE LAST BITS
All "\AUTO\*.PRG" files on the boot drive are loaded and run.
Somewhere in a disk's bootsector is a word value, at offset $1E,
that is copied to the system variable cmdload, which is located
at address $482.
When this address gets the value $0000, it will try to load a
file called "COMMAND.PRG" from the boot device after trying to
find an execute any .PRG files in the "AUTO" folder on that same
device. Such a file "COMMAND.PRG" could for example be a Command
Line Interpreter - for people who prefer typing MS-DOS style
commands above the ease of GEM and the mouse.
If the cmdload value is unequal to $0000, it will only try to
find and execute these "AUTO" folder programs. Instead of loading
"COMMAND.PRG" after that, it will start the AES part of ROM.
It used to be a very commonly known fact that files or
contiguous sectors can be fairly easily loaded from a bootsector
using the extended information located at offsets $20 to $39
which were incorporated in the old Atari booter. This was e.g.
used to load Operating Systems from disk in the time when nobody
has their TOS on ROM. It's obsolete now.
