looking at yoomp on youtube.. this is very much possible i think..
the basic tunnel effect is a fixed offset map affair, which can be optimised heavily (which is why you see this kind of effect in ST/Falcon demos)..
for speed you'll have to do chunky pixels (160x100)
you essentially bypass the C2P stage by hardcoding the offsets into the tunnel texture directly into your screendraw routine..
furthermore, you need to convert your texture into friendly pre-shifted pixel packets(!) for the routine to use directly.
if a0-a3 is your preshifted 'texture' formatted to chunky pixels already, and a4 is your screenbase:
then your screendraw is simply:
move.l xxxx(a0),d0 ;pixel 1+2
or.l xxxx(a1),d0 ;pixel 3+4
or.l xxxx(a2),d0 ;pixel 5+6
or.l xxxx(a3),d0 ;pixel 7+8
movep.l d0,xxxx(a4) ;write 8 pixels
movep.l do,xxxx(a4) ;next same 8 pixels to next scanline
so you generate a massive block of code above, and 'poke' for every position the offset into the texture, and poke the destination screen addresses (xxxx(a4))..
to scroll through the tunnel, you change your start offset into the texture.
of course, you're not scrolling a texture, you're scrolling a tile map.. so would need some thought, but essentially you'd have to regenerate the texture on the fly, shouldn't be too expensive to populate 1 row of tiles, over a number of frames..
you could optimise the screendraw further by reducing the c2p code block to only the dirty area drawn.
i think it's possible anyway with some effort. Ray of TSCC wrote a really nice series of docs about C2P and how to do away with it altogether for these kinds of fx, i can't find it online but it must be out there somewhere.