did a quick test comparing the linking of the 83+ and 86 via blacklink cable through a usb converter... The results are nearly identical.

I did quite a bit of hackery to the tilp2 linking library a while back. One change was to verify the writes before moving to the next step. The result is interesting... in that the original ser_io_wr() write function pretty much directly calls the IOCTL to write the serial port's handhaking outputs. Now, reading them back uses the same ioctl as reading the serial port's handshaking /inputs/, which is used by ser_io_rd(). So, the question, I guess, is whether those /outputs/ are actually read-back via extra circuitry, or whether it merely reads back the value stored in the latches that eventually drive those pins. 

This comes up because: it almost always takes three write-verify attempts before verifying properly. This could be due to USB, as discussed in an earlier log; I /think/ when one requests e.g. a port-read through USB, it responds /immediately/ with whatever was read from the port /already/.

So, writing the output registers, then immediately reading them back... well, the read-back may result in what was on the latches /previously/, if the internal polling isn't particularly fast. But, Three attempts? Now I begin to wonder if it's actually reading back the values on the pins themselves! Weird, I'm pretty sure those signals are output-only...

Anyhow, the result, here, is that my write-verify technique results in many reads of all the handshaking inputs and outputs, but only pays attention to the outputs. Which could explain why some intermediate states go undetected, e.g. the moment between when the computer sends a change but before when the calculator responds to the change. From the way it looks, now, the calculator seems to respond instantaneously...

The problem with looking for that intermediate step doesn't present itself except between the end of one bit transmission and the beginning of the next. As I explained in a previous log, in some cases it's impossible, without seeing that intermediate state, to know whether the calculator has responded to the end-of-bit with the beginning of the next bit, or if it's taking a long time to respond to the end-of-bit. Thus the somewhat arbitrary (and surely far too long, in most cases) "delay" between bits.

So, my write-verifty technique may be catching then discarding that intermediate state, but I think the fact is it could just as easily be missed by a slow computer (or USB bottleneck) which can't perform a read in time. So, actually, it's kinda amazing it works at all, and part of that has to do with the fact that the only thing in the original code that looks for those intermediate states is a while-loop that usually just falls through immediately, because the intermediate-state is too fast to be detected by a read after a write.

But *IF* we could see that state, then the delays could be removed, and the communication would occur at the fastest rate possible, handshaking all the way.

So, I'm still pondering... If I do anything in this regard, I think I'd like to keep it compatible. I mean, sure, I could add an edge-detect flip-flop, and feed its output to an extra unused serial handshaking input (Ring Indicator)... but then I might as well be designing a new link cable entirely, no?

Similarly: TIOCMWAIT may be an option, but apparently few USB-Serial converters' drivers implement it. In fact, the PL2303 linux driver seems to have most of the groundwork which is only useful if it's there, but yet it's not implemented, and I'm pretty sure I recall reading in an email discussion regarding implementing it that basically "don't bother, since few USB-Serial drivers do." Which leads me to wonder if either A) someone wrote that groundwork unaware that the chip can't support it, or B) the chip can, but no one uses it since most folk have accepted the limitations of other chips.

And, regardless, then it becomes a question of end-goals... add TIOCMWAIT to the PL2303 driver, then add it to the tilp2 connection library, and now there's a *very* niche case for both...

OTOH, it should also speed up direct serial connections in tilp, so maybe not-so-niche... It would, however, make the code a bit less straightforward, since it'd have to detect whether the serial port supports it... and maybe open a can of worms with drivers which half-implement it... or that try to emulate its abilities through software which can't handle the /actual/ edge-detection (e.g. by polling the pin too slowly). 

So /then/ it becomes a question of TIOCMWAIT's actual intent (and others' use), which, basically, is I think to just wait until a handshaking line becomes active, or inactive, rather than actually trying to detect such a tiny pulse. So, using it here would be a hack in itself, and again niche, and again likely open a can of worms that could break tilp's blacklink connection library on many other systems, if not done carefully.

OTOH, it could be useful in other ways I don't yet forsee... e.g. most those softwares which use it are basically incompatible with USB-Serial dongles, but for no real reason, because it /could/ be implemented through polling, if it is as I expect, usually just used to wait for a handshake. At which point, if there are enough such softwares, then that polling could be implemented in the generic USB-Serial driver as a fallback, making it available to nearly all USB-Serial adapters, whether they bother to implement it in their specific driver or not... But, of course, it probably isn't the case that so many softwares still rely on that, since real serial ports are so rare these days. Heh!

(And, again, that polling fallback *wouldn't* help with tilp, since it might miss the tiny pulse!)

Makes me wonder how many programs exist out there that were once written for /more/ supplied/standardized-functionality, then had to be rewritten later for less, each independently reinventing that same wheel.

Anyhow... not sure where I'll go with this...

It'd be nice if there was some way to search e.g. all the sourcecode used in all the software maintained in some distro, say Ubuntu... (or, frankly, all opensource code). Does something like that exist online?