Amiga ISO Collection

home *** CD-ROM | disk | FTP | other *** search

/ Amiga ISO Collection / AmigaUtilCD2.iso / Misc / CBMDevKit1.dms / CBMDevKit1.adf / tutorials.lha / tutorials / V39_AA_Graphics < prev next >

Wrap

Text File | 1993-11-04 | 29.4 KB | 693 lines

Overview of V39 Graphics (c) Copyright 1992-93 Commodore-Amiga, Inc. All Rights Reserved The Advanced Amiga Chip set (AA) redefines graphics performance on the Amiga by adding many new display modes, new features and more color to the Amiga platform. This article presents an overview of how the new V39 graphics library has implemented theses new features in the system software. In V39, the graphics library has changed in the following areas: o Support for new AA display modes o Double buffering o Retargettable sprite and screen (ViewPort) functions o Palette sharing o Bitmap functions o Interleaved BitMaps o Display mode promotion, coercion and selection o RTG compatible RastPort functions. The original Amiga graphics library exposed many device-dependent details to the application programmer. Because of this, introduction of new graphics devices has been slowed, and application support of new features has been delayed. To reverse this trend, no features have been added to the new graphics system which cannot be kept for the future. Thus, when newer graphics systems are introduced, system software will need fewer changes, and applications will be ready to automatically use new capabilities. Thus, parameters such as number of bits per pixel, resolution, color palette size, etc., are either variable or have been made very large. Compatibility ============= The AA chips are register level compatible with the old and ECS chips at boot up time. However, when new AA modes are enabled and displayed, and a game then takes over the screen display without informing the OS of it, some registers may be in incompatible settings. Two approaches will reduce this: 1) Old Programs which boot with their own custom boot block (games) will have AA features disabled unless they are specifically asked for. This should ensure transparent compatibility for all bootable games. 2) It will be possible to disable AA features for non-compatible programs. This will be done via the "BootMenu" which is available at system boot time. New options in this menu will allow disabling of AA, disabling of ECS, and switching of PAL and NTSC. For bootable games that want AA features, use the V39 graphics function SetChipRev(). This lets you upgrade the Amiga to be any chip revision you need, and handles the extra house-keeping that graphics needs to operate the selected chipset (such as updating the graphics database). The only restriction is that it is not possible to downgrade the setting from AA down to ECS or A. Get/Set Functions ================= This release of graphics.library will attempt to ease the (future) transition to Retargetable Graphics. New functions are provided to do some operations in a more device-independent manner. This will help when we have to support foreign graphics devices, more than 8 bits per pixel, chunky pixels, and true-color displays. These new "Get/Set" functions will allow device independent access to fields in the RastPort structure which were only previously manipulable by direct structure access. VOID SetAPen(rp, pen) Sets the current APen value ULONG GetAPen(rp) Return current APen value VOID SetBPen(rp, pen) Sets the current BPen value ULONG GetBPen(rp) Return current BPen value VOID SetDrMd(rp, mode) Sets the current DrawMode ULONG GetDrMd(rp) Return current DrawMode VOID SetOPen(rp,c) Was a macro. Now use the SetOutlinePen() function, or the SafeSetOutlinePen() macro. ULONG GetOPen(rp) Return current area outline pen VOID SetWrMsk(rp,m) Was a macro. Now use the SetWriteMask() function, or the SafeSetWriteMask() macro. ULONG GetWrMsk(rp) Description of this function is left as an exercise for the reader. VOID SetABPenDrMd(rp,apen,bpen,drmd) Sets the APen, BPen, and DrawMode for a RastPort. Faster than separate calls. VOID SetRPAttr(rp,taglist) You asked for it so here it is. Lets you set many of the RastPort attributes with one tag-based call. Here are the attributes currently supported: RPTAG_Font Font for Text() RPTAG_SoftStyle style for text (see graphics/text.h) RPTAG_APen Primary rendering pen RPTAG_BPen Secondary rendering pen RPTAG_DrMd Drawing mode (see graphics/rastport.h) RPTAG_OutLinePen Area Outline pen RPTAG_WriteMask Bit Mask for writing. RPTAG_MaxPen Maximum pen to render (see SetMaxPen()) VOID GetRPAttr(rp, taglist) No prizes for guessing what this does. It supports the extra tag RPTAG_DrawBounds. This tag is passed with a pointer to a rectangle structure. The returned rectangle structure will contain the bounds of the clipping regions inside the RastPort. This can be used to optimize drawing and refresh. Color Map Functions =================== The color palette in AA is different in a lot of ways from the ECS one: o It has 24 bits per entry, plus one bit to select transparency. o There are 256 entries which is enough for many programs running on the same screen to share the palette. All colors are now specified as 32 bit left-justified fractions, and are truncated based upon the number of bits that the hardware is capable of displaying. There are now ...RGB32() functions to replace the ...RGB4() functions. These all work in 32-bits per gun, irrespective of the device the colors are intended for. Devices that cannot handle the color resolutions will truncate the colors to the most significant n bits. That is why it is important to duplicate the most significant n bits throughout the 32-bit resolution. For example, pure white should be treated as: R = 0xffffffff, G = 0xffffffff, B = 0xffffffff and not R = 0xf0000000, G = 0xf0000000, B = 0xf0000000 The new color palette functions allow for multiple applications to coordinate their access to the palette. This allows applications to, for instance, dynamically remap pictures to match the color palette of the Workbench screen, display animations in windows, etc. ObtainPen() will attempt to obtain a free palette entry for use by your program, and then set the pen number to the RGB value you specify. A pen can be either shared or exclusively for your own use. If shared, then you should not modify the RGB value of the pen once the pen is obtained, because other applications may use that same pen, and will be relying on its color. ObtainBestPen() is a tag-based function that will attempt to find the pen in the ColorMap which is closest to the specified RGB value, and then return a shared pen to you. There are (currently) four levels of precision to which the RGB value must match. PRECISION_EXACT asks for an exact match of the RGB value. The other three are, in descending order of precision, PRECISION_IMAGE, PRECISION_ICON, and PRECISION_GUI. If there is no pen in the ColorMap with the required RGB value to the specified precision, and there are unallocated pens, then a new pen is reserved as shared, and its RGB value set to the value you requested. Note, there is no way to physically stop you from changing the colors of shared pens, but it's just not done, so don't do it. Pens obtained either with ObtainPen() or ObtainBestPen() should be released back to the system with ReleasePen() when no longer used. All the palette-sharing functions require a struct PalExtra to be attached to the ColorMap. This is done automatically for all Intuition screens, but if you are not using Intuition, then you will need to call AttachPalExtra() yourself. This allocates and attaches a PalExtra structure to the ColorMap. The PalExtra is deallocated by the FreeColorMap() function. FindColor(cm,r,g,b,maxcolor) lets an application find the "closest" color to a given RGB value, independently of palette sharing. In fact, using SetRGB32CM and FindColor, you can perform color matching which is not associated with a display at all. Bitmap Functions ================ These function exist because the new AA chips have alignment restrictions in high bandwidth modes. Changing InitBitMap() and AllocRaster() to obey these restrictions would have been very incompatible. Bitmaps created by AllocRaster with a multiple of 32 or 64 pixels per line will be compatible with high fetch modes (2x or 4x respectively). Incompatible ones will fall back to 1x mode, if 1x mode is capable of displaying the screen. AllocBitMap() allocates an entire bitmap structure, and the display memory for it. AllocBitMap() allows you to use more than 8 planes, and also allows you to specify another bitmap pointer, thus telling the system to allocate the bitmap to be "like" another bitmap. A bitmap allocated in such a matter may be able to blit to this bitmap faster. Such a bitmap may be stored in a foreign device's local memory. Do not assume anything about the structure of a bitmap allocated in this manner. The size of a bitmap structure is subject to change in future graphics releases. Thus, you should use AllocBitMap()/FreeBitMap() for your raster allocation. Sprite Functions ================ Graphics sprite functions (MoveSprite()) have been extended to understand large sprites, selectable sprite pixel resolution, and movement of scan-doubled sprites. Sprite positioning is no longer rounded down to lo-res pixel resolution. Applications will no longer have to "know" about the hardware-dependent format of sprite data. The new sprite functions work with an ExtSprite structure, which is obtained with the tag-based AllocSpriteData() function. This function allows you to specify a BitMap for the image of the sprite, and tags to specify scaling factors to apply to the BitMap. The returned ExtSprite structure is then passed to GetExtSprite(), which is the V39 equivalent of the old GetSprite() function. There is no equivalent FreeExtSprite(0 function; FreeSprite() does the trick. The ExtSprite allocated with AllocSpriteData() is freed with FreeSpriteData(). The AA chip set imposes some limitations on sprites: o All sprites in a ViewPort will be of the same resolution and width. There is no individual sprite resolution/width control. If the sprite you allocate is of a different width than Intuition's pointer, then Intuition is notified, and takes the appropriate steps to maintain the pointer imagery. o In the programmable beam modes (namely Multiscan, Euro72, DblNTSC, DblPAL, and Super72), only sprite 0 is likely to be available; the other sprites are lost to bitplane DMA. MakeVPort() has code that detects which sprites have been reserved (with GetSprite() or GetExtSprite()), and if possible, will drop the display bandwidth. This will make available more DMA to the lower numbered sprites, at the expense of more bitplane DMA access. MakeVPort() will not drop the bandwidth if doing so would cause the loss of bitplanes in the display, so this is not always guaranteed to work for you. All the AA sprite features are available through new tags for VideoControl(): VTAG_SPEVEN_BASE_SET/GET This sets the base color number of the even numbered sprites. The AA chip set allows odd numbered and even numbered sprites to use the colors of different 16-color banks, as opposed to the previous chip sets where all sprites used colours 16-31. Legal values to set the base are 0-255, but will be rounded down to the nearest multiple of 16. VTAG_SPODD_BASE_SET/GET As VTAG_SPEVEN_BASE_SET/GET, only for the odd numbered sprites. For example, if the following tag list is passed to VideoControl(): struct TagItem[] = { {VTAG_SPEVEN_BASE_SET, 32}, {VTAG_SPODD_BASE_SET, 144}, {TAG_DONE}, }; then the sprites use the following colors: Sprite Colors 0 32 (transparent), 33,34,35 2 36 (transparent), 37,38,39 4 40 (transparent), 41,42,43 6 44 (transparent), 45,46,47 1 144 (transparent), 145,146,147 3 148 (transparent), 149,150,151 5 152 (transparent), 153,154,155 7 156 (transparent), 157,158,159 [Attached sprites use the palette settings of the odd numbered sprites.] Normally, there are only (2 << depth) colours in a ColorMap (with the exception that Intuition screens always have a minimum of 32 colours). If you wish to set the sprite's colors to use pens that are outside of this range, then you should use the VTAG_FULLPALETTE_SET tag, which specifies that the ColorMap should contain entries for all possible colors (256). Therefore, the colors of these entries can be set with the usual ...RGB32() functions. Not setting VTAG_FULLPALETTE_SET in this case may cause unpredictable colors and enforcer hits. VTAG_SPRITERESN_SET/GET This allows you to set all the sprites in the ViewPort to one of 5 resolutions. SPRITERESN_140NS: All sprites have 140ns pixels. SPRITERESN_70NS: All sprites have 70ns pixels. SPRITERESN_35NS: All sprites have 35ns pixels. SPRITERESN_DEFAULT: All sprites have the Intuition default resolution. SPRITERESN_ECS: Compatible with ECS resolutions; 140ns, except in 35ns display pixel modes (SuperHires), where the sprite pixels are 70ns. VTAG_DEFSPRITERESN_SET/GET For setting the default sprite resolution, as used by SPRITERESN_DEFAULT. VTAG_BORDERSPRITE_SET/GET/CLR: This sets the bordersprite option in the AA chipset for the ViewPort, which allows sprites to appear in the borders outside of the normal display window (DisplayClip), i.e., the area that is normally color 0. However, this does not apply to the horizontal blanking area. VTAG_PF1_TO_SPRITEPRI_SET/GET: All revisions of the Amiga chips have allowed the priorities of sprites to playfield to be set. Usually, the priority is such that the sprites always appear in front of the playfield. There is an entry in the ViewPort structure for altering this priority, but V39 provides this tag in preference to writing to the ViewPort structure. VTAG_PF2_TO_SPRITEPRI_SET/GET: As VTAG_PF1_TO_SPRITEPRI_SET/GET, only for playfield 2. On the Amiga, playfield 2 is the default playfield, and playfield 1 is only used in DualPlayfield modes! Display Mode IDs and the Graphics Database ========================================== The graphics database has been extended where necessary for AA information, and these changes are limited to the DisplayInfo structure. The DisplayInfo->PaletteRange is only one WORD long, which is insufficient for the AA 24-bit colour resolution, and so has been superceded by three new entries called RedBits, BlueBits and GreenBits. These are one BYTE each, and show how many bits of precision is available for each colour gun. 255 bits each for red, green and blue should be enough for the foreseeable future (pun intended). Some new DIPF_IS flags were added to the database, providing more information about each display mode ID. DIPF_IS_SPRITES_ATT shows the mode supports attached sprites. The 35ns display modes on ECS could not support them. DIPF_IS_SPRITES_CHNG_RES shows that the mode supports sprites that can change resolution, and so the VTAG_SPRITERESN_SET VideoControl() tag will work on ViewPorts in this mode. DIPF_IS_SPRITES_BORDER shows that this mode supports border sprites, so the VTAG_BORDERSPRITE_SET VideoControl() tag will work on ViewPorts in this mode. DIPF_IS_SCANDBL shows that this mode is scandoubled (each display line is repeated once), so that half as many lines take up the same physical area on the monitor. There should be no need for you to look at this bit. DIPF_IS_SPRITES_CHNG_BASE shows that this mode supports sprite base colour offset changing, so that the VTAG_SPODD/SPEVEN_BASE_SET VideoControl() tag will work on ViewPorts in this mode. DIPF_IS_SPRITES_CHNG_PRI shows that this mode supports changing the playfield to sprite priority, so that the VTAG_PF2/PF1_TO_SPRITEPRI_SET VideoControl() tag will work on ViewPorts in this mode. DIPF_IS_DBUFFER shows that this mode will work with the double-buffering Chan geVPBitMap() function. You should check this flag before using the double-bufferi ng functions on the ViewPort. DIPF_IS_PROGBEAM shows that this mode is a programmed beam-sync mode. DIPF_IS_FOREIGN shows that this mode is not native to the Amiga chip set. Currently, no mode IDs will have this flag set, but under RTG many 3rd party display devices will. You may want to start checking for this flag now. With the plethora of new display modes that are available under V38 and V39, it is now becoming harder and harder for both the application writer and the end user to know which display mode ID they need to use. This will be especially true under RTG when the application writer will have no way of knowing all the possible display mode IDs that are available on third party display devices. A function was added for V39 to alleviate this problem, and provide a means by which the system can calculate the best mode ID to use given a number of requirements, called BestModeID(). It takes the following tags: BIDTAG_DIPFMustHave The DIPF_ flags that this display mode ID must have set. Default is NULL, so there is no preference. BIDTAG_DIPFMustNotHave The DIPF_ flags that this display mode ID must not have set. For example, you may wish to ensure that only native Amiga modes are considered, so use BIDTAG_DIPFMustNotHave with DIPF_IS_FOREIGN. The default value is defined as SPECIAL_FLAGS, which is (DIPF_IS_DUALPF | DIPF_IS_PF2PRI | DIPF_IS_HAM | DIPF_IS_EXTRAHALFBRITE) so you may need to OR your particular requirements with SPECIAL_FLAGS. BIDTAG_ViewPort An initializes ViewPort for which a mode ID is sought. For example, to find an interlaced version of a ViewPort: ID = BestModeID( BIDTAG_ViewPort, ThisViewPort, BIDTAG_MustHave, DIPF_IS_LACE, TAG_END); BIDTAG_NominalWidth BIDTAG_NominalHeight Together make up the aspect ratio of the desired mode ID. If specified, will override the Width and Height of the ViewPort passed in BIDTAG_ViewPort, or the NominalDimensionInfo of the ID passed in BIDTAG_SourceID. Defaults to 640x200. BIDTAG_DesiredWidth BIDTAG_DesiredHeight Nominal width and height of the returned mode ID. BIDTAG_Depth Mode ID must support at least this many bitplanes. Defaults to vp->RasInfo-> BitMap->Depth of the ViewPort passed in BIDTAG_ViewPort, or 1. BIDTAG_MonitorID The returned mode ID must belong to this monitor family. BIDTAG_SourceID BestModeID() will use characteristics of this mode ID, and override some of the characteristics with the other values in the taglist. BIDTAG_RedBits BIDTAG_BlueBits BIDTAG_GreenBits The mode ID must support at least these many bits for each color gun. Defaults to 4 bits each, so A2024 modes will not be considered. As an example of its use, here is a portion of the code for the V39 CoerceMode() function (which is used by Intuition when coercing screens): ULONG CoerceMode(struct ViewPort *vp, ULONG MonitorID, ULONG Flags) { ... /* Coerce the ViewPort vp to the best fit ModeID in the monitor * MonitorID. */ must = NULL; mustnot = SPECIAL_FLAGS; tag[t].ti_Tag = BIDTAG_ViewPort; tag[t++].ti_Data = vp; tag[t].ti_Tag = BIDTAG_MonitorID; tag[t++].ti_Data = MonitorID; if (GetDisplayInfoData(NULL, (APTR)&dinfo, sizeof(struct DisplayInfo), DTAG_DISP, ID)) { must = (dinfo.PropertyFlags & SPECIAL_FLAGS); mustnot = (SPECIAL_FLAGS & ~must); if ((Flags & AVOID_FLICKER) && (!(dinfo.PropertyFlags & DIPF_IS_LACE))) { /* we don't want lace if AVOID_FLICKER is set, * and this ViewPort is not naturally laced. */ mustnot |= DIPF_IS_LACE; } tag[t].ti_Tag = BIDTAG_RedBits; tag[t++].ti_Data = dinfo.RedBits; tag[t].ti_Tag = BIDTAG_GreenBits; tag[t++].ti_Data = dinfo.GreenBits; tag[t].ti_Tag = BIDTAG_BlueBits; tag[t++].ti_Data = dinfo.BlueBits; } tag[t].ti_Tag = BIDTAG_DIPFMustNotHave; tag[t++].ti_Data = mustnot; tag[t].ti_Tag = BIDTAG_DIPFMustHave; tag[t++].ti_Data = must; tag[t].ti_Tag = TAG_DONE; return(BestModeIDA(tag)); } As another example, consider an IFF display program with a HAM image, to be displayed in the same monitor type as the Workbench ViewPort. ID = BestModeID(BIDTAG_NominalWidth, IFFImage->Width, BIDTAG_NominalHeight, IFFImage->Height, BIDTAG_Depth, IFFImage->Depth, BIDTAG_DIPFMustHave, DIPF_IS_AM, BIDTAG_MonitorID, (GetVPModeID(WbVP) & MONITOR_ID_MASK), TAG_END); The definitions of the display mode ID keys have been moved from <graphics/displayinfo.h> to a new <graphics/modeid.h> file. The include file <graphics/modeid.h> specifically says that the individual bits of the mode IDs should not be checked for any meaning, but that the database should be read to glean information about the mode ID. In order to maintain compatibility with old software, and make the application writer's job somewhat easier, I am willing to guarantee that any mode ID with the bit 0x00000800 set is a HAM mode, and any mode ID with the bit 0x00000080 set is an ExtraHalfBrite mode. These are the only bits that are guaranteed to mean anything in the mode ID itself. These bits correspond of course to the HIRES and EXTRA_HALFBRITE definitions in <graphics/view.h>. Display Mode Promotion ====================== Promotion is a software solution for the lack of hardware deinterlacing circuitry on the AA machines. With the promotion feature enabled in Icontrol, the default monitor (NTSC on NTSC machines, PAL on PAL machines), becomes DblNTSC on NTSC machine and DblPAL on PAL machines. There are a number of advantages and gotchas with this approach. One advantage is that the graphics database is always truthful. Any enquiries about a default monitor mode ID will yield information relevant to whatever the default monitor happens to be at the time. This should not be a problem for any code written for V37 onwards, as the default monitor has always been either NTSC or PAL; now, there are just more possibilities. Another advantage is that V39-aware software that requires NTSC or PAL modes (e.g., video titling software), can now get such modes using specific NTSC or PAL mode IDs. Here is a list of "gotchas" (that is, things to watch out for if you want display mode promotion to work correctly). 1) The default monitor is dynamic, and can change at any time. Therefore, do not cache any information about the default mode IDs, but read them from the database as you need them. 2) There is no equivalent in the Dbl... monitors to the SuperHires modes. The database LVOs sniff out SuperHires mode IDs for database enquiries, and map SuperHires mode IDs to the equivalent Dbl... Hires mode IDs if promotion is enabled. 3) Programs that rely on copper timings for UserCopperlists, such as SHAM displayers, may no longer work when promoted, because each line is shorter in time than the NTSC/PAL line. Therefore, there are less coppercycles per line. 4) Promoted ViewPorts have less sprites available than non-promoted ViewPorts. 5) For compatibility, we do not promote 1.3 style custom ViewPorts and Views (we check for the presence of a ViewExtra). Miscellaneous ============= Interleaved screens have been added. These use a different layout of the graphics data in order to speed rendering operations and eliminate the annoying "color-flash" problem which is the hallmark of planar (as opposed to "chunky") display architectures. Set the BMF_INTERLEAVED flag when calling AllocBitMap(). Double buffering functions have been added. These allow applications to display very smooth, synchronized animation in fully an efficient "Intuition-friendly" manner. Call AllocDBufInfo() to allocate and initialize the DBufInfo structure, which is then passed to ChangeVPBitMap(). The double-buffering functions return up to two different types of messages. The first (dbi_SafeMessage) tells your program when it is safe to write to the old BitMap. The second (dbi_DispMessage) is sent when it is safe to call ChangeVPBitMap() again and be certain the new bitmap has been seen for at least 1 field. The autodocs for AllocDBufInfo() has example code showing how to safely double buffer with ChangeVPBitMap(). The DBufInfo structure should be freed with the FreeDBufInfo() function. Due to the extra colours that need to be loaded in deeper AA screens, the gap between screens can now be greater than the three lines that Intuition traditionally kept. In fact, the number of lines between screens is variable, depending on the screen type and depth. A new function CalcIVG() (CalcInterViewPortGap) has been added to calculate the number of lines required by the copper to execute all the copper instructions before the display window is opened. Note however that CalcIVG() returns the true number of lines (rounded up to the next whole line) needed in ViewPort resolution units, but Intuition still maintains a gap of at least three lines between Screens. Therefore, when calling CalcIVG() to position screens in an Intuition environment, use the result of MAX((laced ? 6 : 3), CalcIVG(v, vp)). There is one other caveat with respect to CalcIVG(). This function works by counting the number of copper instructions in the ViewPort->DspIns list, which is set up by MakeVPort(). If an Intuition screen is opened behind, then MakeVPort() is not called on that screen's ViewPort until it first becomes visible, so calling CalcIVG() with that screen's ViewPort will yield a result of 0. Some operations have been sped up: RectFill() has been rewritten, WritePixel() uses the CPU (3x speedup) ScrollVPort is 10 times faster, and other optimizations. Bugs and Anomalies ================== There is a big bug in the V37-V39 graphics hash-table code, which is used to associate a ViewExtra with a View; namely, only 8 Views can have ViewExtras attached to them. This has been fixed in the latest SetPatch and Kickstart. ScrollVPort() and ChangeVPBitMap() have problems with 8-bit HAM mode. This has been SetPatch'ed. Many other outstanding bugs have been fixed for V39. Table: New AA Modes (In Addition to Modes Supported by ECS) Mode Planes Colors Bandwidth (See note 1) ---- ------ ------ ---------------------- LORES (320x200) 6 64 1 7 128 1 8 256 1 8 HAM 256,000+ (see note 2) 1 HIRES (640x200) 5 32 2 6 EHB 64 (see note 3) 2 6 HAM 4096 (see note 4) 2 6 64 2 7 128 2 8 256 2 8 HAM 256,000+ (see note 2) 2 SUPERHIRES (1280x200) 1 2 (see note 5) 1 2 4 (see note 5) 1 3 8 2 4 16 2 5 32 4 6 EHB 64 (see note 3) 4 6 HAM 4096 (see note 4) 4 6 64 4 7 128 4 8 256 4 8 HAM 256,000+ (see note 2) 4 VGA (160,320,640x480 non-int.) 1 2 (see note 5) 1 2 4 (see note 5) 1 3 8 2 4 16 2 5 32 4 6 EHB 64 (see note 3) 4 6 HAM 4096 (see note 4) 4 6 64 4 7 128 4 8 256 4 8 HAM 256,000+ (see note 2) 4 Notes: 1 - The "Bandwidth" number describes the amount of fetch bandwidth required by a particular screen mode. For example, a 5 bit deep VGA screen requires the 4x bandwidth fetch mode while a 1 bit VGA screen requires only the 1x mode.. This translates to the hardware having to move data 4 times faster. To be able to move data at these higher rates, the higher bandwidth modes require data to be properly aligned in CHIP memory that is fast enough to support the bandwidth. Specifically, bandwidth fetch mode factors of 1 require data to be on 16 bit boundaries, factors of 2 require 32 bit boundaries, and factors of 4 require 64 bit boundaries. Restrictions like these are the best reason to use the system allocation functions whenever data is being prepared for the custom hardware. It is not guaranteed that all machines that have the new chipset will also have memory fast enough for the 4x modes. Therefore, the ONLY way to know whether or not the machine will support the mode you want is to check the Display Database. 2 - New 8 bit HAM mode uses the upper 6 bits for 64 24-bit base register colors or as a 6 bit modify value, plus the lower 2 bits for 18 bit hold or modify mode control. This mode could conceivably allow simultaneous display of more than 256,000 colors (up to 16.8 million, presuming a monitor / screenmode with enough pixels.) Please note that while the register planes and control planes are internally reversed in 8 bit HAM (the control bits are the two LSBs instead of the two MSBs), programs using graphics.library and intuition.library (i.e. Screens, BitMaps) will not have to deal with this reversal, as it will be handled automatically for them. 3 - This is like the original EHB mode, but in new resolutions. It uses 5 bits to yield 32 register colors, plus a sixth bit for 32 colors that are 1/2 as bright. 4 - This is like the original 6 bit Ham mode, but in new resolutions. It uses the lower 4 bits for 16 register colors, plus the upper 2 bits for modify mode control. This mode allows simultaneous display of 4096 colors. 5 - These modes are unlike the old VGA and SUPERHIRES modes in that they are not restricted to a nonstandard 64 color palette.