Hacker News Reader

Programming environments were available of course, but none were built-in. The fact that the external floppy doesn't work is the main problem here.

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.

>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.

[1] https://www.amazon.com/Serial-Converter-Adapter-Supports-Win...

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)

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.

>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.

Sure, but IDK how you'd send them on a mac without the software to do it?

Is there even an environment you can program in? Can Applescript on classic macos do serial stuff in any form?

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.

You could use local talk and another Mac with ethernet or a floppy drive. Mac file sharing is built in with system 7 and later

https://apple.fandom.com/wiki/Serial_port links to "Macintosh Serial Throughput" (1998) https://lowendmac.com/1998/macintosh-serial-throughput/ which mentions a Farallon Mac serial to Ethernet adapter.

/? 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

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.

[1] https://learn.microsoft.com/en-us/dotnet/api/microsoft.visua...

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.

> 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.

windows xp sp1 and later bundled .net framework, which included compilers for c# and vb.net.

ref: https://en.wikipedia.org/wiki/.NET_Framework_version_history...

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.

Mac OS X is a UNIX (of sorts). Mac OS classic (as in the article) is most definitely not.

So that version of MAcOS had no possibility of some command line shell scripting?

There was no command line at all.

Brings back memories, but you'd have to install a programming environment, e.g.:

- https://en.wikipedia.org/wiki/Macintosh_Programmer%27s_Works...

- http://www.think-pascal.org/#SetUp

- https://en.wikipedia.org/wiki/THINK_C

Everything from DOS 5.x onwards (including Windows 9x and NT) came with QBasic, previous versions of DOS had GW-BASIC.

Not the greatest tools out of the box, but still better than nothing.

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.

The RS-422 ports are backwards compatible with RS-232, so you don't even need a special RS-422 adapter to talk to them.

The RS-422 support is just there to support LocalTalk networking.

>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.

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.

Given that the perfect image from the fax barely worked, a photograph would certainly not do.

Or they’d do with a similar accuracy, since the main factor here is font rendering resolution.

>Given that the perfect image from the fax barely worked, a photograph would certainly not do.

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.

> 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).

It's going to be a tricky situation.

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.

One could also find-and-replace in Word to pick a set of 16 characters that avoids OCR confusion…

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").

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.

This is great! I'm amazed that someone else has solved the same problem in a different context. Good stuff.

> 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.

> hex dump

ah, missed that, was just skipping through

Still would not solve the problem of copying data without changing it.

Of course, use search and replace to change 0 to zero... etc. The OCR will (should) work better.

You might as well just use an error-correction code: same result, less overhead.

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.

yes i noticed that way too late, my bad