G: XBRA & Cookie Jar Protocols
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
