Arn't there a serial (COM) port available on that laptop ? It was kind of ubiquitous at those days. This website [1] says there were two of them. Solving the probem with Zmodem would be trivial. The software (terminal) is already there, it seems.
You can indeed use xmodem or zmodem, and use a macbinary encoding to transfer any file you want in either direction. Does require you to have something that can receive over serial on the PowerBook. ClarisWorks could definitely do it, but office probably has exactly the same 'receive document' feature.
Alternatively, you can use the serial port to 'print' to, and just capture the serial output. It's essentially just unidirectional text transfer but that's enough for what the author intended to do.
On the other hand, faxing and OCR'ing is pretty cool.
It's highly unlikely any terminal software would be installed on an old Mac, even if it had a modem. (Although I don't know about Clarisworks.) It was counter to the whole mentality. There was a bootstrapping problem where you needed to get the software which allowed you to download the software, and even the common MacBinary/Stuffit/etc programs did not come with the system.
Because serial ports (and modems) were pretty much the default thing to use (besides LocalTalk and AppleTalk) the desktop software usually supported that out of the box, no terminal required. This is also why Fax support was built in, because even then, any other type of peer connectivity wasn't really big enough. And around that same time, ClarisWorks was also really common on Macs.
Now, we don't know for sure that the author also had ClarisWorks, but we don't really know much about what was available in general (except the games, the sound files and the fax). But in general serial file transfers, modem and serial based methods were pretty 'normal' to have.
Good finds everyone! Other than LocalTalk (which was 'normal'), I don't believe the old MacOS had any OOB support for serial transfers. Thus Clarisworks or ZTerm or etc was needed.
From the screenshot after the picture of the battery and a picture of a circuit diagram, we can see that the fax software is from Global Village ("GlobalFax PowerPort/Mercury Duo", probably v2.5)
GlobalFax had a terminal emulator app included, most likely ZTerm, in this case.
" the absolute garbage terminal emulator software we were including in the box.
And I set about pestering Rick to get somebody to Dave Alverson’s ZTerm terminal emulator app bundled with our modems because it was light and easy and supported the ZModem file transfer protocol which "
So the user could have likely run ZTerm to transfer the files.
Should we discover any more files to recover from the laptop, I may explore this avenue a bit further. If the ZTerm software is present, the trickiest part might be physically connecting the serial port to something else. Not an insurmountable problem.
As a poor Atari owner out in the nowere, I used metal paper-clips bent into shape and welded cables on them to connect my weird non-standard ports to other things. Worked pretty good :-)
SLIP, zmodem, and uuencode are tremendously useful when no other options are available.
I suspect you won't even have uudecode, in which case so long as you can transfer binary files, self-extracting ZIP files should work. Might take a while for larger transfers.
Getting a Real Operating System onto the old laptop would be a benefit. You might want to look into boot-from-floppy options including TomsRootBoot and Trinux. The former fits onto a single 1.5 MB floppy ("superformatted" to about 1.7 or 1.8 MB). The latter uses 2--3 disk images to include a number of more formidable tools.
Trinux still has a Sourceforge page, though I've not dug into it. You may need to hit up Internet Archive for working images:
I don't think that will work on non-x86 architectures. As far as I know, you can't boot linux on 68LC040 at all, perhaps if someone forked uCLinux and made it work with no FPU and no MMU you might get something going, because all the 68k linux variants expect a MMU that works, which on that specific CPU is too buggy. You can't run MkLinux kernels either since those are PPC OldWorld, which came after 68k.
There might be Powerbook Linux boot floppy, though NetBSD might be a better choice. The CPU appears to be a 68LC040: <https://support.apple.com/en-us/112137>
Looking at the reporting, it does seem like the 68LC040 emulation at least worked (just slightly buggy), which is much better than the not-booting Linux of the same era. I should probably not be surprised to see NetBSD run on yet another thing ;-)
I wonder what has been ported to more hardware at this point: NetBSD or bare metal Doom.
Some years back I seem to recall Debian making the claim to support more hardware (if not necessarily the same hardware) as NetBSD. I cannot verify this presently however....
ClarisWorks had a "communications" module which is effectively a serial terminal, and which supported sending and receiving files. I'm not sure if it internally supported MacBinary, but it'd at least be enough to get files off the system.
The ClarisWorks communication module could act as a TTY, like HyperTerminal. You could just dump text into it and copy from the buffer to SimpleText if you really wanted.
It did automatically detect MacBinary, I think there's even some example out there of someone doing exactly this. You don't need a terminal on the old Mac, but they did use a new Mac because it came with the macbinary tool preinstalled which makes it all very easy.
> Alternatively, you can use the serial port to 'print' to, and just capture the serial output.
I've done this to recover data from a number of old systems. It's a great way to get at old data.
I've also done this to get data out of proprietary databases. As long as there's a report that gets the data you want it becomes just a parsing problem.
Many moons ago I'd bootstrapped a Linux install on a circa-1990 laptop which afforded a floppy drive, serial, and parallel ports, but no innate networking (a 32-bit PCMCIA network card was later possible but required drivers and/or kernel support to be compiled).
I'd pieced together the install by splitting a tar.gz across multiple floppy transfers, then enabled SLIP and zmodem which permitted copying uu-encoded files for further support, then SLIP and PLIP. The latter was particularly useful as I could sustain multiple simultaneous network connections: both an SSH session and scp'ing across files for further support, rather than running a console under minicom. SLIP was bound at somewhere around 9600 AFAIR, fine for a terminal session, but cramping my style for file transfers. (It may have been faster, 38,400 and 56k are available modem rates.) PLIP IIRC was at or approaching Mb/s speeds, which was (comparatively) blazing.
Though the sheer audacity of copy-pasting uuencoded files through minicom had a certain coolness factor.
Author here. It's a good question. It probably does, but I admit I'm not familiar with Zmodem. I don't recall finding a terminal application installed on the laptop, but maybe I just wasn't looking hard enough.
Before they had built-in phone modems, the CPU communicates with a COM port for general I/O to the outside world.
COM port is just serial digital data transfer by RS-232 standard, unlike the parallel (printer) port, the COM port is very robust because the RS-232 standard requires the ability to short or improperly connect any of the pins to at least +/- 12VDC without doing any damage.
You connect two mainframes or personal computers' COM ports together using a "null modem" (crossover) cable having a common ground connection and with each's data transmit wire (pin 2) connected to the other's data receive wire (pin 3). You have to set the same baud rate, word length, parity, and number of stop bits on each device. Handshaking lines can often be considered "optional" so many of the cables only have these 3 wires. However using the comm app you may have to virtually enable a handshake line or two on each computer if the extra wires are not there and the devices are troublesome for some reason.
The terminal app or related program will usually be where you get to the communication settings, and once the terminal at each end of the communication cable is correct, then each person can type to the other in real time, perhaps simultaneously depending on "duplex" setting. Very much like an antique teletype machine, COM ports are also referred to as tty's.
With a GUI there should be a drop-down menu where you can set the receiving terminal to collect all following data from that point, into a file which you should be able to name yourself and store where you would like after the transfer finishes.
At the sending terminal you click the corresponding button to open the selection window so you can browse for the file you want to send out on the COM port.
To do it over the phone, the device at each end would then add an external modem plugged into the COM port. Then you can connect computers to the outside world using a phone cable. The modem is what detected the dial tone and dialed your target's number on the public phone network from your land-line location, as well as doing the audio modulation of your data so it would go well over the phone line. Modems started out pretty dumb and it was years before "smart" modems became common, but almost all of them responded to what is known as special AT commands. Somewhat specific set of AT's for different manufacturers and vintages. Receiving the ATD command followed by the target phone number, the modem would open the phone line, listen for a dial tone, then autodial the digits you had provided. If the other party responded then the intercommunication would begin.
But if you're just connecting two computer modems together in the same office without going over land lines there is no dial tone and no voltage being provided by the phone company either. The voltage is well covered with the battery arrangement shown, but a different AT command must be used on the sending modem so it will proceed to negotiate communication without the dialing process.
IOW all personal devices had com ports and that's what you used at first, not everybody was good with the cables and settings though so it never became very common knowledge. After built-in phone modems began to appear, devices retained COM ports in addition for a period of time before they started becoming more rare. Once there was no more COM port exposed to the user, yes you can go directly from modem-to-modem, but it's always another layer of complexity in addition to the underlying COM-to-COM foundation.
Remember terminals produce ASCII text through your designated COM port when typing but it's just binary data when sending files. You can send a Windows EXE file to a MAC for storage and it will be a faithful copy but naturally it's not made to actually execute on the MAC.
Yes, it had those ports. Just like Kevin McCallister could've called the police in Home Alone, I think the author preferred this to become an extraordinary story more than the simplest possible solve.
I just had to update the firmware my HF radio using xmodem protocol. Tons of modern ham radio gear still using serial data... even the modern ones that connect to your PC via USB, still just a USB->serial device built in.
EDIT: actually not ZModem, but it supports X/YModem -- source code, despite the comment at its beginning, finally says "Sorry, zModem not available yet"
You are right, but it's possible to connect RS-422 to RS-232 using just proper wiring [1]. Basically, same three wires and one loop wire for RX+ to ground. It's not reliable and not recommended, but works and would solve the problem. :-)
The Mac RS-422 ports are backwards compatible with RS-232, dumb cables work fine. No Mac users were buying special RS-422 modems back in the day, we all used standard PC RS-232 modems and they worked fine with just a dumb cable. Even Apple's own serial printers were just RS-232.
That's the first thing that came to my mind. I remember connecting two laptops using LPT or COM cable and transferring files using norton commander (if I remember correctly) 30 years ago.
1. https://everymac.com/systems/apple/powerbook_duo/specs/mac_p...