home *** CD-ROM | disk | FTP | other *** search
/ Amiga ISO Collection / AmigaUtilCD2.iso / Programming / Assembler / TFF-AOB.DMS / in.adf / Release3.1 / Docs3.1.lha / Docs3.0 / Compatibility.Checklist next >
Encoding:
Text File  |  1992-09-15  |  6.3 KB  |  135 lines
  1. V39
  2. General
  3.  · In general, some new LVOs supersede old ones.  While the old ones still
  4. work, add-on software that SetFunctions the old LVOs may no longer catch
  5. what they were hoping to catch.  An example from V37 was people who
  6. SetFunction'd AutoRequest().  Most system requesters go through
  7. EasyRequest() now.  A V39 example would be SetWindowPointer() replacing
  8. SetPointer().
  9.  
  10. Intuition
  11.  · OpenScreen() now fails if you request a screen deeper than the hardware
  12. can support.  Look for a secondary error of OSERR_TOODEEP.
  13.  
  14.  · Forgotten FreeSprite():  Sprites may now have a number of different
  15. modes.  However, under Intuition, these modes are global to all sprites. 
  16. If a program gets a sprite in a particular mode, but then does not free it,
  17. Intuition (and all Intuition-based programs including Workbench) are forced
  18. to use sprites in the mode of the forgotten sprite.  In general, it is good
  19. practice to not use sprites other than the pointer when coding software
  20. that is meant to be Intuition-compatible.
  21.  
  22. Graphics Database
  23.  · Data for any mode may be different across kickstarts, different
  24. machines, even accross similar machines!  Treat the database as dynamic.
  25.  
  26.  · Never cache any information on DEFAULT_MONITOR_ID modes as the default
  27. monitor can be changed by the user via the promotion feature.
  28.  
  29.  · Information that was available under V37 may not necessarily be
  30. available under V39. For instance, VGA and A2024 are no longer in ROM, and
  31. if they are not added by the user, there will be no info about them.
  32.  
  33. Graphics Displays
  34.  · The gap between intuition screens was always 3 non-laced lines (or 6
  35. laced lines). This value is now variable (but always at least 3 for
  36. compatibility).
  37.  
  38.  · MakeVPort() can now return an error. see <graphics/view.h>
  39.  
  40.  · BitMap plane layout:  Interleaved bitmaps have a new memory layout. They
  41. are allocated as one contiguous block of CHIP memory, and are internally
  42. different from non-interleaved plane data.
  43.  
  44.  · BitMap->BytesPerRow:  BytesPerRow officially means "the number of bytes
  45. you have to add to a pointer to a byte of the BitMap to get to the same
  46. place one row down". It no longer can be depended on to mean "the number of
  47. bytes in this row". For interleaved bitmaps, BytesPerRow is quite a bit
  48. larger than the number of bytes in this row.  GetBitMapAttr(bm,BMA_WIDTH )
  49. can return the true width in pixels.
  50.  
  51.  · Misuse of PAL or NTSC flags:  A common method of determining whether a
  52. machine is running in PAL or NTSC mode makes use of the DisplayFlags field
  53. in GfxBase.  Starting with V36, PAL vs. NTSC information derived from this
  54. field can only be used to determine PAL vs. NTSC timing periods, not for
  55. finding out display characteristics.
  56.  
  57.  · Poking Copper lists or copinit:  The structure and order of Copper lists
  58. will change for all modes, so any program that relies on poking the Copper
  59. lists will likely break.
  60.  
  61. Consoles
  62.  · We gave up a degree of compatability on console by doing single plane
  63. scrolls, and/or masked scrolls ... applications which draw graphics in the
  64. console portion of the window, but use console scroll commands may not work
  65. if they are drawing their text in other than pen 1 on pen 0.
  66.  
  67.  · Console does not do pen allocation; those using pen sharing on their own
  68. screens should allocate, and set pens 3-7 IF they plan on using those
  69. colors in console.  They may set them to whatever they like, but currently
  70. responsibility for the screen, and window is still the responsibility of
  71. the calling application, not console.  For maximum compatability, console
  72. still uses pens 0-7 just as it always has.
  73.  
  74.  · Tablet driver writers should test that their tablets now work with
  75. console drag selection (known not to work in 2.04).
  76.  
  77.  · Application writers may wish to test that it is possible to print 8
  78. bitplane HAM images under V37, even though they cannot display those images.
  79.  
  80. V39 on AA
  81.  · BitMap planes:  Bitplane data must be properly aligned in CHIP memory
  82. for certain hardware features to work.  Because of this, allocations of
  83. BitMap plane data now have stricter rules. Under >=V39, use AllocBitMap().
  84.  
  85.  · Pointer handling has become much more sophisticated. People playing
  86. tricky games with the pointer data may get into trouble if they make
  87. assumptions about the data format of the Intuition pointer, which can be
  88. different in new modes.
  89.  
  90.  · Intuition allocates your screen's BitMap, through AllocBitMap().  This
  91. means that the bytes per row will be a multiple of 4 or 8 bytes, where
  92. previously it was only a multiple of 2.  If you make assumptions about how
  93. many bytes per row will be in that BitMap, you may have trouble due to
  94. higher alignment restrictions.
  95.  
  96.  · ColorMaps and ColorTables:  The color system has undergone significant
  97. changes, so new calls should be used whenever possible.  The value
  98. ColorMap->ColorTable and the structure it points to should never be poked
  99. or read directly.
  100.  
  101. Processor
  102.  · Self-modifying code: Any form of self-modifying code, including loading
  103. code off of disk into memory (when not using the normal DOS call) will
  104. absolutely break on an 040.  Self-modifying code without the appropriate
  105. cache controls has been a no-no since the 68020. However, on the 68020 and
  106. 030, your chances of getting away with it were pretty good, because of the
  107. small cache size. The large caches of the 68040 make your chances of
  108. getting away with it approximately zero. Also breaks most programs packed
  109. with a "packer" program.
  110.  
  111. AA
  112.  · Poking custom chip register bits:  Many bits that were previously
  113. undefined or private now functions.
  114.  
  115.  · Illegal use of the processor to write to bitplane and sprite data
  116. registers:  The correct way for data to be fed to the chips is by setting
  117. up DMA that points to the data in Chip memory.
  118.  
  119.  · Illegal re-use of sprites on the same line:  Attempting to re-use
  120. sprites on the same horizontal line by redefining the sprite data is
  121. illegal and unsupported.  Sprites may only be re-used vertically, and then
  122. only with at least a one line gap between re-uses. See the "Amiga Hardware
  123. Reference Manual" for an example of sprite re-use.
  124.  
  125.  · Incorrect allocation of sprite image data:  Because of the increased
  126. fetch bandwidth of the new chips, sprite image data must be properly
  127. aligned in Chip memory.  Under 2.0, the best way to allocate this memory is
  128. to call the Exec library AllocMem() function.
  129.  
  130. Hardware
  131.  · Video Slot Compatibility.  Hardware that uses the 12-bit video slot
  132. should work in the new 24-bit video slot, but verification of this is
  133. certainly necessary.
  134.  
  135.