In order to perform a conversion of some chunky-graphics data to the planar-graphics data format, you need to use Mc2p which performs this `chunky to planar' conversion. Without doing this it is not possible to view your chunky-graphics on the display, due to the fact that they are normally stored in `non-displayable' fastram.

Before this can be achieved you must have already set up a c2pWindow object using Mc2pWindow, which in turn needs to be preceeded by MReservec2pWindows. Please look at the documentation for the other parts of the c2p system in order to be sure that you have set up things in the right order and have taken into account the limitations of the system, such as only being able to use one fixed planar height at a time, and the caution needed to ensure that the c2p interlacing will work properly.

Once you are happy that a c2pWindow object has been setup correctly you can proceed to perform the c2p conversion operation. The c2p routine will take into account the settings specified with M040c2pUsage and Mc2pCPUmode to select the appropriate cpu-optimised routine to use.

At its simplest you only need to specify an address at which you plan to output the planar non-interleaved data from the converter. This should generally be an address aligned to the nearest longword, because it is especially important to output to longwords in chipram (planar data should be in chipram!) due to the access speed restraints that chipram brings. Outputting to an unaligned address in chipram will cause possibly a 50% drop in performance. You also have to be sure that your planar memory area is large enough to hold 8 bitplanes for the given size of the display, and that you have set up a c2pWindow object appropriately to represent this size. I recommend reserving some memory first and seperately, and then using the blitz CludgeBitmap command to turn it into a normal blitz Bitmap object. If you use InitBank for this purpose, then you can use Bank(n) to pass the base address of the memory to CludgeBitmap and also as the planar memory address to Mc2p. Using this technique of cludging onto reserved memory will ensure that the bitmap is non-interleaved, has no line modulo, and that all bitplanes are contiguous. Note also that you should create an 8-bitplane bitmap due to the fact that the chunky data is 256-colours. You should also ensure that the planar bitmap's width is generally a multiple of 64 and aligned to memory a memory address that is a multiple of 8 bytes if possible to ensure that the o/s will use the fastest possible fetchmode. Lower fetchmodes will hinder the c2p performance.

When specifying only the planar memory address to output to, the system will `assume' which c2pWindow to use, based on previous calls to MUsec2pWindows, MUsec2pWindow and possibly if MAutoUsec2pWindows was active when a c2pWindow object was created. This `currently used' c2pWindow object will be used to describe the size of the operation. Also, having not specified a chunky memory address, ie the address at which your chunky data is stored and should be taken (which can be an unaligned address), the system will assume the currently used chunky Bitmap object to manufacture a suitable source address. This object will have been specified with a call to MUseBitmaps, MUseBitmap or will have been automatically set by having created a chunky Bitmap object when MAutoUseBitmaps was active. To calculate the address, the routine will take the base data address of the Bitmap's memory. If the Bitmap has `wrapping' active (see the relevent section of the manual), then the Bitmap's origin will be used to create an offset, which will be added to the base address. Also if the Bitmap has `clipping' active (see the relevent section of the manual) then the clip window's top left corner will be used to create an offset which will be added to the base address as well. This final address will be taken to be the source chunky address from which the c2p routines will read the chunky graphics data.

It is possible in the second variation of the parameters, to specify the chunky source address yourself, in which case you should simply pass a longword address pertaining to the place in memory that you wish to convert data from. This should correspond to the top left corner of the rectangle to be converted and the chunky data should preferably be in fastram. In the long form of Mc2p you can also specify a c2pWindow object number if you wish to do so.

Once the routine actually begins, chunky data will be converted into planar data in groups of longwords and written to the planar destination in a viewable format. You will need an 8-bitplane display, ie AGA. Of course, if you have a graphics card you will not need to use the c2p system at all, as you can use something along the lines of the o/s function WritePixelArray8 or WriteChunkyPixels to directly copy the chunky data to the graphics card.

Possible syntax:
Mc2p Planar.l

Mc2p Chunky.l, Planar.l

Mc2p c2pWindow.w, Chunky.l, Planar.l

c2pWindow.w ---- This parameter allows you to specify a c2pWindow object to use in order to define the size of the operation to be performed. This c2pWindow object should have already been correctly setup by using the Mc2pWindow instruction. c2pWindow objects are numbered from 0 upwards to the total number of windows minus 1. If omitted, the currently used c2pWindow object will be used.

Chunky.l ---- This is a longword address of the memory location in which your chunky data is stored. It has little impact on the conversion process to have an unaligned address, meaning that you can position the top left corner of the chunky data to be converted with pixel precision, which effectively allows you use to the c2p conversion as a `software scroll'. Omitting this parameter will force the c2p system to calculate a chunky address based on a chunky Bitmap and also possibly its Origin and clip window top-left corner. Please also refer to MBitmapPtr, MShapePtr, MStencilPtr and MCookiePtr for a way to provide a chunky address more easily, based upon a chunky Bitmap or Shape, a Bitmap's stencil or a Shape's cookie, also with additional Xoffset and Yoffset coordinates to assist in map-tile type systems. Chunky data should be in fastram.

Planar.l ---- This specifies the planar memory address to which the routine will output the displayable image data. Generally this address should be aligned to the nearest 4 bytes, ie longwords, because outputting to unaligned addresses in chipram (where your planar memory should live) will cause horrendous slow-down in the conversion process. The main reason for moving to chunky-format graphics in the first place is to escape the bottleneck of chipram memory-access speed restraints. Generally you can specify the base address at which you have cludged your blitz Bitmap object, allowing the c2p routine to handle any scrolling in a `software' fashion by specifying or creating an unaligned source chunky address. Planar data should be in chipram.