V39 General · In general, some new LVOs supersede old ones. While the old ones still work, add-on software that SetFunctions the old LVOs may no longer catch what they were hoping to catch. An example from V37 was people who SetFunction'd AutoRequest(). Most system requesters go through EasyRequest() now. A V39 example would be SetWindowPointer() replacing SetPointer(). Intuition · OpenScreen() now fails if you request a screen deeper than the hardware can support. Look for a secondary error of OSERR_TOODEEP. · Forgotten FreeSprite(): Sprites may now have a number of different modes. However, under Intuition, these modes are global to all sprites. If a program gets a sprite in a particular mode, but then does not free it, Intuition (and all Intuition-based programs including Workbench) are forced to use sprites in the mode of the forgotten sprite. In general, it is good practice to not use sprites other than the pointer when coding software that is meant to be Intuition-compatible. Graphics Database · Data for any mode may be different across kickstarts, different machines, even accross similar machines! Treat the database as dynamic. · Never cache any information on DEFAULT_MONITOR_ID modes as the default monitor can be changed by the user via the promotion feature. · Information that was available under V37 may not necessarily be available under V39. For instance, VGA and A2024 are no longer in ROM, and if they are not added by the user, there will be no info about them. Graphics Displays · The gap between intuition screens was always 3 non-laced lines (or 6 laced lines). This value is now variable (but always at least 3 for compatibility). · MakeVPort() can now return an error. see · BitMap plane layout: Interleaved bitmaps have a new memory layout. They are allocated as one contiguous block of CHIP memory, and are internally different from non-interleaved plane data. · BitMap->BytesPerRow: BytesPerRow officially means "the number of bytes you have to add to a pointer to a byte of the BitMap to get to the same place one row down". It no longer can be depended on to mean "the number of bytes in this row". For interleaved bitmaps, BytesPerRow is quite a bit larger than the number of bytes in this row. GetBitMapAttr(bm,BMA_WIDTH ) can return the true width in pixels. · Misuse of PAL or NTSC flags: A common method of determining whether a machine is running in PAL or NTSC mode makes use of the DisplayFlags field in GfxBase. Starting with V36, PAL vs. NTSC information derived from this field can only be used to determine PAL vs. NTSC timing periods, not for finding out display characteristics. · Poking Copper lists or copinit: The structure and order of Copper lists will change for all modes, so any program that relies on poking the Copper lists will likely break. Consoles · We gave up a degree of compatability on console by doing single plane scrolls, and/or masked scrolls ... applications which draw graphics in the console portion of the window, but use console scroll commands may not work if they are drawing their text in other than pen 1 on pen 0. · Console does not do pen allocation; those using pen sharing on their own screens should allocate, and set pens 3-7 IF they plan on using those colors in console. They may set them to whatever they like, but currently responsibility for the screen, and window is still the responsibility of the calling application, not console. For maximum compatability, console still uses pens 0-7 just as it always has. · Tablet driver writers should test that their tablets now work with console drag selection (known not to work in 2.04). · Application writers may wish to test that it is possible to print 8 bitplane HAM images under V37, even though they cannot display those images. V39 on AA · BitMap planes: Bitplane data must be properly aligned in CHIP memory for certain hardware features to work. Because of this, allocations of BitMap plane data now have stricter rules. Under >=V39, use AllocBitMap(). · Pointer handling has become much more sophisticated. People playing tricky games with the pointer data may get into trouble if they make assumptions about the data format of the Intuition pointer, which can be different in new modes. · Intuition allocates your screen's BitMap, through AllocBitMap(). This means that the bytes per row will be a multiple of 4 or 8 bytes, where previously it was only a multiple of 2. If you make assumptions about how many bytes per row will be in that BitMap, you may have trouble due to higher alignment restrictions. · ColorMaps and ColorTables: The color system has undergone significant changes, so new calls should be used whenever possible. The value ColorMap->ColorTable and the structure it points to should never be poked or read directly. Processor · Self-modifying code: Any form of self-modifying code, including loading code off of disk into memory (when not using the normal DOS call) will absolutely break on an 040. Self-modifying code without the appropriate cache controls has been a no-no since the 68020. However, on the 68020 and 030, your chances of getting away with it were pretty good, because of the small cache size. The large caches of the 68040 make your chances of getting away with it approximately zero. Also breaks most programs packed with a "packer" program. AA · Poking custom chip register bits: Many bits that were previously undefined or private now functions. · Illegal use of the processor to write to bitplane and sprite data registers: The correct way for data to be fed to the chips is by setting up DMA that points to the data in Chip memory. · Illegal re-use of sprites on the same line: Attempting to re-use sprites on the same horizontal line by redefining the sprite data is illegal and unsupported. Sprites may only be re-used vertically, and then only with at least a one line gap between re-uses. See the "Amiga Hardware Reference Manual" for an example of sprite re-use. · Incorrect allocation of sprite image data: Because of the increased fetch bandwidth of the new chips, sprite image data must be properly aligned in Chip memory. Under 2.0, the best way to allocate this memory is to call the Exec library AllocMem() function. Hardware · Video Slot Compatibility. Hardware that uses the 12-bit video slot should work in the new 24-bit video slot, but verification of this is certainly necessary.