Anyone more familiar with the SCC than I am have any thoughts on this?
I'll try to jump in with my thoughts here, but I think cheesestraws pretty much covered it.
I believe: The SCC provides two signals: "missing clock" and "SDLC Frame in Progress". The latter requires byte sync and the SCC can detect that it has lost a clock faster than it can detect that it has gained one. It does not seem to provide a "something's going on on my pins but I don't know what yet" signal.
Page A-3 in Inside AppleTalk talks a little bit more about these two indications:
Note: A frame cannot be detected until a complete flag has been transmitted on the line and
recognized by the hardware. On the other hand, the synchronization pulse sent before
frames and the resulting missing clock detected by receivers provide a more immediate
indication of an ongoing transmission (see Chapter 1, “LocalTalk Link Access Protocol”).
Missing clock indicates the detection and then the absence of a clocking signal on the line.
The synchronization pulse is clearly designed around the "missing clock" detection feature of the SCC. In Appendix B there's a bunch of sample code for doing LocalTalk with the SCC, which is what I used for my SCC LocalTalk bridge implementation. In the notes, it talks about missing clock being the "one clock missing" bit in RR10 of the SCC. In the sample code, there's only one place that bit is checked, and it's in the transmit routine immediately after the random wait period. After the wait period, it checks both the byte sync bit (RR0 bit 4) and the "one clock missing" bit. As long as there's no byte synchronization *and* it hasn't seen a missing clock, it will proceed with a transmit by sending its own sync pulse followed by an RTS or ENQ. Otherwise, it knows someone else has already started transmitting, and it backs off. (BTW, thanks for bringing this up -- my SCC code was only doing the sync pulse with RTS, I should add the sync pulse on ENQ as well).
So as far as I can tell, it's just about minimizing collisions. It's pretty SCC-specific, but it allows every other device on the bus that uses an SCC to more quickly detect that you've started transmitting. I believe if you don't send the sync pulse, it's going to be slightly more likely that another SCC-based LocalTalk device clobbers your transmit because there's that (small) window during your first flag byte being transmitted where it hasn't achieved byte synchronization yet, but it thinks the bus is still free because you didn't send a sync pulse so it has no other way of knowing that you're in the middle of transmitting already. So you'll effectively end up with less efficient use of the bus because of more collisions.
I thought there was wording in there that implementing missing clock detection was optional for non-SCC implementations of LocalTalk, but I can't actually find that now, so I might have dreamed it...
Based on what I'm seeing, they wouldn't have said that -- any other LocalTalk device on the same bus that has an SCC would be dependent on this sync pulse being there to know sooner that someone else beat it to transmitting the next frame. With that said, I'm guessing that it matters more on loaded LocalTalk buses and it's going to be much less of an issue if it's just a tiny 2-device LocalTalk network (the PIC and a single Mac).