let's have some closer look at the problem. in fact there are some operations the blitter can perform quickly, in some cases even quicker than the cpu could do (i.e. copying while applying additional logical operations, masking and shifting of the source and/or destination data. and yes, i agree that a plain copy can be done much faster even by a 030 @16Mhz with a 16bit bus. to learn more about the blitter's abilities you might read this article). to get an idea of the blitter timings take a look here.

well, concerning the scaling, at least there is a way to speed this up using the blitter - i didn't believe this until i heard how it works: the blitter is able to speed up gouraud shading and even further texturemapping of a row on the screen !
however, i will only discuss how to draw gouraud shaded lines using the blitter, here as it's the only thing i implemented yet. the texturemapping method works out a bit diffrently and it's not as simple, so i won't cover that. additionally, the whole idea becomes useless as futile as soon as you start using the dsp which literally can do almost everything faster than the cpu or the blitter ever could do - though, if your demo uses a mp2 dsp-player this method could come in handy to speed up your gouraud shader a little bit.

now let's return to the scaling problem - the blitter has two signed 16bit variables "_SrcXinc" and "_SrcYinc" which are used to tell it the amount of words the source pointer should get incremented after a word either a row. now to scale a line we'd need an fractional increment. but this fraction can - and this is the actual idea of the technique - achieved by interpreting those variables, diffrently. instead of scaling down a fixedpoint value each time you want to draw a pixel you can scale up your texturerows or whatever by the same amount instead, since that's the only way to tell it the blitter. the good circumstance is that the blitter adds this increment for free without speending any additional cycles, which is the reason why it works quicker than being done by the cpu.

gouraud shading then works out by using a huge upscaled gradient of truecolor words reaching from shade 0 to your brightest color, let's say 63. using 8 bits fraction your table would become 2*64*256 bytes = 32Kbytes large. to map a row all you need to do is set up the apropiate screen word into the destination pointer, the color of the left pixel inside your gradient as source. the color delta gets fed into the "_SrcXInc" variable. ah yes, and don't forget to tell him the length of the row before you start the blitter, finally. oh and please run in shared mode, otherwise your interrupt timing might get screwed a bit. little speed hint: for triangles the delta remains constant, so no need to recalculate that one per row.

here's some pseudo-code to show you how it works: