Maybe I can rewind this handshaking discussion for a moment. I think you had a fair point, BDD, when (in
this post) you objected to the phrase Garth included in his
printer article which states, "You do need to pay attention to the busy line."
BigDumbDinosaur wrote:
Many years ago, I concocted a Centronics interface for my Commodore 128 through the user port, which is wired to CIA #2. The handshaking was /STROBE and /ACK
Right. With the approach Garth chose, one does need to pay attention to the BUSY line. But with the approach you chose, one
doesn't, and the wording in Garth's article seems to deny that (although inadvertently, I expect).
So, it's reasonable to draw attention to the narrow context of Garth's phrase. But then you go on to argue that BUSY is not only unnecessary but actually flawed -- "not entirely trustworthy as a handshaking line" -- and I see issues with both of your lines of reasoning in this regard.
I get that you have concerns about data corruption resulting perhaps from interrupts and too-fast machines, but these concerns seem vague and shapeless -- you haven't spelled out an a, b, c sequence that would result in a failure. It's good to be on the lookout and anticipate potential timing problems, but I don't believe those problems are unmanageable. And telling us to be on the lookout is different from telling us the BUSY method isn't trustworthy.
BigDumbDinosaur wrote:
Also note that BUSY is high-true, but /ACK is low-true. There is a reason for that...in handshaking, low-true is usually considered the more reliable arrangement due to limitations of TTL totem-pole outputs.
Oops, we had a run at this before and got nowhere... perhaps because I failed to quote the specific comment I was responding to, so this time I am including it.
You seem to be saying a wise decision was made when the polarity of /ACK was defined but a poor decision was made when the polarity of BUSY was defined, is that right? I'd say both decisions were wise, and I can't help wondering if you suffered a titch of mental flatulence, as any one of us might. Names can be distracting. BUSY could just as easily have been named /READY and yet its behavior would be the same. (And of course it's behavior that matters. I talked about this in the final paragraph of my previous post.)
-- Jeff
ETA: Still not confident I've made myself clear; so, for anyone still wondering... Electrical noise can get superimposed on a signal in transit from the printer back to the host. And, recalling that TTL voltage levels are used, we know it takes only a volt or so of noise superimposed on a TTL low to create a momentary error during which the signal appears high. Thus a false high can occur fairly easily. But it would take more than a volt or so of noise to cause a TTL
high to seem like a
low, and thus a false low is comparatively unlikely.
The writers of the printer interface specification can't change the quirks of TTL, but they do get to choose whether they'll use a high or a low to mean "proceed." Given that a false low is comparatively unlikely, they're wise to use low to mean proceed. That's because it's a critical error for handshaking to proceed prematurely. They're wise to use a low to mean acknowledge and they're wise to use a low to mean ready.
Login
Register
FAQ
Search
), but as I said above, the client only needed three. With all four simultaneously printing, the C-64 had its work cut out for it. 
