Well, I think it's safe to say that I'll never complete this run, so here's some resources I dug up from my PM box.
http://dehacked.2y.net/microstorage.php/info/640070465/Chip%20%27n%20Dale%20Rescue%20Rangers%20%28U%29%202playertestrun.fm2 - almost completed test run
http://dehacked.2y.net/microstorage.php/info/221249344/Chip%20%27n%20Dale%20Rescue%20Rangers%20%28U%29%20TASL1.fm2 - zone 0 better optimized
The most important RAM addresses:
68 - chip's x pos
470 - chip's x-sub pos
510 - chip's y pos
460 - chip's y-sub pos
69 - dale's x pos
471 - dale's x-sub pos
511 - dale's y pos
461 - dale's y-sub pos
To execute the zip glitch one player must throw the other one frame before hitting the ground, then wait for 2 frames and then jump into him. What y-pixel you need to be at when throwing the other player depends all on the characters' y-subpixel values. In order to get the zip to work while throwing from the same y-pixel as the platform you're about to land on you should aim to have the carried character's y-subpixel value to be as low as possible (when being carried) and the other one's as high as possible (at the frame before you jump into the other one). Just think about that the highest subpixel for this character is 170 since the game checks for what the next value would be which is 170 + 85 = 255, for the carried character this isn't the case though and thus the lowest subpixel value is 0 instead of 171. It doesn't need to be perfect though, I don't know where the exact line is between it working or not but the margin is at least 100 subpixels combined, meaning if you can get the subpixel value 50 with the carried and 120 with the other it should still work. If the subpixels are arranged differently you must either throw the other character from 1 or 2 pixels above the ground (depending on how the subpixels are set).
Apparently the screen scrolls slower if Dale is first of the characters while zipping.