68k New application: Tiny Transfer (BinHex .hqx conversion and file transfer)

[David Cook]

Hello everyone,

For bulk file copying on older Macs, nothing beats emulated hardware such as Floppy Emu, MacSD, ZuluSCSI, and so on. However, for sending small files back and forth, swapping the micro SD card in and out can feel a bit like sneakernet.

I've written a small application that runs on all Macs from the Mac 128K all the way up to the G3, and all operating systems they support. With Tiny Transfer, you can:
1. Send files over a serial cable to another Mac or emulator. No server, AppleTalk, inits, or reboots needed. Just a standalone application.
2. Synchronize the Mac's clock
3. Convert files to/from BinHex (.hqx) format

A limitation of the classic BinHex format is that file comments and file dates are not preserved. For many files this doesn't matter. But, when you want to publicly archive something like original versions of MacsBug, then the dates and comments are part of the story they tell. Tiny Transfer appends this additional information after the main BinHex section, so the file format stays compatible with older decoding applications.

Take a couple of minutes to download Tiny Transfer (ironically the .hqx then needs to be decoded by BinHex or StuffIt) and add it to your 'Tools' folder on your standard drive images. Then, next time you find yourself needing to convert to/from BinHex or transfer a file, give it a try!

- David

 

[ClassicHasClass]

Very nice! Will source code be available?

 

[ajacocks]

Very neat application @David Cook . Have you considered adding Zmodem? The old BBS’er in me would be happy.

- Alex

 

[David Cook]

Have you considered adding Zmodem?

Yes, I strongly considered it. Zmodem definitely has higher performance than Xmodem, as well as the ability to continue an interrupted file transfer from where it left off.

The power of Zmodem is that it uses a file offset rather than arbitrary packet numbers with ack/nak. That way you can tell the sender where you left off based of the size of the file received so far.

ZMODEM replaced the packet number with the actual location in the file, indicated by a 32-bit number. This allowed it to send NAK messages that re-wound the transfer to the point of failure, regardless of how long the file might be. This same feature was also used to re-start transfers if they failed or were deliberately interrupted. In this case, the receiver would look to see how much data had been previously received and then send a NAK with that location, automatically triggering the sender to start from that point.

Macintosh files need three different chunks: the file info, the data fork, and the resource fork. If the file info header is fixed in length (such as MacBinary), then I can still calculate the offset by acting like of all three parts are back-to-back sequential data. However, the precludes altering the size of the file contents in any way (such as the compression inherent in BinHex). One solution would be to first convert the file locally into a single fork format ("temp combined and compressed.hqx") so that it can always retry sending from a known fixed file offset. However, on a floppy drive, this might not fit and it might result in slower performance than just xmodem.

Nevertheless, good recommendation.