Typical project, for me... this has now "taken on a life of its own..."

I went in for vintage-computing learning... get me some new understanding in the Von Neumann realm which I've really only a dabbling in... (Even my PC/XT hackery is Harvard-Architecture! https://hackaday.com/2017/05/21/hackaday-prize-entry-a-pc-xt-clone-powered-by-avr/ ). A few other such things from the ol' Z80 realm, back when interfacing custom hardware directly to the CPU was actually a thing... (and not very different from today's microcontroller-based or otherwise embedded-systems)... such-like. Aside from the nostalgia and a bit of learning along the way, it was also to be a bit of an excursion toward getting back into projects in general... more on that later. But the immediate goal was simple, mess with z80 hardware/software that handily was handheld.

And, now...? Well, for a while there, even though seemingly completely unrelated, I went down the rabbit-hole of USB URBs, linux kernel drivers, interrupts, etc. In an entirely different realm of computing, different architecture, different concept-entirely of layers upon layers of what appears to contain many loose-ends in hardware-abstraction, nevermind being of a different /era/, entirely.

The goal, there, to get a fast-enough TI-graphlink connection that I wouldn't be massively set back each time I forgot to add "ret" to the end of my assembly endeavors, or when I start messing with hardware, which, in doing, inherently wipes the memory, including the assembler used to write the programs to test the hardware, as well as wiping those programs themselves.

So, I guess the idea was regular full backups and restores, which, with my current hack to the tilp2 libticonnect library to enable the "blacklink" cable to function over USB-Serial dongle, would probably take about a half-hour. 

Thus, looking into ways to speed that up... which led me down many paths.

For one, learning that the de-facto code/description of the state machine used in graphlink is apparently somewhat behind-the-times as far as how it's actually implemented in my TI-86 and TI-83+... Those both seem to essentially respond so quickly that two intermediate states are essentially skipped, which ironically /slows/ things a bit because the software in the connection library expects those states, and, not seeing them, has to rely on arbitrary delays to resynchronize. That's a limitation that's made worse by the use of a USB to serial converter, but, really, should affect real serial ports, as well, except maybe on extremely fast machines with very little overhead (OS task switching, driver abstractions, etc.) So, I've managed a slight modification which can at least remove that arbitrary delay for ~half the data receptions; when receiving the same bit value repeatedly. But it doesn't remove the delay when receiving two differently-valued bits back-to-back. Also, in light of how these calculators /send/ data, seemingly skipping two states, I also duplicated this functionality when sending data /to/ the calculator, which means complete removal of arbitrary delays during transmission. The calculator essentially tells the system when it's received the next bit /after/ that next bit has been started. It is, actually, well within the de-facto state-machine's ability to handle this situation... it just means that the receiver may be processing the /last/ bit /while/ the next bit is already being transmitted. The receiver and transmitter, then, are pretty much always never in the same state, usually the receiver is one state behind, but can take as long as it needs to to process it. Thus, the inter-bit delay is unnecessary, and the receiver itself is responsible for indicating when the next bit has been received.

OK, now, the same /would/ go for reception at the computer, except for one thing... apparently the calculators detect an /edge/ in switching from one particular state to the next during reception. When two consecutive bits are the same in value, the wires toggle in value, which is easy to detect whenever the computer can get around to it. But when two consecutive bits differ in value, the low wire pulses high /very/ briefly, and serial ports' hardware-handshaking lines just aren't fast enough to detect that same edge when the /calculator/ is transmitting, the pulse is too short. Thus, for half the bits transmitted, the /only/ option is to add a delay long-enough to be certain that pulse has come through...

So, those two changes /should/ speed up transfers somewhat significantly, regardless of the interface (USB-converter or real serial)... but are definitely less intuitive, looking at the code and state diagrams.

The /Other/ idea, which led me into USB drivers, and possible linux kernel hacks was to try to actually detect that edge... There is actually a function for that in the original serial-port tty drivers in the linux kernel, but it has essentially been dropped in USB-serial drivers, and after a bit of digging I think I see why. It seems it doesn't actually detect an /edge/, but detects a /change/... Designed to, essentially, pause a tty application until the handshake line becomes active. So, while it looks, at the API-level, as though it actually catches all the edges on those pins, what it actually does is just watches those pins until they change state... which in /most/ cases is done by polling, which again means that a brief pulse could easily occur between two polls and go completely unnoticed. Times like these, it's pretty much essential to have the source-code available, and it really makes me wonder how anything gets done right with the "blackbox" of limited API documentation.

Anyhow, from Z80 nostalgia to linux kernel hacking, and beyond.

Now we're in the realm of trying to backup my computer, which /should be/, and has long been, a relatively easy process... until just the other day, when my computer went friggin' haywire about halfway through the backup. Apparently after a year or more of reliability I'm discovering all sorts of design-flaws... apparently the Pi's "run" pin (which actually should be called reset) is picking up noise which it didn't do before. And the 9V DC converter I hacked from a car-USB-charger for the display appears to be outputting 5V again, at the weirdest times. And there may be some internal grounding issues caused by thin long wires and some other issues from the tiny wires powering the Pi through the micro-usb connector, and the slew of loops caused by the hub and hard drive, and so-forth... How did none of this come up before? I have no idea. Actually, some of this was known-questionable, and even unreliable... but then it actually ran surprisingly reliably for so long... what's changed?

Then, in another smiting to my plans--because, really, this whole endeavor, again, was about getting me back into projects in general--I'd finally realized I had access to hours of reliable electricity (which, of course, is pretty important in my field) which I could use from time to time, so I planned-out how I was going to use it... for months, really... and /the day/ I decided to go for it, I received a letter informing me it was no longer available, as of that very day. W T H.

So, now that my system which seemed surprisingly reliable for so long is now completely flaky to the point of not even being able to complete a backup, I need access to those hours of reliable electricity, even more than I did before, in order to fix this thing that was working fine until I tried to back it up. Heh. And that all-in-one handheld z80 development platform which would've cut the need for such unreliable systems in the first place... well, it apparently really depends on them, anyhow. Heh.

"It's not about the destination, it's about the journey" I guess.