I bought the butane soldering iron. It works surprisingly well. But, don't handle it the same way you handle a wired one! I managed not to burn myself, surprisingly... but equally surprising was the reason I'm surprised I didn't burn myself... Apparently my soldering-iron-handling-skills is a bit of muscle-memory which expects a flange at the end of the handle for delicate positioning and uses the weight of the wire for balancing. Heh!

Anyhow... soldered up the big beefies to the Pi and display controller, and it did exactly the same thing. Complete freakout crash about half an hour after power-up.

Thankfully I bought a spare Pi Zero last year... It was intended as a spare that would be experimented-with for another (decades-long) project-idea in the meantime. Well, /that/ project's design-progress was on a roll for the first time on the night my best friend, my dependent, disappeared, 11 months ago, tonight at 10:30PM. God... I miss you, Buddy... I'm so sorry. I'm some 90 miles away, now, and still check the engine compartment nearly every time.

.

Thankfully, that spare Pi Zero never got purposed. And lo and behold, it was just a matter of soldering-up the GPIO header and a jumper for the DPI interface, a little bit of work to break out the activity LED, and of course the big beefy power cables.

Soldering went surprisingly well.

Pi booted, like nothing changed...

Ran my backup, and /finally/ completed it...

Did a bit of cleaning-up of files that I'd /long ago/ copied to the Pi's drive from /old old/ machines' in an attempt (long ago) to get them moved to the backup drive (can't reliably run two external hard drives simultaneously for long with my power limitations). Also, did something that'd been nagging at me during each backup for years prior... Back when I worked on #OMNI 4 - a Kaypro 2x Logic Analyzer I used /many/ methods to try to extract every sector of its floppy disk into individual files... 400k worth of data... but that resulted in literally tens of thousands (hundreds?) of 512byte files, many (most) corrupted by read-errors... a wrong bit here or there. It took dozens of copies to determine the likely-correct CRC of each and match that with a full valid copy of the sector's data. So, in all, thousands upon thousands of tiny files... 1GB worth, in fact, in terms of disk-usage. Almost 500MB worth of actual data. And a Tremendous drag on my backup utility to try to track... for a measly 400K of valid data. Hah! Heck, just browsing one of those folders of attempts takes nearly a minute to load the contents in the file browser!

So... I /could/, I suppose, delete all that... seeing as how I do actually now have it all compiled into a disk image (400KB!). But, I hate throwing all that hard work away. The utilities I designed and improved and improved for extracting what it could in various different ways and trying to sort through it... well, it was no small task, and could possibly be useful in other such cases. By no means is it "production-ready" but it looks at the disk as best it can at a level that borders on parsing MFM data in the raw, without necessitating a specialized floppy controller. Not an easy task and not at all within the normal usage of the floppy controllers it's designed to work with. So... it /could/ be a handy tool, one day, maybe... except, of course, that it's not at all ready for "the public." So all that 500MB of corrupt raw bits is perfect for testing that. One day, maybe. In the meantime, it's /really/ slowing things down that I try to do regularly (backups). So, ZIP to the rescue. Now it's only 250MB! And, more importantly, /one/ file. That may seem like a "duh", but you have no idea what I've been through these past years... well, maybe /now/ you've some idea, being that this project was supposed to be about hacking a TI-86, went into USB drivers and library hacking, went to fixing my main computer which wasn't even broken until I tried to back up my progress, and now... coming full-circle to......

....

Last night I got excited to finally load ZAC back onto the TI-86. I /Really/ want to test my theory that one of the presently unknown/unused pins on the CPU might be an additional address bit. And, regardless, I have a FLASH chip to piggy-back on the ROM and a quad-two-input-NAND which I've already worked out the logic to decode the addresses appropriately for either the case of an additional address bit OR the case where there's not, and I'll shove 128K of the FLASH into the unpopulated RAM space. A pretty simple test, really, a couple hours to figure out the necessary assembly code to test it, I think. (Though, my "couple hours" now apparently turn into /weeks/. "Just an hour to run a full system backup" two weeks and a brain transplant later.). 

And I was /so/ excited to finally be on my way to trying it that I didn't even care that my link hack is still exceptionally slow, so uploading ZAC would take quite some time, and then I'd face the issue of how to open the case (to watch that pin), without wiping the memory in the process, or, big deal, just reload it (slowly) after opening the case and figuring out how to power it without the battery compartment...

So, I got out my usb to serial converter and link cable that I'd been working with for weeks... and the linking library which I'd been thoroughly testing for weeks without a hitch...

And...

It no longer links. Rather, it gets about 90% through the process of reading the calc's contents then croaks with errors I've never seen.

So, obviously, the bit-level linking I'd worked on still works... both directions. And... I have no friggin' clue where this new ordeal just appeared out of the blue from.

.

But, in the process of trying to diagnose it, I did try something I hadn't during all that other testing... watching dmesg. And there are a few instances where the pl2303 driver spits out an error message stating "unable to set control lines" or similar... which is weird, no? Why wouldn't that have been resulting in ioctl() returning non-zero and then should've been caught by my code... long ago! But, it might help to explain some other oddities, which led me to write-verify in the first place... but, again, it doesn't make sense that it only happens once or twice per transfer, which contains literally hundreds of control-line-writes. Very strange. Stranger, those don't seem to occur when the transfer fails. And, stranger still, the transfer failures don't seem to occur /during/ bit-level data transfers at all.

Really, it should have simply been a matter of plugging in a few cables and transferring ZAC.

....

OK! O KAY!

So, the last numerous revisions added quite a few printfs for logging purposes... and, since I was logging, I redirected stdout to a file. And, so, when I ran it last night, I didn't need the log, so didn't redirect stdout, which sent a ton of info to the terminal window, whose input buffer filled, causing the transfer to pause while the terminal printed out a few lines clearing buffer space... but during said pause, it took too long for the current operation in the transfer, so it timed-out.

I think I can buy that.

.

However, there's ziltch reproduction of the ioctl failing this time.

.

On that note, I guess we've got functional transfers and I can get on with coding up that address-testing. Of course, now the steam for learning how to do that is dissipated.

BTW, we're allegedly achieving 0.1KB/s, ONE HUNDRED BYTES per second!

(Wonder how much that's slowed by printfs to logfiles? Though, the first time I uploaded Zac--before stupidly wiping it and everything else by forgetting to add 'ret' to the end of my program--I don't recall the spedometer ever changing from 0.0KB/s)