"stop bits"; was: NEC uPD7201 misfeature

On Fri, Jan 24, 2014 at 11:03:36AM -0500, Paul Koning wrote: Almost definitely showing my own ignorance (I'm very new to serial comms), but my impression is that in the old days, synchronous ports *always* used a modem-supplied (etc.) external clock signal, and it's only newer fancy-pants ports like the Zilog Z85(2)30 that try to be cute about using a PLL to derive a clock from transitions in the bit stream. So my understanding (correct me!) was that sync characters exist for, well, sync (i.e. byte framing -- getting to a character boundary for sure, when it's possible the receiver wasn't listening or just started up), and idle characters are to maintain that byte framing when you don't have anything else to send, i.e. TX underrun (because if you just sent a variable amount of "mark" like an async line, you'd lose your byte framing when you started sending valid data again). And bit-stuffing in SDLC is just there to make sure that the 01111110 flag character that begins/ends packets can't possibly occur anywhere except in those places (this is a huge bug in DDCMP -- if a header gets garbled, the receiver can be fooled by a fake packet contained entirely within the data field, which is delimited only by a byte count in the header). But through all of this there's a 1x clock coming in the RxC/TxC pins on the DB25, either from the modem, or on a local connection, from a 1x BRG in one of the ports that has been strapped to drive it onto the connector. ANYWAY so the point of the SYN character is not to have a certain # of guaranteed transitions, but to be intentionally lopsided so that no rotation of it can be mistaken for valid (e.g. 55h would be useless as a sync char), so that a receiver in "sync search" mode can click into position and be ready for the LSB of the real data. OK rip me to pieces. John Wilson D Bit