This feels like a practical exam in information theory, and I love it.
"You've got a 32,000 byte file to transmit over a channel of your choice. They all suck in some way. You have a smartphone, a serial port, and a computer. The computer has no compiler, but you can use any of its native facilities. Solutions that require more bytes of input (eg scripts) than are in the file to be transferred are disqualified. There is no time limit, but the fastest solution wins. Go."
Given this is an old Mac, Im not sure I could have outdone the author. Although I was tempted by the notion that if you could replace visually similar chars like 3 and 8 with something very distinct (eg 8 with Z), then using a smartphone to capture the screen and OCR might be the fastest path of all. I think System 7 had AppleScript so perhaps that sed-like step is possible?
Before I ever entertained any sort of soft solution, I would have the drive out and plugged into a XYZ to USB interface. Simple manner of installing hfsprogs mounting the drive, yanking the files you want off, and you're done.
The proprietary connector might prove to be a problem, would likely have to bodge your way to victory there, but, mercifully, old stuff tends to work when bodged just fine.
I'm a software guy and my first reaction was the same: "Two words: eBay, Linux".
But then it turns out: taking the harddrive out of that Powerbook Duo 280c is kinda sorta a real mess for it requires taking the entire laptop apart (I just looked at an online teardown video of that old Mac laptop).
Now the advantage of eBay+Linux is that it works even if the screen is broken, if the laptop doesn't boot, etc. It works as long as the harddrive still boots.
There's no reason to open the laptop to access the disk from another computer.
With a dock, that laptop gains an external SCSI port.
And with an external SCSI port, it can boot up in a mode wherein the whole laptop behaves like a standalone SCSI disk -- ready to use with whatever other computer with SCSI from the past 40-ish years that one can muster up.
OCR from smartphone camera could easily make mistakes that would be difficult to detect and correct.
What I would do is look for some kind of encoding that makes errors extremely unlikely. If I had to dump the entire laptop's drive, I'd rather leave the laptop running for a week once than use a faster method that introduces errors.
I don't know much about error correction, so let's take naive approach. 320MB (drive size) in a week is 530 bytes per second. I don't know what's the screen refresh rate (and reaction time) but it's sensible to assume that if we display any image at 4Hz and record it with a smartphone, we won't miss frames or have any other funny artifacts. So it's like 135 bytes per frame, which is 1080 bits. If we divide the 8.4 inch 640x480 screen into squares 16 by 16 pixels, then we have 1000 squares 0.5 by 0.5cm. If each square is either black or white for 0.25 seconds, then camera artifacts shouldn't affect the transferred data too much, and the bandwidth is almost exactly what we need.
with a hex editor, I wonder how many bytes it would take to input a binary program that output the data to the screen as a series of black and white images, like a QR code but not. So you wouldn't be trying to OCR characters which has the problems mentioned, but you'd have to get the program into it first.
"You've got a 32,000 byte file to transmit over a channel of your choice. They all suck in some way. You have a smartphone, a serial port, and a computer. The computer has no compiler, but you can use any of its native facilities. Solutions that require more bytes of input (eg scripts) than are in the file to be transferred are disqualified. There is no time limit, but the fastest solution wins. Go."
Given this is an old Mac, Im not sure I could have outdone the author. Although I was tempted by the notion that if you could replace visually similar chars like 3 and 8 with something very distinct (eg 8 with Z), then using a smartphone to capture the screen and OCR might be the fastest path of all. I think System 7 had AppleScript so perhaps that sed-like step is possible?