so, I thought maybe I could speed up the link connection, and it seemed clear how...
Turns out the ti "black link" connection library that comes with tilp2 is a little awkwardly-written... It essentially swaps the two output circuits. There are two signal wires going to the calculator, red and white, and both are bidirectional. Reading each wire is accomplished from two RS-232 handshaking input lines, writing each wire is accomplished through two additional RS-232 handshaking output lines. This isn't dissimilar from the way it's allegedly done inside the calculator... One 8bit port is used for linking. Two bits are used for reading and two other bits are used for writing. In this case, reading occurs on bits 4 and 5 (0x30), and writing occurs on bits 0 and 1 (0x03).
There are MANY low-level code examples for linking via assembly from a calculator, and it appears tilp2's library is built on those examples. However, there is a difference in the two systems. On a calculator, a wire is tied low by writing a 1 to the appropriate bit. The Black link cable, however, doesn't invert it; writing 0 (not 1) ties the wire low.
So, on a calculator, writing, say, 0x01 will be read-back as 0x20. (0b01, both bits inverted gives 0b10... Reading occurs at the upper nibble, 0b10,0000.) Now, on a calculator, writing 0x03 results in both bits being low... Reading back would give 0x00. With the black link cable, however, writing 0x03 is read-back as 0x30. So, then, you might think writing 0x01 on the black link cable, since it's not inverting its outputs, would be read-back as 0x10, right? But, no, that's where it gets confusing, they swapped the output bits in the connection library code. Writing 0x01 (0b01) outputs 0x02 (0b10), and since the read-back wires are not swapped, it will be read-back as 0x20... Just like on a calculator. BUT, this only works when writing one bit high and one bit low. Again, writing 0x03 gives 0x30, and 0x00 gives 0x00, NOT 0x00 and 0x30, respectively, as on a calculator.
It's a clever workaround, swapping the two write-bits, because the code that handles 0x00, 0x30, and 0x03 are, frankly, trivial in comparison to the code that handles 0x01, 0x02, 0x10, and 0x20. Thus, that code could essentially be copy-pasted from one of the many known-functional examples written to be run on a calculator. Then, just swap-out 0x03 or 0x30 with 0x00, and vice-versa, in the few other cases.
BUT: it makes reading the code quite difficult, and comments frankly don't exist.
I set up an experiment which showed that bit transmissions can occur without any of the inherent handshaking built into the protocol... An entire bit transmitted without any calculator or other receiving device connected to even respond. It seemed the "handshaking" was a result of the bit-swap, the computer sees its own message /as/ the handshake, and thus transmits the entire bit as fast as it can regardless of whether the calculator is fast enough (or even connected) to receive it.
Now, the fact is, the calculator is probably far faster at handling the bit-transitions, via interrupts, than the black link cable and reading/writing RS-232 handshake wires... So, the above probably doesn't affect the transmission of the proper bit value.
Then, stupidly, I didn't save that experiment, except as a screenshot... So, when I finally understood the bit-swap, I went back to the original code... And... It seems it should be properly-implemented... And now I can no longer wrap my head around how that experiment could've worked, unless I messed something up. So... Now, back to the presumption handshaking is actually functioning appropriately... And... Now my ideas about how to speed up communication have been thwarted.
Thing is, I saw the experiment work (or not work, as the case may be), and improper handshaking is pretty much the only reason I can think of to cause communication to be so slow in the first place... The"delay" between each bit transmission should be unnecessary, handshaking should take care of that!
There's another thing...
The calculator seems to be exceptionally fast at handshaking /during/ the bit transmission... So fast that the serial port's wires (and read-functions) can't detect when it responds, because it's already responded by the time the next serial-port read is executed. So, the computer only detects the state thereafter, that it had responded. Now, that's fine for inside the bit transmission, but not between two bit transmissions... Because...
If the calculator responds as quickly to handshaking /between/ bits as it does /during/ bits, then there's no way for the computer to know whether the wires are signalling the beginning of the next bit, or still hanging there at the end of the last. (Depending on whether the two bits differ). Thus, inserting a delay assures that the calculator has had plenty of time to set up the next bit. Now, the weird thing is that the calculator seems to respond with the next bit quite some time /after/ the request for handshake indicating the end of the last bit... but when it does, it immediately starts the next bit, apparently assuming the receiver saw the extremely brief response which would only be detectable via an edge-interrupt. (Thus, again, the delay). Now, again, this doesn't seem quite right...
Supposedly, other cables are much faster. But by far the slowest part is the inter-bit delay... And, again, even minimizing it as much as possible to detect when one end-of-bit is visible because of a change to a different value for the next start-of-bit... Even then the delay has to be /significantly/ longer than the default values. And bit rates would be exceptionally slow (maybe 10bytes per second!) Again, not due to the black link cable, nor even due to the intermediate usb-dongle, but due to the slow inter-bit handling of the calculator itself. That can't be right, I'd surely remember half-hour-long backups from my old TI-82 days.
So... Frankly, I'm at a bit of a loss...
I think it means starting again from scratch, and I definitely haven't had that in me. I have tried to write this up three times, now... But how do yah write-up what you don't get?
I don't get it. I thought for sure, when that experiment gave the results I expected, I had it figured out... But now I can't even grasp how that experiment could have given those results. HAH!
(NOTE just checked, black link cable has only five wires!)