If pic1 sends a message to pic2 it will remain in pic2s buffer until pic2 gets around to checking for messages. So all I needed to do was send a message and wait for an answer in one pic, and the reverse in the other.
So pic2 will send message A to pic1 regardless if it's ready or not, and wait for a reply. This message will remain in pic1's buffer until pic1 is ready to read. When it finds message A it will send message B to pic2 in return, and continue with it's program. Pic2 has waited a while but has now received message B so it is now sure about the position of pic1's software and can continue also.
l
If pic1 happens to be at the checkpoint first, then message A hasn't arrived yet (obviously). So pic1 waits for the message to arrive, confirms by sending out message B and both pic's are off again. So no matter who gets there first this methodology always works.
l
The example programs basically look like this. Pic1 is running a 'long' program with lot's of delays. Pic2 on the other hand is running a very short program and bound to be at the checkpoint first (in the real program pic2 has a yellow led and a small time delay also for more viewing pleasure). So pic2 runs very quickly, and the has to wait each time for pic1 to catch up.
l
The schematic is straight forward, basically it doesn't do anything except power the PIC, provide serial connection to the PC and foster two yellow led's. These led's serve no real purpose other than observing that the programs are still running (and in synch). And besides: who doesn't like flashing lights? Well, apart from you...
http://members.home.nl/b.vandam/lonely/pagina15.html
