Before you can perform a conversion of chunky data to planar data, you must first of all tell the c2p system some information about the size of the operation to be performed. This information is embodied in the form of a c2pWindow object.
Having already reserved some space to store c2pWindows with MReservec2pWindows, you can create a c2pWindow object to describe the operation you require. At its simplest you can use the system to convert the whole of a chunky buffer to the whole of a planar buffer. In this case, both chunky and planar buffers must be exactly the same size and should not have any line modulos. You can just pass the width and height of the operation to be performed and Mc2pWindow will set up the object to describe the operation in a way that Mc2p can use.
Additionally you can specify what cpu is available. As there are 68030 and 68040 optimised c2p conversion routines, it is desirable to set which routine to use dependent on the avilable cpu. For this purpose you should use the `Processor' instruction that is a blitz instruction. `Processor' will return a number from 0 to 4 depending on your cpu. 0 to 3 will represent the 68030 c2p routine, whereas 4 will represent the 68040+ routine. All c2p routines will run on all 680X0 cpu's but if you get the system to use the routine designed for the given cpu you will achieve better performance. Specifying the Processor as part of Mc2pWindow does the same thing as if you were to seperately call Mc2pCPUmode. From a default startup Mildred will use the 68040 routine until you specify otherwise.
If you require a more sophisticated c2p operation, it is possible to provide three additional parameters which allow differences in the sizes of the source and destination. With this you can convert an area smaller than the destination and smaller than the source, such as to display part of a chunky superbitmap to an area in the display. The first parameter to pass is SourceBWidth, which is the width in bytes of the chunky buffer. This is the entire width, such as the width of a superbitmap. Byte width is the same thing as pixel width in chunky, as one chunky pixel is represented by one byte. Secondly you have to pass the width of the planar bitmap. Your planar bitmap should not have any modulos of its own because they will be ignored, and the bitplane memory should be contiguous and non-interleaved. There is no gain to be had from using interleaved displays with a chunky system that doesn't use the blitter.
The final parameter that Mc2pWindow needs is the height of the planar display. This height is used to create a value that the c2p routines can use to skip from a pixel in one bitplane to the same pixel in another bitplane. This value becomes `hardcoded' into the c2p program itself using self-modifying code. Therefore, the planar height should be the same for all c2pWindows that you intend to output to that particular planar memory area. For this reason, you cannot have a seperate `control panel' screen with its own planar height. Generally speaking, working in chunky means you are intending to have easy graphics-card support, and graphics cards do not generally support multiple resolutions on the same screen or copperlist palette-altering tricks. Your `control' panel should be of the same resolution as the main game area and incorporated into the same planar memory area, due to all c2pWindow's sharing the most recently defined planar height. Note also that even if you do not specify these three last parameters to Mc2pWindow, it will still set a new planar height based on the operation height.
If you are intending to use the row interlacing features of the c2p system, you should also generally ensure that the operation height is a multiple of 2, otherwise when the lace frame is alternated from even to odd, for example, it would attempt to output to a row at the bottom of the display which you haven't reserved memory for, resulting in a crash.
The width of a c2pWindow should be a multiple of 32 pixels, because the c2p routines work purely in longwords only. SourceBWidth and PlanarWidth, however, do not necessarily have to be a multiple of 32 but PlanarWidth should be a multiple of 8. The minimum size of a c2p operation is 32x1.
Creating a c2pWindow requires a flush of the datacache of the cpu, so is of questionable use for realtime changes of operation size and/or planar size, but the delay isn't very large at all so it is entirely feasible to have seperate planar destination areas such as seperate screens by defining the planar height within the main update loop of your software, although you should achieve this `legally' using the appropriate commands due some the self-modifying code that is needed to bring about this change.
Unless you are specifically intending to use more than one planar height in the same game-screen update, you should only need to call Mc2pWindow once for any number of following Mc2p calls.
Possible syntax:
Mc2pWindow c2pWindowNum.w, OpWidth.w, OpHeight.w
