SOME CAVEATS TO HARDWARE LEVEL PROGRAMMERS
The Amiga is available in a variety of models and configurations, and is further diversified
by a wealth of add-on expansion peripherals and processor replacements. In addition,
even standard Amiga hardware such as the keyboard and floppy disks, are supplied by a
number of different manufacturers and may vary subtly in both their timing and in their
ability to perform outside of their specified capabilities.
The Amiga operating system is designed to operate the Amiga hardware within spec,
adapt to different hardware and RAM configurations, and generally provide upward
compatibility with any future hardware upgrades or "add ons" envisioned by the
designers. For maximum upward compatibility, it is strongly suggested that programmers
deal with the hardware through the commands and functions provided by the Amiga
operating system.
If you find it necessary to program the hardware directly, then it is your responsibility to
write code which will work properly on various models and configurations. Be sure to
properly request and gain control of the hardware you are manipulating, and be especially
careful in the following areas:
Do not jump into ROM. Beware of any example code that calls routines in the $F80000 to
$FFFFFF range. These are ROM addresses and the ROM routines WILL move with every OS
revision. The only supported interface to system ROM code is through the provided library,
device, and resource calls.
Do not modify or depend on the format of any private system structures. This includes the
poking of copper lists, memory lists, and library bases.
Do not depend on any address containing any particular system structure or type of
memory. The system modules dynamically allocate their memory space when they are
initialized. The addresses of system structures and buffers differ with every OS, every
model, and every configuration, as does the amount of free memory and system stack
usage. Remember that all data for direct custom chip access must be in CHIP RAM. This
includes bit images (bitplanes, sprites, etc), sound samples, trackdisk buffers, and copper
lists.
Do not write spurious data to, or interpret undefined data from currently unused bits or
addresses in the custom chip space. All undefined bits must be set to zero for writes, and
ignored on reads.
Do not write data past the current end of custom chip space. Custom chips may be
extended or enhanced to provide additional registers, or to use currently undefined bits in
existing registers.
All custom chip registers are read only OR write only. Do not read write only registers, and
do not write to read only registers.
- Introduction 9 -
To Next Page
Loading...
