* Do not rely on the order of Copper list instructions.  The Release 2
    mrgcop() function builds different copper lists to that of 1.3, by
    including new registers in the list (e.g., MOVE xxxx,DIWHIGH).  This
    changes the positions of  the  other  instructions.  We  know  of one
    game that 'assumes' the BPLxPTRs  would be at a certain offset in the
    Copper list, and that is now broken on machines running 2.0 with the
    new Denise chip.

  * Graphics and layers functions which use the blitter generally return
    after starting the final blit.  If you are mixing graphics rendering
    calls and processor access of the same memory, you must waitblit()
    before touching (or deallocating) the source or destination memory
    with the processor.  For example, the text() function is faster in
    Release 2, causing some programs to trash partial lines of text.

  * colormap structure is bigger.  programs must use getcolormap() to
    create one.

  * Blitter rtns decide ascend/descend on 1st plane only.

  * Changing the display mode of an existing screen or viewport while
    open is still not a supported operation.

  * gfxbase displayflags and row/cols may not match workbench screen.

  * Do not hardcode modulo values - use bitmap->bytesperrow.

  * If the graphics Autodocs say that you need a tmpras of a certain size
    for some functions, then you must make that the minimum size.  In
    some cases, before 2.0, you may have gotten away with using a smaller
    TmpRas with some functions (for example flood()).  to be more robust,
    graphics now checks the TmpRas size and will fail the function call
    if the TmpRas is too small.

  * ECS chips under 2.0 generate displays differently. The display window
    registers now control DMA.

  * loadrgb4() used to poke colors into the active copperlist with no
    protection against deallocation of that copperlist while it was being
    poked.  Under 2.0, semaphore protection of the copperlist was added
    to LoadRGB4() which makes it totally incorrect and extremely
    dangerous to call LoadRGB4() during an interrupt.  The general
    symptom of this problem is that a system deadlock can be caused by
    dragging one screen up and down while another is cycling.  Color
    cycling should be performed from within a task, not an interrupt.  In
    general, the only functions which may be safely called from within an
    interrupt are the small list of Exec functions documented in the
    "exec interrupts" chapter.