Skip to main content

                            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.