In this version ropes can be specified for position and length. It will also be noted that the ropes do not pick up willy when they pass though an object. It is permissible for other sprites to cross the ropes path. It is also permissible for ropes to collide with each other.
I would hazard a guess that the way that was achieved was by modifying the rope-drawing code, so that collisions are detected in the same way as the arrow-drawing code. i.e. a pixel-collision has to take place when a segment of rope is drawn AND the attribute of the cell within which that rope segment is being drawn also has to have a white INK setting?
The above approach may be more appropriate for optimising the horizontal guardian movement in Manic Miner (i.e. having a shared set of commands for both left and right movement), since the guardians 'face themselves' in their sprite pages rather than being 'back to back', and as a result there would not be a need to swap the two halves of each sprite page. I haven't tried it out yet though.
Having thought about the above, I'm not sure if it's feasible to come up with an arrangement that's more byte-efficient than the current one.
Firstly, the direction of travel for horizontal guardians would have to be determined from Bit 2 of Byte 04. But there's no easy way of checking when the value in Byte 4 has spilled over past Bits 0-2, other than by checking for the individual values 08 or -01 (#FF). The Carry Flag wouldn't respond in these circumstances.
Maybe if all the values for animation frame were doubled (and the 'Draw the horizontal guardians' routine was amended accordingly, with an additional RRCA inserted at #8DD0), then the Half-Carry Flag could be used. But I don't think there are any Z80 instructions (conditional jumps etc) which are determined by the status of the H Flag.
You would need to fundamentally change the function of Byte 04 for horizontal guardians - edit all the horizontal guardian data, so that Bits 5-7 holds the animation frame (with Bits 0-4 unused, although perhaps they could be recycled for other purposes?), rewrite the 'Move the horizontal guardians' routine in accordance with my previous post, and then NOP out the three RRCA's in the 'Draw the horizontal guardians' routine at #8DCE-#8DD0.
Probably not worth the hassle.
To contradict myself again, I managed to get my suggested approach to work in Manic Miner.
I used three RRCA's at the start of the 'Move the horizontal guardians' routine to rotate the animation frame (loaded up to A) into Bits 5-7, and then three RLCA's at the end of the same routine to rotate the updated frame value back into Bits 0-2, before loading back into guardian Byte 04. (No need to change 'Draw the horizontal guardians'.)
Even with all those additional rotate commands, there are still at least ten spare bytes left over because of the merging of the left-right movement commands!
I've just noticed the Software Projects triangle rotating on the grassy area
Clarification: the above is sometimes the Software Projects triangle, but at other times it is the 'thresher' guardian. i.e. the sprite drawn in that position on the title screen depends on which version of the game you are about to play - corresponding to whichever vertical guardian appears in 'The Warehouse'.