How to copy a file from a 30-year-old laptop
unterminated.com
unterminated.com
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...
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
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)
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?
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.
0123456789ABCDEF
012345M7XPAVKHEFThe 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.
For the record, you’d have had no problem mounting an image of the HFS disk on any modern Linux or macOS system.
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.
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.
The article author claims the networking software wasn't installed, though.
> Also SCSI tends to be easy to convert if one knows the drive connector/type, and is willing to chain a couple adapters.
I was thinking this too. And the author also says they didn't believe they'd be able to read the HFS volume, but Linux has had an HFS driver for... decades?... at this point.
In this case, it's a PowerBook Duo with a SCSI disk, so you'd need a Duo Dock or similar[2], a HDI-30-to-something-a-little-more-standard adapter [3], and whatever combination of cables, converters, and controllers are required to connect a parallel SCSI device into a more modern system.
For example, if you have a machine with a PCI Express slot (or Thunderbolt PCI Express enclosure), I'd recommend any of the LSI Logic Ultra320 adapters available on eBay for < $50, as drivers are readily available for macOS (AppleLSIFusionMPT.kext, included in all Mac OS versions worth mentioning, up to and including Sonoma, Intel and Apple Silicon), Linux (in-kernel mptspi driver), and Windows (the Windows Server 2008 driver[4] should work on current Windows versions).
Assuming all these things are in order, connect the Macs with a SCSI cable, hold down T while booting the PowerBook to enter target disk mode, and answer no to any prompts your OS may display offering to format the unreadable disk you just attached!
As for accessing the HFS filesystem, assuming macOS, my preferred method would be:
1. Create a raw disk image:
$ hdiutil create -tgtimagekey diskimage-class=CRawDiskImage -srcdevice disk<Number> <Name>.img
2. Shut down the PowerBook.
3. Make a backup copy of the image in case something goes wrong.
4. Install Mac OS 9 in qemu[5] and attach the image.
5. Use Alsoft PlusMaker[6] in Mac OS 9 to do an in-place conversion of the filesystem on the image from HFS to HFS+ (download the first file, use StuffIt[7] to extract the file and Toast[8] to mount the image, and run PlusMaker directly from the image to avoid being prompted for a serial number).
6. Shut down Mac OS 9 ("Shut Down" is in the Mac OS 9 Finder's "Special" menu).
7. Mount the resulting HFS+ image in (current) macOS (double-click in Finder, "hdiutil attach <Name>.img" from a command prompt, etc.).
Other options exist, but this is the easiest full-fidelity one that comes to mind.
As a bonus, you'll now have an emulated Mac OS 9 system that should run most of the applications from the original PowerBook's hard drive on your modern Mac.
[1] https://developer.apple.com/library/archive/technotes/tn/tn1...
[2] https://en.wikipedia.org/wiki/PowerBook_Duo#Docking_stations
[3] https://www.amazon.com/dp/B0081SAIS2/
[4] https://www.broadcom.com/support/download-search?pg=Legacy+P...
[5] https://wiki.qemu.org/Documentation/GuestOperatingSystems/Ma...
[6] https://www.macintoshrepository.org/19-plusoptimizer-plusmak...
[7] https://www.macintoshrepository.org/809-stuffit-deluxe-1-5-x...
[8] https://www.macintoshrepository.org/1724-toast-5-titanium
"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?
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.
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.
But then it turns out: taking the harddrive out of that Powerbook Duo 280c is kinda sorta a real mess for it requires taking the entire laptop apart (I just looked at an online teardown video of that old Mac laptop).
Now the advantage of eBay+Linux is that it works even if the screen is broken, if the laptop doesn't boot, etc. It works as long as the harddrive still boots.
With a dock, that laptop gains an external SCSI port.
And with an external SCSI port, it can boot up in a mode wherein the whole laptop behaves like a standalone SCSI disk -- ready to use with whatever other computer with SCSI from the past 40-ish years that one can muster up.
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.
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.
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.
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.
PC Convertible is another option: https://en.wikipedia.org/wiki/IBM_PC_Convertible
This was painful to read, like using a butter knife as a precision screwdriver.
-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.
> 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.
But, this worked with what he had at the time, so, eh, fun times.
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.)
10/10 for ingenuity anyway using the fax port.
The problem with the Appletalk to Ethernet adapter is that would definitely need drivers that are unlikely to exist on the Mac.
Given that, then using the serial port with a dumb terminal would be the next best option, but IIRC MacOS didn't ship with a terminal application so there's a bit of a chicken and egg problem.
What might exist is an Appletalk implementation for the GPIO ports on a Raspberry Pi or similar board, which would let you use the built-in Appletalk file sharing to get stuff on and off of the machine. The retrocomputing scene has to have something like that, it would be extremely useful.
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.
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.
Patient : Miniscribe 8425SA 20 MB SCSI hard disk from an Apple Hard Disk 20SC (external SCSI enclosure with a HDD). Hoped the disk was still in working condition after more than a decade stored (HDD was built in '88 and a sticker mentioned a repair in '99), the enclosure power supply was presumed dead (no power on) and the mac itself was shorting mains power in a few little minutes, probably from the screen high voltage converter dying and shorting.
I simply extracted the hard disk from the enclosure. This full height 3.5" disk has an "external" mechanical actuator : a stepper motor visible from outside drives the arm with the head(s) inside the disk, protected by a bellows. It gives a cool sort of a floppy drive sound when random access occurs.
I simply plugged it on a SCSI chain on my vintage Advansys SCSI PCI Card and ribbons.
Read the HFS partition with an old recovery software I could find on the recovery computer, quickly found the files (very simple file system and hierarchy), recovered them on the PC. Encountered just one bad sector.
Then looked the content of the file as raw shaking and ajusted the recovered text format for use with Windows PC/Word from the old word processor software - I think they were Corel Wordperfect files.
Very few correction to make to the raw text. Layout will have to be more thoroughly restored beyond EOL. Mainly accented characters and a few other replacements to do. I thought it would be more of an chore from an vintage apple system and third party software.
Overall, it was far easier than expected. Took me less than 2 hours. But am a ex data recovery guy with some ressources.
Quite pleased the miniscribe acted almost like a charm after 10 years or so of (warm, indoor) storage and not a single power on. Feared the HDD motor's ball bearing were totaly stuck !
I wonder if reducing the font size for faster transmission made it worse? A larger font might have been easier to read. Probably save time in the long run.
EDIT: Actually, looking at the output of the Fax to Binary Converter program, I think that's very likely. Even I'm not 100% sure whether that 8x6 glob of pixels is a 0 or a D.
Hmmm. If nothing else, what about search-and-replacing the Word doc to replace some of the most difficult characters with clearer ones, and then reversing the process on the other end? I mean, that's ridiculously complex, but not as complex as writing a custom Fax to Binary Converter app.
I simplified the story a bit for brevity. I actually tried a bunch of different font styles, including a 47 page fax using a pretty large size Courier (with only 72 characters per line). The screenshots from the blog post were after the point I decided OCR wasn't working, so I was using a heavily reduced font size to optimize the transfer time. Hence the characters looked like barely-legible blobs.
The Fax-to-Binary converter isn't doing anything particularly complicated with the image, just breaking it up into an accurately-aligned grid and hashing the pixel data of each tile.
Replacing the characters in the document hadn't occurred to me at the time! It's a good idea, but for my programmer brain, writing this software was the easier (and more fun) solution :)
Wow. That is very surprising. I'm baffled.
I suppose the author hasn't heard of eBay. The adapter is $15.
> The laptop has an AppleTalk port and a phone jack... but no networking software installed.
The author may have some search engine problems if they can't figure out that Macs have had networking software built in for ages, and that a PowerBook is too new to run any Mac OS that doesn't have networking :P
Transferring data via FAX is cool and job well done, but the other things really don't fit with a clever solution.
Just as a point of general archival best practices: old spinning media are extremely fragile. Your goal should be to image the drive exactly once, before doing anything else. Once that completes, everything amounts to a pure software problem you can solve at your convenience. But insisting on booting that drive repeatedly trying to "recover" it is a good way to break it forever.
Also:
> The internal hard drive uses SCSI with an unusual connector. 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.
Yeah, that's silly. You can literally mount that drive image on a vanilla linux box.
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.
Making a localtalk adapter is also a cool idea. There seem to be localtalk implementations (tashtalk) for PIC microcontrollers. Someone even made a localtalk-wifi gateway.
dd seek=
https://68kmla.org/bb/index.php?threads/adtx-scsi-ide-2-5-in...
[0] Macintosh PowerBook Duo 280c: Technical Specifications https://support.apple.com/en-us/112137
The internal hard drive uses SCSI with an unusual connector. 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.
Oh, it's about a Mac...
The sound I recall is the last phrase in 3stooges05.mp3 from here:
https://www.barbneal.com/the-collection/tv-shows/the-three-s...
Everyone's talking about the way to connect to the Mac, I'm just wondering if it's easier get the sound sources the Mac sounds the person wants were made from.
You'd have to "trim" it (e.g. quicktime), then using Garage Band you can make it a iOS ring tone (how I rebuilt my pre OSX Mac sounds from original sources).
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.
From there, I remember running ssh and scp on classic macs, so that is theoretically possible. Getting those old clients to talk with modern sshd might be tough.
I feel like I would attempt that, or perhaps floppies, before what this person did...
https://vintagemacmuseum.com/reading-powerbook-2-5-scsi-hard...
It'd take a bit of work but you could probably just go straight to USB and maybe even have some file system trickery where you misreport the amount of "free space" as the host os copies to the "1.44MB" floppy basically by opportunistically "removing and freeing" sectors from the virtual disk transparently, essentially always reporting 1.44MB. It's such a dirty and beautiful hack if it would work.
If I were doing this, this is essentially the only approach I'd actually be interested in.
The files were very small and recorded with the internal mic on the computer, so it's not as though these are high quality recordings, they're more sentimental to whoever owned the laptop.
But if we’re going with crazy hacks, I bet one could emulate an ADB keyboard to copy binaries onto the laptop by sending keystrokes to “type” hex into ResEdit.
AFAIK modern Linux is still able to properly read from HFS and HFS+. I mounted a MacOS 9 disk image just a few days ago.
Somewhat misleading. It would have been trivial if the laptop didn't have multiple hardware faults.
Could just use a serial cable on one end, and USB->serial or parallel port cable that could transfer files with the software to allow file transfers easily.
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.
How about directly connecting a DSO to the speaker terminals?
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.