> 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)!
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.
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.
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.
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.
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.
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.
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.
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.
Appletalk is the way to go, the drivers are built in and apple did a good job of maintaining compatibility over a long timeframe. I have similar issues moving stuff between a IIGS and modern machines. Its possible to move stuff with floppy emulators, via scsi , or just raw serial, but the simplicity of having a Mac with both appletalk and ethernet, allows one to drag and drop entire file hierarchies between the target appletalk based machine and a SMB/etc share from the machine in the middle.
Also SCSI tends to be easy to convert if one knows the drive connector/type, and is willing to chain a couple adapters. I'm sure that is the case here too, the 2.5" scsi drives were a form of SCA connectors IIRC, SCSI adapters exist for almost anything to anything as long as the single ended vs differential rules are followed, newer ultra differential adapters could usually fall back to 8 bit single ended allowing them to drive just about everything. The problem is going to be finding an OS/etc that can real the old mac filesystems although I'm guessing one of the utilities to read raw images (of which i'm failing to remember the ones Ive used in the past) could probably read/write the raw disk image.
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.
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.
>The internal hard drive uses SCSI with an unusual connector. Adapting it didn't seem straightforward
this was the way:
SCSI is a bus mastering protocol which allows multiple masters to share the bus, which means you can plug two computers into the same SCSI bus at the same time and they will both be able to share access the disk device. You wouldn't want to rely on simultaneous access to the file system, but the entire disk from those days would be just a large file today and you could just dump the whole thing (the inconsistencies in the open file system would be like recovering from a crash, and none of the long term files would be affected)
> and we weren't confident the old file system (HFS) would be easy to read from a modern system.
the nice thing about opensource/New Jersey style is that that old HFS would be completely easy to mount loopback on linux
I still have a complete disk image of my old Mac SE20 from 1988, and I still mount it up from time to time, and I pulled it off my old mac through the scsi bus. I believe the 20 referred to the MHz of the 68020 processor, but it also coincidentally had a 20MB disk, as was the case for the SE30 that came out the following year.
> Deus fax machina: While the laptop has no networking software, it does have fax software ... The first question was how to turn the audio file into something faxable.
this reminds me of an old idea I had that I never pursued. Back in the days of fax there was generally a cover sheet for tracking/delivery of faxes in an office environment, but which seemed like a waste of paper/modem time to me who was never in a big org situation. To cut to the chase for my idea, I thought it would be cool to transmit something like a large QR code on the coversheet, which would be an encoding of the document you were sending in .DOC (ms-word) format. That way, you could fax to a fax machine, but if the recipient was a computer modem it could receive the document in original format, and abort (via handshake) the rest of the fax transmission. I thought it would be a gentle way to transition past "obsolete" fax technology.
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.
Wow! That was an exciting read. It was way too complex for my limited knowledge of computers.
Sometime around 1993-1994, based on my placements against other relative events, I had the opportunity to "fix" a non-booting IBM Laptop. It was thick, heavy, and large but with just a screen the size of a 3½ Floppy. I have never encountered such a laptop in pictures or elsewhere, so I will assume it was even older in those years.
If anyone have any idea what that might be, it would be nice to see a picture.
An eccentric, out-of-time, local-uncle/mentor gave me that to fix and I let it lie on my table for a few days just to show off to others. I think we did something stupid and simple to fix it - replace the AUTOEXEC.BAT and then load WordStar, which was the only thing they need. Not even Windows 3x but DOS.
The Laptop was likely given by the visiting Christian Missionaries who visit the local Churches in my hometown.
I've another computer-fixing story, but I need to remember and write down the details. Sleeping in an army barrack in the mountains, armed guards while we pee, and returning home while taking care of a pregnant woman in an ambulance. That "mission" was with my childhood/neighbor friend, but he died. That out-of-time uncle also died. Not related.
Although the screen on that would have been somewhat larger than a 3.5" floppy (and it didn't even come with 3.5 floppies, just 5.25). You could find a smaller screen on the Osborne 1 and other early 80s portables, but they wouldn't have run DOS.
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.
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!
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.
I'm not a Mac guy, but it seems like they glossed over all of the normal solutions to intentionally come up with weirdest one possible. Good for them getting the files they needed I guess, but still weird.
What about pointing a camera at the screen and then paging through all the numbers on the Mac while capturing images?? Then you could OCR the numbers directly on the capturing laptop rather than trying to convert sound back into text.
In the picture with the phone cable plugged into the modem port directly next to it appears to be an Ethernet port. I know the blog post says there was "no networking software" installed, but the OS came with file sharing capabilities built in. Someone would have had to gone to effort to remove it. It might even have an old school FTP client.
That picture is of the thinkpad he used to receive the faxes. The mac doesn't have an ethernet port. I believe it would have had appletalk that maybe could have connected to ethernet using an adapter.
If it was an old DOS/Windows laptop, you could just use INTERLNK via COM or parallel port. I have to post that, it's just such a nostalgic memory copying files like that.
So if somebody needs to do it: Dosbox + USB-RS232 adapter and the right cable. INTERLNK/SRV was included with DOS 6.0 and later, so it's rather easy to find.
Since these are audio recordings an easier hardware approach would be to tap the output of the motherboard's D/A converter right before the speaker amp and capture it with an A/D. You could also tap the speaker wires which should be easier than tapping thin SMD traces, though the signal might have been highpassed before amplication to better support the small laptop speakers.
Of course this means you'll have to disassemble the ancient laptop and all that, and it won't be a bitperfect capture. For voice recordings though the quality should be more than adequate.
[+] [-] qiqitori|1 year ago|reply
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)!
[+] [-] lisper|1 year ago|reply
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.
[+] [-] Terr_|1 year ago|reply
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.
[+] [-] zamfi|1 year ago|reply
[+] [-] OptionOfT|1 year ago|reply
[+] [-] tfvlrue|1 year ago|reply
[+] [-] jdthedisciple|1 year ago|reply
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.
[+] [-] ruslan|1 year ago|reply
1. https://everymac.com/systems/apple/powerbook_duo/specs/mac_p...
[+] [-] oneplane|1 year ago|reply
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.
[+] [-] tfvlrue|1 year ago|reply
[+] [-] gcp123|1 year ago|reply
[+] [-] thebeardisred|1 year ago|reply
[+] [-] rvense|1 year ago|reply
[+] [-] perakojotgenije|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] mbreese|1 year ago|reply
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.
But, where's the fun in that?
[+] [-] tfvlrue|1 year ago|reply
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.
[+] [-] immibis|1 year ago|reply
[0] https://social.immibis.com/notice/AeWSRvyKlhBB2hANoe
[+] [-] hypercube33|1 year ago|reply
[+] [-] gizajob|1 year ago|reply
[+] [-] Evidlo|1 year ago|reply
[+] [-] p0seidon|1 year ago|reply
[+] [-] chasil|1 year ago|reply
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.
[+] [-] ruslan|1 year ago|reply
[+] [-] StillBored|1 year ago|reply
Also SCSI tends to be easy to convert if one knows the drive connector/type, and is willing to chain a couple adapters. I'm sure that is the case here too, the 2.5" scsi drives were a form of SCA connectors IIRC, SCSI adapters exist for almost anything to anything as long as the single ended vs differential rules are followed, newer ultra differential adapters could usually fall back to 8 bit single ended allowing them to drive just about everything. The problem is going to be finding an OS/etc that can real the old mac filesystems although I'm guessing one of the utilities to read raw images (of which i'm failing to remember the ones Ive used in the past) could probably read/write the raw disk image.
[+] [-] kjellsbells|1 year ago|reply
"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?
[+] [-] jtriangle|1 year ago|reply
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.
Perks of being a hardware guy first to be honest.
[+] [-] anal_reactor|1 year ago|reply
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.
[+] [-] fragmede|1 year ago|reply
[+] [-] fsckboy|1 year ago|reply
this was the way:
SCSI is a bus mastering protocol which allows multiple masters to share the bus, which means you can plug two computers into the same SCSI bus at the same time and they will both be able to share access the disk device. You wouldn't want to rely on simultaneous access to the file system, but the entire disk from those days would be just a large file today and you could just dump the whole thing (the inconsistencies in the open file system would be like recovering from a crash, and none of the long term files would be affected)
> and we weren't confident the old file system (HFS) would be easy to read from a modern system.
the nice thing about opensource/New Jersey style is that that old HFS would be completely easy to mount loopback on linux
I still have a complete disk image of my old Mac SE20 from 1988, and I still mount it up from time to time, and I pulled it off my old mac through the scsi bus. I believe the 20 referred to the MHz of the 68020 processor, but it also coincidentally had a 20MB disk, as was the case for the SE30 that came out the following year.
> Deus fax machina: While the laptop has no networking software, it does have fax software ... The first question was how to turn the audio file into something faxable.
this reminds me of an old idea I had that I never pursued. Back in the days of fax there was generally a cover sheet for tracking/delivery of faxes in an office environment, but which seemed like a waste of paper/modem time to me who was never in a big org situation. To cut to the chase for my idea, I thought it would be cool to transmit something like a large QR code on the coversheet, which would be an encoding of the document you were sending in .DOC (ms-word) format. That way, you could fax to a fax machine, but if the recipient was a computer modem it could receive the document in original format, and abort (via handshake) the rest of the fax transmission. I thought it would be a gentle way to transition past "obsolete" fax technology.
[+] [-] t0mek|1 year ago|reply
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/
[+] [-] Brajeshwar|1 year ago|reply
Sometime around 1993-1994, based on my placements against other relative events, I had the opportunity to "fix" a non-booting IBM Laptop. It was thick, heavy, and large but with just a screen the size of a 3½ Floppy. I have never encountered such a laptop in pictures or elsewhere, so I will assume it was even older in those years.
If anyone have any idea what that might be, it would be nice to see a picture.
An eccentric, out-of-time, local-uncle/mentor gave me that to fix and I let it lie on my table for a few days just to show off to others. I think we did something stupid and simple to fix it - replace the AUTOEXEC.BAT and then load WordStar, which was the only thing they need. Not even Windows 3x but DOS.
The Laptop was likely given by the visiting Christian Missionaries who visit the local Churches in my hometown.
I've another computer-fixing story, but I need to remember and write down the details. Sleeping in an army barrack in the mountains, armed guards while we pee, and returning home while taking care of a pregnant woman in an ambulance. That "mission" was with my childhood/neighbor friend, but he died. That out-of-time uncle also died. Not related.
[+] [-] cornholio|1 year ago|reply
Although the screen on that would have been somewhat larger than a 3.5" floppy (and it didn't even come with 3.5 floppies, just 5.25). You could find a smaller screen on the Osborne 1 and other early 80s portables, but they wouldn't have run DOS.
PC Convertible is another option: https://en.wikipedia.org/wiki/IBM_PC_Convertible
[+] [-] wannacboatmovie|1 year ago|reply
This was painful to read, like using a butter knife as a precision screwdriver.
[+] [-] PreInternet01|1 year ago|reply
-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...
[+] [-] tfvlrue|1 year ago|reply
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!
[+] [-] gist|1 year ago|reply
> 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...
[+] [-] endgame|1 year ago|reply
http://www.oocities.org/zztexpert/docs/upoprgv4.html
[+] [-] semi|1 year ago|reply
[+] [-] Suppafly|1 year ago|reply
[+] [-] gizajob|1 year ago|reply
10/10 for ingenuity anyway using the fax port.
[+] [-] sponaugle|1 year ago|reply
[+] [-] axus|1 year ago|reply
[+] [-] WalterBright|1 year ago|reply
[+] [-] jandrese|1 year ago|reply
[+] [-] Suppafly|1 year ago|reply
[+] [-] andix|1 year ago|reply
So if somebody needs to do it: Dosbox + USB-RS232 adapter and the right cable. INTERLNK/SRV was included with DOS 6.0 and later, so it's rather easy to find.
[+] [-] mysteria|1 year ago|reply
Of course this means you'll have to disassemble the ancient laptop and all that, and it won't be a bitperfect capture. For voice recordings though the quality should be more than adequate.