Skip to main content
© Hotline

                            PART III
            THE ULTIMATE VIRUS KILLER BOOK APPENDICES

              G - XBRA STRUCTURE AND THE COOKIE JAR


 XBRA STRUCTURE

 Literally  dozens  of  programs  (if not  dozens  of  dozens  of
dozens...) bend system vectors for their own particular use. Each
of  them  buffers  the original value contained  on  that  system
vector,  to  execute  the original routine after they  have  done
their  own  bit.  In the end,  this tends to  result  in  several
programs linking themselves at the same vector,  buffering  their
'parent' vector address value, calling each other, etc.
 The XBRA structure,  even though it arrived much too late, rages
for  order  in  this  chaos.   It  was  devised  by  some  German
programmers,  and is rapidly being accepted as a rather excellent
way to make things easier with regard to checking which  programs
bend which system vectors - indeed,  even allowing you top  check
an entire chain of programs that bend one vector!
 In  case of an XBRA structure the following happens:  A  program
bends  a vector at itself - let's assume this results in the  new
value of the vector being $B0000.  The program will now not store
the  old vector (which is an address and,  thus,  a longword)  at
just  any specific buffer address in its own code,  but  it  will
copy it to a very specific address - $BFFFC ($B0000 minus 4).  At
$BFFF4 (yet 8 bytes lower),  it will put the hexadecimal longword
value of $58425241, which represents the ASCII characters 'XBRA'.

 So what we get is the following:

 Vector points to ADDRESS X

 ADDRESS X     : Start of actual program code
 ADDRESS X -  4: Longword value of the previous vector contents
 ADDRESS X -  8: Program ID
 ADDRESS X - 12: 'XBRA'

 You will have noticed the presence of four bytes of space at the
address  minus  8:  This  can be used by the  programmer  of  the
vector-bending  software  to contain the  program  ID,  which  is
usually  an  ASCII  word  with a length  of  4  bytes  (i.e.  one
longword). The ID code for the Claus Brod Hard disk  Driver,  for
example, is 'CBHD'.
 All the programmer needs to do is define three longwords  buffer
space before the start of the routine to which a vector will bend
-   to   be  filled  in  with  the  proper  values   and   'XBRA'
identification by the installation routine.
 The  obvious  advantage is that programs such as  the  "Ultimate
Virus  Killer" can establish what all the programs are that  bend
vectors, contrary to being able just to check the topmost one. If
you're a programmer that bends system vectors,  therefore, please
use the XBRA protocol!

 THE COOKIE JAR

 In  TOS  1.06 and up,  Atari implemented something  called  'The
Cookie  Jar'.  This  is a reserved area in memory  where  certain
values represent certain things.  It was included for the STE and
TT's sakes (and later, of course, the Falcon's), so that programs
would  have  ways  of getting to know which  hardware  they  were
addressing.  STE,  TT and Falcon have different hardware from the
ST, logically.
 Of course, Atari largely neglected to document this feature, but
after  many  hours  of  searching  and  months  of  experimenting
(and...er...glancing over an issue of the German "ST Magazin")  I
can now offer you some info about it.

 At  address $5A0 (an official system variable that will  not  be
changed  any  more - but then again you never know  with  Atari),
there will either be a zero or a longword pointer.  If you have a
zero  there,  this means that you have a TOS version  lower  than
1.06,  or the pre-version of TOS 1.06 (which is most likely).  If
you find a longword pointer instead of a zero, however, this will
be the address where you can find the Cookie Jar.

 The  Cookie  Jar is,  strictly taken,  a  collection  of  32-bit
values,  of which two belong together each time. The first one is
usually a value representing some kind of ASCII string,  and  the
second  is the actual value.  Usually,  this is another  address.
ASCII strings starting with an underscore ("_") are off Atari and
should never be used by other people rather than Atari!
 The  last  Cookie  is always a longword  zero  followed  by  the
maximum  number  of  cookies that can be used  (only  a  specific
amount of memory is reserved for Cookies,  and you should not use
more unless you want to install it all yourself again and  expand
it - but that's too much to tell here).
 That's basically all there is to know about the Cookie Jar.  Its
use is simple:  Apart from other programs just getting parameters
from it, it can also specify addresses of variable locations that
can  then  be used by other programs.  It's  all  about  programs
communicating with each other.

 Some  of  the  officially  documented  Atari  Cookies  are   the
following.  First follows the longword ASCII string, and then the
value(s).

 _AKP     TOS & Keyboard language Cookie (TOS 4.xx).
          The high byte seems always to be $2F.  The two  highest
          bits of the second-highest byte can have the  following
          values:
          0            MM-DD-YY date format
          1            DD-MM-YY date format
          2            YY-MM-DD date format
          3            YY-DD-MM date format
          The fourth bit of that byte determines whether the time
          format is 24 hours (bit on) or 12 hours (bit off).
 _CPU     This  is  not  hard  to  imagine.  It  specifies  which
          processor is present in the system.  It can be  0,  10,
          20,  30, 40 or 60 for 68000, 68010, 68020, 68030, 68040
          ("Medusa" and "Afterburner") and 68060 respectively.
 _FDC     Describes what kind of floppy disk hardware happens  to
          be  attached to your system.  It indicates the kind  of
          floppy  drive,  i.e.  double density  (standard),  high
          density (HD drives) or Extra-high density.
          The  high byte of the second longword can have  any  of
          the following values:
          0            Normal (i.e. double) density
          1            High Density (HD); 1.44 Mb
          2            Extra-high Density (ED); 2.88 Mb
          The other three bytes indicates who set the Cookie.  So
          far, the following are know:
          $000000      No information
          $415443      "ATC" - Atari Corporation
          $445031      "DP1" - Dream Park Development
 _FLK     This is the file lock Cookie,  for use with networks or
          multi-tasking systems. It determines whether or not the
          GEMDOS  function "Flock" (#92) is present (which is  as
          of TOS 3.06).
 _FPU     Describes  which hardware and  software  floating-point
          support is installed in the machine.  The high word can
          have different values,  where the following bits denote
          specific hardware:
          Bit 0        SFP004 or compatible is present
          Bit 1        68881 or 68882 present
          Bit 2        Surely a 68881
          Bit 3        The 68040's internal FP support
          Note:  If 2 is set and 1 is cleared,  there is surely a
          68881. If 1 and 2 are set then there's a 68882.
          The  low  word  denotes special values  when  you  have
          software FPU emulation.
 _FRB     Since  the  TT's  "Fast  RAM" is  not  usable  for  DMA
          transfers,  the  BIOS of that computer creates a 64  Kb
          buffer area in memory of which the address can be found
          here.
 _FSR     Tells you "FLCNSER" version 1.0 is installed. This is a
          patch program for (Falcon) TOS 4.00 to 4.04 to  correct
          the  TOS  routines  in  connection  with  serial   port
          transfers.
 _IDT     International Date & Time Cookie (TOS 4.xx).
          The  highest word has two meaningful  bytes.  The  high
          byte determines the keyboard language.  Possible values
          are:
          1            German
          2            French
          3            English (UK)
          4            Spanish
          5            Italian
          6            English (USA)
          7            Swiss French
          8            Swiss German
          The  low  byte determines the TOS  language  (i.e.  the
          language  with  which TOS  presents  itself).  Possible
          values are:
          0            English
          1            German
          2            French
          3            ?
          4            Spanish
          5            Italian
 _INF     STEFIX  installed - a patch program for TOS  1.06  (for
          the so-called "DESKTOP.INF bug").
 _MCH     Describes  the  machine  you  use.  Here,  also,  we're
          talking about two words.
          0,0   260 ST, 520 ST(F)(M)(+), 1040 ST(F)(M)
          1,0   MEGA ST (Difference: Real Time Clock)
          2,0   STE
          3,0   TT
          4,0   Falcon 030
 _NET     This  is another Cookie for use  with  networks,  which
          supplies   information  about  the  network   that   is
          connected.
 _OOL     This  is a Cookie that will be installed  when  running
          the "POOLFIX3.PRG" or "POOLFIX4.PRG" programs,  both of
          which install patches for Operating System bugs (in TOS
          1.04 and 1.06,  with GEMDOS version 0.15).  This Cookie
          only signifies the fix program being installed, and has
          no particular values.
 _SLM     The "Diablo" driver for the Atari SLM laser printer  is
          installed.   The   value  points  to  an   undocumented
          structure.  This  cookie  is only installed  by  driver
          versions number 1.4 and higher.
 _SND     A   bit   table  that  tells   programs   which   sound
          possibilities  they have.  Only three of these 32  bits
          are used - but let's hope that this shall not last long
          (idle hopes...).
          Bit 0      YM sound chip (ST and STE)
          Bit 1      Stereo 8-bit playback
          Bit 2      DMA record (with XBIOS) (STE and TT)
          Bit 3      16 bit CODEC (Falcon)
          Bit 4      DPS (Falcon)
 _SWI     Value of configuration switches,  if present. Don't ask
          me what this is supposed to mean. I don't know (neither
          do  any  mortals  outside  of  Atari   Corporation,   I
          suspect).
 _VDO     Version number of the video hardware.  This is actually
          represented  by two words.  The first word is the  spot
          before the comma; the second the one after.
          0,0   ST
          1,0   STE
          2,0   TT
          3,0   Falcon 030