I was actually expecting the author to take photos of the old laptop's screen and OCR those. This was far more entertaining.
I do wonder though... perhaps it would have been faster to have the larger fonts and let the transfer take 24 minutes. It probably took longer than 24 minutes to write the updated OCR software.
Author here. Seeing how difficult it was to get a reliable OCR transcription with commercial software from a pristine, computer-generated representation of the text, I suspect trying to OCR photos would be even less reliable :)
I simplified some things for brevity in the write-up. I did indeed try a bunch of fonts/font sizes (trying a single page at a time and manually inspecting the results) without much improvement.
The transcription errors I was getting were not consistent. Like, D would be O or 0 or D, with no apparent rhyme or reason to it. And the turnaround time on each fax attempt was long enough that I focused on doing the image recognition myself instead.
This was a phenomenal effort and such a joy to read. Based on how much work this was, these were probably some very important sound files that mean a lot to someone in your family, so thanks for your hard work getting them off the laptop.
My goofy idea was using the font OCR-A but you'd be very lucky if that Mac came with that.
Well, mounting the disk itself. If it was simple to get an image of the disk, the author could have used the same method to just get the files they wanted.
There is nothing pristine about images transmitted over Fax. It's such a grotty old technology with loads of aliasing issues. A modern cell phone picture of a word screen full of hex would almost certainly be easier to OCR.
Did you try seeing how well ChatGPT was at OCRing the images? Though since it is HEX characters it might not do so good. I've found it to be very reliable at OCRin e.g. photos of receipts.
Couldn't you just do a bunch of different faxes, perhaps in different fonts or different font sizes, which would lead to different randomly distributed errors? Then you can do OCR for all of them, and just take the median of the result, and get exponentially less error.
A laptop of this age should have a serial port. It's possible even with something like Win95 to run a null modem and tcp/IP over that and SMB to copy files to a semi modern OS.
Well, the source site seems to be hosted on an 30-year-old laptop, and therefore unavailable (even trough archive.org), but here we go:
-If you ever encounter a situation where "well, this volume might contain valuable data" is a thing, try to make a forensically-sound copy first;
-Depending on the exact source media, this might be a very specific process. Don't skip on it, though.
But, once you have an accurate copy of the source media, feel free to run any non-destructive experiments that you'd like. After, of course, publishing the source media for fellow enthousiasts...
> the source site seems to be hosted on an 30-year-old laptop
You're not too far off :)
It's actually hosted on super cheap shared VPS with only 768MB of RAM and a single CPU core. This is the first time it's seen any real heavy traffic, and all considered I think it did pretty well with such limited resources.
I did a little postmortem investigation and, surprisingly, it wasn't CPU-bound. A low memory condition killed the database service a couple times. It looks like PHP-FPM was set to scale too aggressively. For the future I've reduced the number of workers it can spawn. Server administration is not my specialty, so this was a fun learning experience!
If you have OCR in the loop anyway, you could have just taken a picture of the file as displayed on the original laptop, no need to do the fax transfer.
Also, replace the ambiguous characters like D/0 or 3/8 to something a bit more recognizable like D becomes d and 8 becomes X and then do a find-replace after the OCR process. Was there really a need to write the OCR software from scratch?
Right. Fax is a terrible, crappy protocol that generates pretty bad images on the receiving side, even when you have clean phone lines. I wouldn't be surprised if a modern camera-phone photo of the screen displaying the text would yield a better image.
Is a fax implicitly an analog transmission? Or is there a digital data stream somewhere beneath the layer sending the photo that could be used like a modem?
Very, very old faxes used to be purely analog. Since dial-up was invented, however, faxes are fully digital. If you've ever used a fax machine, you'll notice the classic dial-up handshake noises. Faxes are modems and vice-versa: any PC with a modem could send and receive faxes. It was a commonly advertised feature back in the day.
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 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.
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.
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.
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.
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.
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.
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....
> 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.
EDIT: actually not ZModem, but it supports X/YModem -- source code, despite the comment at its beginning, finally says "Sorry, zModem not available yet"
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.
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.
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.
Very creative and interesting ie 'use whatever tools/knowledge you have' but:
> The internal hard drive uses SCSI with an unusual connector.
This is literally never an issue as old connectors are easily obtainable (in particular 'in this day and age').
> Adapting it didn't seem straightforward, and we weren't confident the old file system (HFS) would be easy to read from a modern system.
Simple search pulled this up. Honestly that reason didn't make any sense to me at all. The other way might be interesting and fun but I don't think this is a reason not to attempt mounting the old file system.
Linux will mount HFS drivers and files like nothing...
This setup it's overcomplicated and hackey, but dumb in the end. You can mount old SCSI drivers with modern adaptors just fine, and Linux/BSD will either mount or extract HFS images with unar (I think) or hfsutils/hfstools.
Or just spawn ymodem/zmodem compatible software (as he used a Fax setup for modem) and the problem would be solved in minutes.
I sympathize with the notion to fix things in software instead of buying hardware (an SCSI adapter): You have to spend money, wait for it to arrive (or even leave the house to get it yourself!) and it's one more future plastic waste.
If fiddling around and getting creative is something one enjoys (and has the time to do so), doing things like OP did is a nice alternative :)
Hell, I wrote a FUSE implementation of HFS a while back. HFS (and to a lesser extent HFS+) is quite well documented. Current versions of MacOS can still do HFS+ (but not HFS) natively.
Fun for the win! I suspect most of the other suggestions, even if possible, wouldn't have generated this level of interest. Well done on your Rube Goldberg method!
In my younger years, I had to pull a dBase 2 database off a CP/M desktop into an MS-DOS portable.
I ended up configuring a serial cable, and running PROCOMM on the PC, set 9600/n/8/1 on both ports, then printed from dBase 2 and set PROCOMM to record the session to a file.
It would lose characters if I let it run too long without a pause to write to a floppy, so I would ctrl-s/q on the CP/M side.
I guess nobody else had ever figured out how to do this.
I think in this particular (macbook) case the problem was lack of proper software. Yet, I recall if there was modem installed, a terminal software had to be present as well.
The CP/M side didn't have any terminal software. Both sides had methods to set 9600/n/8/1 on the printer device.
On the PC side, without PROCOMM, it would be possible to "COPY COM1: FOO.TXT" but I don't know how 9600/n/8/1 could be set in advance (IIRC setting it as a printer to force the baud rate altered the device so it could not be read).
Generally speaking, all of the pre-PC microcomputers implemented serial ports, which is the first choice in pulling data off of them (including binary data with XMODEM and its variants).
Yes, you can transfer files via COM port in MS-DOS using COPY command, but errors may occur. :) Also you have to switch port to 8-bit binary mode and turn off flow control. Don't remember how to do that exactly. Default was 7 bit XON/XOFF, AFAIR.
Is it so hard to write your own program which would just read a file stream and send it to a port? Maybe also split it into smaller frames with CRC hashes attached.
Depends: I wonder what programming tools/languages were present on the old PowerBook. Otherwise, getting any handwritten program or its associated tools/runtimes (if necessary) onto the laptop might be just as much of a challenge as getting audio data off.
> I try a bunch of different OCR programs, but can't find any that can transcribe the document with 100% accuracy. They often confuse certain letters or numbers (like 0 and C, 9 and 4, 0 and D). Sometimes they omit characters, sometimes they introduce new ones. I try different font sizes and different fonts, but it doesn't matter.
I decided to OCR a hex dump from an old computer magazine a while back and fixed this problem by writing a tool to help verify the OCR result. Basically you input the OCR'd result and segment the numbers. It'll display the original segmented characters ordered by their class, and the human eye will very quickly find any chars that do not belong, e.g. 3s sorted under "8" etc.
I wrote two blog posts about this, and the tools are also linked from the blog posts. Note: the tools are just slightly more user-friendly than sendmail.
That said, I don't know if these old Apple laptops came with anything resembling a programming environment (or at least that ancient version of Microsoft Word?), but even if not... There must be a better way (even without hardware hacking)!
>I think a better solution would have been to use the serial port rather than the modem port to send a fax.
From what I could Google, that laptop doesn't have a traditional RS-232 serial port but a DIN-8 RS-422 serial port. Still, it's serial, it's standard and very well documented, easy to acquire and easy to hook up.
I'd definitely would have used that instead to transfer data, especially since I could find USB to RS-422 port converters online easy and cheap[1]. I'm not sure why the author didn't try this, or maybe he tried but had no app to serialize file transfers?
Feels like a missing lead the article doesn't touch on.
I think if there was another "bridge" mac it would've been easier (setup LocalTalk over the serial port, could theoretically send the required TCP/IP libraries, to make it easier to go straight to a modern computer). I'd guess that the comment about "but no networking software installed." includes not having something like ZTerm installed already for direct serial communication, and also not having MacTCP or OpenTransport installed on the old mac (not to mention the missing hardware to set that up)
I have a few old macs that I play with from time to time, and it's certainly possible to network them to modern computers, just becoming increasingly hard with the number of old software and hardware items you have to keep around to do it.
>I think if there was another "bridge" mac it would've been easier (setup LocalTalk over the serial port
But serial communication doesn't require another Mac to receive the data since it's just raw HEX/ASCII bytes over the standard serial protocol. You can pick up the data with an Arduino.
Nor does serial mandate any handshake or a master-slave sync to work. You're free to shoot those bytes on the empty wire for all it cares. If someone picks them up good, if not, just as good.
I wonder if you could convince the mac there was was a postscript printer on the other end, then retrieve the text from the ps commands that were sent.
/? farallon Mac serial port Ethernet
https://www.google.com/search?q=farallon+mac+serial+port+eth... : $50 and no FreePPP or Zmodem or AppleScript serial port to a [soldered] cable to an Arduino/RP2040W/ESP32 (which is probably faster than the old Mac).
IDK about MacOS, but on Windows 9x/XP, sending bytes via serial was incredibly trivial in C#, Visual C++ or even ols school Visual Basic.[1]
Even if you didn't have one of the dozens of already written serial terminal apps, you could write your own pretty easily in one of those languages to push bytes out the serial port, with just a few standard API calls.
I doubt MacOS didn't have something similar. Unless of course, MacOS back then was somehow shittier than Windows, which I doubt.
No need for any programming language in Windows 9X, just open a DOS prompt and use 'copy file.txt COM1: /B'. We used that trick back in the DOS days to print raw ASCII files on parallel (LPT1:) or serial (COM1:) devices. I'm willing to bet it still works on Win11.
It might not. A lab I was at in uni still had Windows XP PCs because according to them, that's the last Windows OS that allowed direct serial/paralel port access needed to control the external robotics/CNCs via those old APIs the SW used, since subsequent versions of Windows abstracted away those direct HW API calls that DOS used in the name of security and stability.
What OS-level APIs would something communicating over serial be using? Sure, Windows abstracts the hardware, but that's been true since well before Windows XP, and modern versions of Windows still expose virtual COM ports for serial adapters connected through USB or PCIE, just as XP did.
In fact, even DOS abstracts away serial communications: your hardware would be set to a specific I/O port and IRQ, but DOS exposes those as I/O devices, so you would just read and write to COM1, COM2, etc.
My guess is that there's some other issue running that old Windows program on modern versions of Windows -- maybe some components are 16-bit, and since current 64-bit Windows doesn't include the VDM, they can't run. Or maybe it's an issue with current versions of certain DLLs.
Didn’t know how to program at the time I was using classic macos but my current understanding (having done some retro programming for fun) is that unless you specifically installed a programming environment there’s no real ability to script or even run commands.
Windows 9x/XP did not come with C#, Visual C++ or Visual Basic. Likewise, classic macOS did not come with any programming or scripting languages. In this respect, they were equally “shitty”, and your solution would have been unavailable for both.
AFAIK MacOS was just another UNIX, and in UXIX writing to a serial port was just writing to a file. Are you telling me MacOS had no shell scripting capabilities to write to a file via the command line? Even MS-DOS could do that.
MS/PC-DOS shipped with debug.com since pretty much the first versions. It is a perfectly usable assembler where you can type a short loop that receives characters from the serial port and outputs them to a file. Similar things have been done many times to salvage hosed systems where a little more than copy file COM1: was required.
With the Internet today, you probably don't even need to remember the instruction names, you can probably find a printout of a program that does this.
> I think a better solution would have been to use the serial port rather than the modem port to send a fax. Serial-to-USB adapters are easy to find.
Two potential problems. I have tried serial transfers on a similar vintage of Mac, and it seems to require a USB/Serial adapter that supports proper RS-232 logic levels. Many (perhaps most) don't. I ended up using the built-in serial port on an older PC. The second issue is that you require software on the Mac side to perform the data transfer. Something like the rather common ClarisWorks would do the job, but the presence of Word and PowerPoint suggests they didn't have ClarisWorks. (Even if it did have ClarisWorks, they would need to know that ClarisWorks includes built-in communications software. It isn't exactly a common component in office suites.)
I suppose they could have explored AppleTalk, print drivers, or (depending on the version of MacOS) TCP/IP. Each option is limited though. AppleTalk requires another suitably equipped Mac or a PC with rare hardware and ancient software. (I think Sun systems would work too, but then we are really getting into the weeds.) I'm pretty sure the Mac print drivers rasterize the text, so you would still have to undo that. (Though it would probably transfer the data faster.) I think TCP/IP only shipped with MacOS 7.5 and later, would have required setup on another PC, and would still be convoluted (e.g. downloading FTP software to the Mac, so it could upload to a PC).
That could become an automated improvement as well... although it was probably published in some paper 40 years ago and I just don't know the name of it.
Basically a second-pass where you look for outliers in each character-group, reassign them to another group, and keep the change if it improves similarity-scores the character groups involved. Then iterate a bit until nothing seems to be improving.
For example, one might find "the 3 that is least-like all the other 3s", temporarily reassign it to "8", and then keep that change if it means an improvement in the the scores for "how closely all sub-pictures of 3s resemble each other" and "how closely all sub-pictures 8s resemble each other".
That might backfire if a document has different typefaces in it though, where it makes the mistake of putting all "3"s from different typefaces together, ruining the group-similarity scores.
For typefaces you check for the distribution of similarities in each group. If it has large clusters then group by 3, 3', etc then run your outlier check on each of those groups
Still would risk some weirdness, but would help a bit I'd hope.
I wonder if it would be worth running some kind of language analysis or spelling/Grammer check to verify the scan too. At least for text, you'd need another solution for number tables.
This reminds me of an OCR application I used for converting PGS subs to SRT. It would show you words/letters grouped together and you had to approve / correct its translation.
> I try a bunch of different OCR programs, but can't find any that can transcribe the document with 100% accuracy. They often confuse certain letters or numbers (like 0 and C, 9 and 4, 0 and D). Sometimes they omit characters, sometimes they introduce new ones. I try different font sizes and different fonts, but it doesn't matter.
I feel like this could be trivially solved by plugging an LLM to the OCR output with the sole task to correct spelling errors like that. That's pretty much one of the tasks LLMs should excell the most at.
Denoising algorithms are always lossy. An LLM (or, y'know, Markov chain) could do this job by exploiting statistical regularities in the English language, but a hex dump isn't quite the English language, so it'd be completely useless. Even if this text were English, though, the LLM would make opinionated edits (e.g. twiddling the punctuation): you'd be unlikely to get a faithful reproduction out the other end.
It's hexadecimal. There is no spelling, so there's no way for an LLM to know if something is supposed to be a `D` or a `0` any more than traditional OCR software can.
Good idea. Maybe making the replacements short, space-separated words would have helped even more, by countering any "helpful corrections" the OCR might have been making based on English words (e.g., it would not surprise me if some OCR software would "correct" "B0B" to "BOB").
He says that there are internal speakers, but no jack. If it were me, I would have cracked the case open and tapped into the audio going to the speakers directly and recorded it from another device, but then again this makes a much more satisfying hack.
Same. Solder one of the $1 audio cables I’ve got lying around to the speaker leads and run it into your choice of audio recorders, play the files and you’re done in 5 minutes with basically no losses.
If it had "fax software" it almost certainly had terminal emulator software whereby one could use something like ZMODEM and not corrupting the files in the process.
This was painful to read, like using a butter knife as a precision screwdriver.
> Oops. The FCC says I need a cover page. Let's try to appease them.
Yet another reason I hate when things I own try to enforce laws against me: there will be cases, like the author's, in which the law doesn't apply but the thing doesn't know it.
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.
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.
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.
> 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).
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.
A few years ago, I spent a fair share of time trying to copy files from and to a Macintosh Plus. I decided to use a 100 MB ZIP drive (actually two of them, SCSI for the Mac Plus and USB for a modern computer) and later a serial port connection with terminal software [1].
Now there's a much better and cheaper option: BlueSCSI [2]. It's a SCSI HDD emulator that allows to mount .img files stored on a SD card as HDD disks. It also supports CD and network card emulation.
Once the files are copied on a such a virtual drive, they can be extracted on a modern machine using via some kind of HFS explorer or an emulator.
They sorta did in the Apple world. Maybe not quite a standard, but quite common. Apple shipped several Macs with (optionally) built-in Zip drives in the late 1990s.
They were proprietary and made by only one company. So there was a bit of a battle between Zip, SyQuest and LS120 ("SuperDisk")
What I don't get is why Magneto-Optical didn't take off. 3.5" disks that were essentially MiniDisc but not proprietary (there were drives and disks from several manufacturers), faster than Zip, and eventually got upgraded to over 1 GB capacity disks. They were huge in Japan where they became a de-facto standard, but mostly unheard of in the rest of the world.
270 comments
[ 14.3 ms ] story [ 5035 ms ] threadI do wonder though... perhaps it would have been faster to have the larger fonts and let the transfer take 24 minutes. It probably took longer than 24 minutes to write the updated OCR software.
But, where's the fun in that?
I simplified some things for brevity in the write-up. I did indeed try a bunch of fonts/font sizes (trying a single page at a time and manually inspecting the results) without much improvement.
e.g.
The transcription errors I was getting were not consistent. Like, D would be O or 0 or D, with no apparent rhyme or reason to it. And the turnaround time on each fax attempt was long enough that I focused on doing the image recognition myself instead.
My goofy idea was using the font OCR-A but you'd be very lucky if that Mac came with that.
https://en.wikipedia.org/wiki/OCR-A
For the record, you’d have had no problem mounting an image of the HFS disk on any modern Linux or macOS system.
[0] https://social.immibis.com/notice/AeWSRvyKlhBB2hANoe
-If you ever encounter a situation where "well, this volume might contain valuable data" is a thing, try to make a forensically-sound copy first;
-Depending on the exact source media, this might be a very specific process. Don't skip on it, though.
But, once you have an accurate copy of the source media, feel free to run any non-destructive experiments that you'd like. After, of course, publishing the source media for fellow enthousiasts...
You're not too far off :)
It's actually hosted on super cheap shared VPS with only 768MB of RAM and a single CPU core. This is the first time it's seen any real heavy traffic, and all considered I think it did pretty well with such limited resources.
I did a little postmortem investigation and, surprisingly, it wasn't CPU-bound. A low memory condition killed the database service a couple times. It looks like PHP-FPM was set to scale too aggressively. For the future I've reduced the number of workers it can spawn. Server administration is not my specialty, so this was a fun learning experience!
Good job.
I likely would have given up several times and just played the audio on the laptop and tried capturing it with another device (my phone) over the air.
1. https://everymac.com/systems/apple/powerbook_duo/specs/mac_p...
You need just three wires for serial line to work. I would strip the wires and plug them in without any connector. :)
1. https://stratusengineering.com/rs232-rs422485-conversion-cab...
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.
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.
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.
GlobalFax had a terminal emulator app included, most likely ZTerm, in this case.
from https://tagn.wordpress.com/2023/09/10/tech-support-at-the-vi...:
" 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.
The user should have consulted HN before diving into the problem. :)
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.
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:
<https://sourceforge.net/projects/trinux/>
A 2001 white-paper: <https://www.sans.org/white-papers/327/>
Tom's Root Boot ... seems to now be offline, but has a Wikipedia article:
<https://en.wikipedia.org/wiki/Tomsrtbt>
And numerous Wayback captures. The one from 2008 should be functional and suit your hardware:
<https://web.archive.org/web/20080724163531/www.toms.net/rb>
November 2023 appears to be the most recent active capture:
<https://web.archive.org/web/20231123003805/http://www.toms.n...>
And a ~2001 article describing TRB's capabilities: <https://www.linux.com/news/little-linux-distribution-could-t...>
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>
A NetBSD install guide which seems to have worked for someone in 2012: <https://web.archive.org/web/20120602135739/http://www.macuni...>
(Site is now SEO scambait.)
NetBSD docs: <https://wiki.netbsd.org/ports/macppc/>
I wonder what has been ported to more hardware at this point: NetBSD or bare metal Doom.
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.
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.
(We used back in the day to move files between PDP11s and PCs - it was the original “anything to anything” file transfer program)
yes and also X/Ymodem, see source code: https://elixir.bootlin.com/u-boot/latest/source/common/xyzMo...
extremely useful feature (I used xmodem in the past, if I remember well)
> The internal hard drive uses SCSI with an unusual connector.
This is literally never an issue as old connectors are easily obtainable (in particular 'in this day and age').
> Adapting it didn't seem straightforward, and we weren't confident the old file system (HFS) would be easy to read from a modern system.
Simple search pulled this up. Honestly that reason didn't make any sense to me at all. The other way might be interesting and fun but I don't think this is a reason not to attempt mounting the old file system.
https://www.matthewhughes.co.uk/how-to-mount-hfs-classic-dri...
This setup it's overcomplicated and hackey, but dumb in the end. You can mount old SCSI drivers with modern adaptors just fine, and Linux/BSD will either mount or extract HFS images with unar (I think) or hfsutils/hfstools.
Or just spawn ymodem/zmodem compatible software (as he used a Fax setup for modem) and the problem would be solved in minutes.
If fiddling around and getting creative is something one enjoys (and has the time to do so), doing things like OP did is a nice alternative :)
(They can also be resold on eBay after they're done being used.)
A quick search yielded this result, which does confirm it's absolutely possible to adapt the drive: https://vintagemacmuseum.com/reading-powerbook-2-5-scsi-hard...
(My way might be more fun. Ha.)
I ended up configuring a serial cable, and running PROCOMM on the PC, set 9600/n/8/1 on both ports, then printed from dBase 2 and set PROCOMM to record the session to a file.
It would lose characters if I let it run too long without a pause to write to a floppy, so I would ctrl-s/q on the CP/M side.
I guess nobody else had ever figured out how to do this.
On the PC side, without PROCOMM, it would be possible to "COPY COM1: FOO.TXT" but I don't know how 9600/n/8/1 could be set in advance (IIRC setting it as a printer to force the baud rate altered the device so it could not be read).
Generally speaking, all of the pre-PC microcomputers implemented serial ports, which is the first choice in pulling data off of them (including binary data with XMODEM and its variants).
None of the tools that you know today would work in something that small.
There was a C compiler for a dialect of C that met these constraints; I didn't have it, and I didn't know C at the time.
Since the mac had a built-in modem, you could have used that software to transfer the file via xmodem or ymodem protocol.
I guess this isn't common knowledge any more.
I decided to OCR a hex dump from an old computer magazine a while back and fixed this problem by writing a tool to help verify the OCR result. Basically you input the OCR'd result and segment the numbers. It'll display the original segmented characters ordered by their class, and the human eye will very quickly find any chars that do not belong, e.g. 3s sorted under "8" etc.
https://blog.qiqitori.com/2023/03/ocring-hex-dumps-or-other-...
https://blog.qiqitori.com/2023/03/ai-day-in-retroland-prolog...
I wrote two blog posts about this, and the tools are also linked from the blog posts. Note: the tools are just slightly more user-friendly than sendmail.
That said, I don't know if these old Apple laptops came with anything resembling a programming environment (or at least that ancient version of Microsoft Word?), but even if not... There must be a better way (even without hardware hacking)!
I think a better solution would have been to use the serial port rather than the modem port to send a fax. Serial-to-USB adapters are easy to find.
From what I could Google, that laptop doesn't have a traditional RS-232 serial port but a DIN-8 RS-422 serial port. Still, it's serial, it's standard and very well documented, easy to acquire and easy to hook up.
I'd definitely would have used that instead to transfer data, especially since I could find USB to RS-422 port converters online easy and cheap[1]. I'm not sure why the author didn't try this, or maybe he tried but had no app to serialize file transfers?
Feels like a missing lead the article doesn't touch on.
[1] https://www.amazon.com/Serial-Converter-Adapter-Supports-Win...
https://en.wikipedia.org/wiki/ZTerm https://lowendmac.com/1998/tcpip-over-localtalk/
I have a few old macs that I play with from time to time, and it's certainly possible to network them to modern computers, just becoming increasingly hard with the number of old software and hardware items you have to keep around to do it.
But serial communication doesn't require another Mac to receive the data since it's just raw HEX/ASCII bytes over the standard serial protocol. You can pick up the data with an Arduino.
Nor does serial mandate any handshake or a master-slave sync to work. You're free to shoot those bytes on the empty wire for all it cares. If someone picks them up good, if not, just as good.
Is there even an environment you can program in? Can Applescript on classic macos do serial stuff in any form?
/? farallon Mac serial port Ethernet https://www.google.com/search?q=farallon+mac+serial+port+eth... : $50 and no FreePPP or Zmodem or AppleScript serial port to a [soldered] cable to an Arduino/RP2040W/ESP32 (which is probably faster than the old Mac).
https://unix.stackexchange.com/a/548343/44804 mentions minicom and gnu screen, and the need to implement e.g. file-level checksums because over serial like ROM flashing
Even if you didn't have one of the dozens of already written serial terminal apps, you could write your own pretty easily in one of those languages to push bytes out the serial port, with just a few standard API calls.
I doubt MacOS didn't have something similar. Unless of course, MacOS back then was somehow shittier than Windows, which I doubt.
[1] https://learn.microsoft.com/en-us/dotnet/api/microsoft.visua...
It might not. A lab I was at in uni still had Windows XP PCs because according to them, that's the last Windows OS that allowed direct serial/paralel port access needed to control the external robotics/CNCs via those old APIs the SW used, since subsequent versions of Windows abstracted away those direct HW API calls that DOS used in the name of security and stability.
In fact, even DOS abstracts away serial communications: your hardware would be set to a specific I/O port and IRQ, but DOS exposes those as I/O devices, so you would just read and write to COM1, COM2, etc.
My guess is that there's some other issue running that old Windows program on modern versions of Windows -- maybe some components are 16-bit, and since current 64-bit Windows doesn't include the VDM, they can't run. Or maybe it's an issue with current versions of certain DLLs.
ref: https://en.wikipedia.org/wiki/.NET_Framework_version_history...
- https://en.wikipedia.org/wiki/Macintosh_Programmer%27s_Works...
- http://www.think-pascal.org/#SetUp
- https://en.wikipedia.org/wiki/THINK_C
Not the greatest tools out of the box, but still better than nothing.
With the Internet today, you probably don't even need to remember the instruction names, you can probably find a printout of a program that does this.
The RS-422 support is just there to support LocalTalk networking.
With the file sizes involved, one could take a picture of the screen showing the hex dump with a smartphone, and then OCR that.
No need to even bother with external hardware.
Photo resolution is higher than a fax resolution, and one can increase the font size / decrease screen resolution.
Plus, they can still apply the same approach they used for fax.
Two potential problems. I have tried serial transfers on a similar vintage of Mac, and it seems to require a USB/Serial adapter that supports proper RS-232 logic levels. Many (perhaps most) don't. I ended up using the built-in serial port on an older PC. The second issue is that you require software on the Mac side to perform the data transfer. Something like the rather common ClarisWorks would do the job, but the presence of Word and PowerPoint suggests they didn't have ClarisWorks. (Even if it did have ClarisWorks, they would need to know that ClarisWorks includes built-in communications software. It isn't exactly a common component in office suites.)
I suppose they could have explored AppleTalk, print drivers, or (depending on the version of MacOS) TCP/IP. Each option is limited though. AppleTalk requires another suitably equipped Mac or a PC with rare hardware and ancient software. (I think Sun systems would work too, but then we are really getting into the weeds.) I'm pretty sure the Mac print drivers rasterize the text, so you would still have to undo that. (Though it would probably transfer the data faster.) I think TCP/IP only shipped with MacOS 7.5 and later, would have required setup on another PC, and would still be convoluted (e.g. downloading FTP software to the Mac, so it could upload to a PC).
It's going to be a tricky situation.
Basically a second-pass where you look for outliers in each character-group, reassign them to another group, and keep the change if it improves similarity-scores the character groups involved. Then iterate a bit until nothing seems to be improving.
For example, one might find "the 3 that is least-like all the other 3s", temporarily reassign it to "8", and then keep that change if it means an improvement in the the scores for "how closely all sub-pictures of 3s resemble each other" and "how closely all sub-pictures 8s resemble each other".
That might backfire if a document has different typefaces in it though, where it makes the mistake of putting all "3"s from different typefaces together, ruining the group-similarity scores.
Still would risk some weirdness, but would help a bit I'd hope.
I wonder if it would be worth running some kind of language analysis or spelling/Grammer check to verify the scan too. At least for text, you'd need another solution for number tables.
I feel like this could be trivially solved by plugging an LLM to the OCR output with the sole task to correct spelling errors like that. That's pretty much one of the tasks LLMs should excell the most at.
ah, missed that, was just skipping through
This was painful to read, like using a butter knife as a precision screwdriver.
Yet another reason I hate when things I own try to enforce laws against me: there will be cases, like the author's, in which the law doesn't apply but the thing doesn't know it.
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.
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.
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).
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.
Now there's a much better and cheaper option: BlueSCSI [2]. It's a SCSI HDD emulator that allows to mount .img files stored on a SD card as HDD disks. It also supports CD and network card emulation.
Once the files are copied on a such a virtual drive, they can be extracted on a modern machine using via some kind of HFS explorer or an emulator.
[1] https://blog.rekawek.eu/2016/12/08/mac-plus#hard-drive
[2] https://bluescsi.com/
What I don't get is why Magneto-Optical didn't take off. 3.5" disks that were essentially MiniDisc but not proprietary (there were drives and disks from several manufacturers), faster than Zip, and eventually got upgraded to over 1 GB capacity disks. They were huge in Japan where they became a de-facto standard, but mostly unheard of in the rest of the world.
http://www.oocities.org/zztexpert/docs/upoprgv4.html