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 -