Here are a collection of fast chunky to planar routines for use in your Blitz programs. I did not write any of these c2p's, I only did what was necessary to get them running as Blitz sourcecode. There are currently 6 c2p's to choose from. c2p030: Mainly for the 68030 This c2p is meant to be used mainly on 68030 cpu's. It doesn't work all that well on other cpu's. This is a cpu-only c2p and does not use the blitter in any way. It is probably optimised with 030's in mind. c2p040only: Mainly for the 68040 This c2p is dedicated mainly to the 68040. It is optimised for that processor and works very well on it. Being a 68040 user myself this is by some marjin the fastest c2p of the lot. Came in joint first for anything higher than 040/25 also. c2p040plus: For anything from 68040 upwards This routine is kind of generic but aimed at any cpu from 68040 upwards, so that includes 040/40, 060/50 and 060/66. This scrapes in about third place in terms of speed. c2p060only: Mainly for the 68060 Apparently this one is written especially for 060 cpu's but even so it is not the fastest of the bunch. Just thought I'd include it anyay. Probably not designed for good performance on lower processors. c2pGeneric: For anything from 68000 upwards This is an all-round generic c2p. Performance is generally pretty low but there are probably some tradeoffs to give general all-round acceptable results. c2pCache : For anything from 68040 upwards This routine is different from the others, written by somebody else. It uses some caching tricks to try and go even faster. For 040/25 this comes in as second fastest and was also about joint first on 060's also. This routine is not designed to be used on 030's. Some general performance times for the routines are as follows. These times are inclusive of having a screen open and being displayed, of the specified dimensions, in either PAL or DoublePAL: c2p030 040/25 results: 320x200 @42fps DoublePAL or 44fps PAL 320x256 @31fps DoublePAL or 34fps PAL 320x240 @33.6fps DoublePAL or 36.5fps PAL c2p040only 040/25 results: 320x200 @49.65fps DoublePAL or 55.3fps PAL 320x256 @36.2fps DoublePAL or 42.5fps PAL 320x240 @39.5fps DoublePAL or 45.5fps PAL 060/50 results: 320x256 @50fps PAL 320x200 @66.1fps PAL c2p040plus 040/25 results: 320x200 @46fps DoublePAL or 49.2fps PAL 320x256 @34.2fps DoublePAL or 37.9fps PAL 320x240 @37fps DoublePAL or 40.6fps PAL 060/50 results: 320x256 @50fps PAL 320x200 @66fps PAL c2p060only 040/25 results: 320x200 @46.0fps DoublePAL or 48.2fps PAL 320x256 @34.2fps DoublePAL or 37.4fps PAL 320x240 @37.1fps DoublePAL or 40.1fps PAL 060/50 results: 320x256 @50fps PAL 320x200 @66fps PAL c2pGeneric 040/25 results: 320x200 @42fps DoublePAL or 44fps PAL 320x256 @31fps DoublePAL or 34fps PAL 320x240 @33.7fps DoublePAL or 36.5fps PAL c2pCACHE 040/25 results: 320x200 @47.1fps DoublePAL or @50fps PAL 320x256 @35.3fps DoublePAL or @38.3fps PAL 060/50 results: 320x256 @49.6fps PAL 320x200 @66.1fps PAL All of the routines except for c2pCACHE allow you to specify the size of the chunky-to-planar operation. This can be specified any number of times during a program's execution. c2pCACHE has to have its dimensions set in constants before compilation. c2p040plus has a self-modifying-code routine that is meant to allow you to alter some stuff that are normally in constants, but it doesn't work so I would advise avoiding it. It is not generally necessarily. All you have to do to setup a c2p operation is something along these lines (for example): InitBank 2,320*256,$10000 ; Fastram chunky buffer InitBank 0,320*256,$10002 ; Chipram planar buffer CludgeBitmap 0,320,256,8,Bank(0) c2pGenericInit{320,256} c2pGeneric{Bank(2),Bank(0)} Of course, replace the c2pGeneric statements with the ones for the relevent c2p that you are using. The only exception to this is c2pCACHE. This requires that you cludge bitmaps to 8 bytes past the start of the planar buffer, and that you tell the c2pCACHE routine to output to an address 4 bytes past the start of the planar buffer. So you have to allow for this by reserving a little extra memory. Like this: InitBank 2,320*256,$10000 ; Fastram chunky buffer InitBank 0,(320*256)+8,$10002 ; Chipram planar buffer CludgeBitmap 0,320,256,8,Bank(0)+8 c2pCACHE{Bank(2),Bank(0)+4} As you will also notice, for c2pCACHE there is no c2pCACHEinit{}. The size of the operation has to be set in constant variables. One thing to note is that you have to define the dimensions of the planar bitmap in constants. The size of the chunky operation is variable, and is set with the init{} routines. But it looks like you have to stick to one planar size. It takes those constants into account when working out where to write data to. In a sense this is a verticle modulo. Once constants such as #c2pBPLSIZE are set in the program they cannot normally be altered. You can open other sized screens and if they use precicely the same amount of data as what you originally specified the new size will work. If you define that your screen is going to be 320x256, you are free to re-initialise the c2p routine to do 320x200, 320x256, or perhaps 320x100 operations at different points in the program, and it will work so long as you are still outputting to the same planar bitmap size. The only way to overcome such limitations is to do some self-modifying-code, if you're up to it. There are no line modulos and generally if you're working in chunky you will only have one size screen and therefore one size operation throughout the entire program, regardless. There is/are some routines for c2p's which have modulos and possibly non-contiguous bitplanes, but I suggest these are hindered and therefore quite slow. The rules that these c2p's impose can be easily worked around. And I would suggest that if you want to do hardware scrolling you would be better off doing a software scroll routine rather than having to have an extra 64 pixels width to the c2p operation. ALWAYS work in fetchmode 3, or if in AmigaMode, make sure that bitmaps are aligned to the nearest 64 pixel widths and to the nearest 2 longwords in memory. The o/s will check that data is 64-bit aligned and use the fastest datafetch mode (which increases c2p performance). If you should happen to do hardware scrolling further than 32 pixels horizontally, or your bitmaps are not a multiple of 64 pixels wide, the o/s will automatically switch the datafetch to 32-bit mode and you will suffer a performance loss. This is why my notes about c2pCACHE have placed the bitmaps to the nearest 8 bytes rather than just adding 4 bytes. NEVER use fetchmode 0 not even for lores screens as this will slash the c2p performance in half. The o/s, if in AmigaMode, will automatically choose fetchmodes depending on wether the first byte of bitplane data is aligned to the nearest 2, 4, or 8 bytes. If you can't get the c2p's working I probably can't do anything about it unless it's just a blitz problem or one of just getting the thing running. You can email me, Paul West, at paul@stationone.demon.co.uk I hope you enjoy these c2p routines and are thankful for those talented people who have created them for public use. You are free to use them and any blitz source I have added in my implementation examples, for freeware, shareware, and commercialware. I would be happy to hear of your c2p endeavours, what you're using it for, how it performs for you on your system, and anything else related. Enjoy.