My first thought was to use the serial port, but perhaps that was unavailable on the recipient hardware?
The second, much more entertaining approach, would've been to harken back to the very arcane days of ZX Spectrums and C64s with tape drives... since the old laptop had functional speakers, it may have been possible to write a bit of code that endcoded the binary data to an audio stream, played that over the speakers, recorded on the recipient machine, and decoded it back to binary form there.
Seems like I didn't get the idea across clearly. While audio files are binary data, they're encoded in a specific way, and use specific playback codecs to render that binary into data suitable for playback by soundcard chipsets.
Back, way back in the day (but not as far back as punch cards, but before diskettes), binary streams were persisted to tape. Not the backup tape used today, but regular audio cassettes. The data was converted into an audio stream, similar in nature to what you'd hear during a modem handshake. On the receiving end, the audio stream was decoded back into binary data, without any loss (well, given the robustness of error correction back then, sometimes you'd have to try again). The key point being, the audio was just a transport layer for binary data, which could have been anything -- images, code, text, audio files, etc.
Sounds like GP is suggesting digitally encoding/modulating the audio bitstream, like using the speaker as a modem. Which would be far less lossy than trying to record the analog signal.
It's funny that we used to all blame WinModem vendors for making WinModems instead of blaming open source for not being able to write DSP code. To be fair, it was a lot younger then.
> It's funny that we used to all blame WinModem vendors for making WinModems instead of blaming open source for not being able to write DSP code.
From what I recall, the main issue was not with writing DSP code; the main issue was (and usually still is) the lack of documentation on the hardware. Knowing how to write DSP code does not help if you don't know how to run it.
With a normal hardware modem, all you needed to know was how to talk with the UART (and these not only were publicly documented, but also were mostly backwards compatible with the original PC UART), and the Hayes command set variant used by the modem (which was also usually publicly documented, and also backwards compatible with ancient modems).
I don't think those old Macs used software modems. Honestly they probably couldn't, the CPU in these machines were not very fast and had some pretty horrendous bus contention issues. Servicing a realtime device is likely beyond their capabilities.
The second, much more entertaining approach, would've been to harken back to the very arcane days of ZX Spectrums and C64s with tape drives... since the old laptop had functional speakers, it may have been possible to write a bit of code that endcoded the binary data to an audio stream, played that over the speakers, recorded on the recipient machine, and decoded it back to binary form there.