Does AppleLink ACU still exist?

[fadden]

I'm looking for a copy of the old AppleLink Conversion Utility (ACU), which I've been calling the AppleLink Compression Utility but the manual says otherwise. I managed to find a copy of AppleLink (https://www.apple.asimov.net/images/gs/communications/AppleLink.zip), but while it has an ACU.SYS16 that looks promising, it turns out just to be a note telling you where to find the real thing online.

Does a working copy of ACU still exist? I've looked through various FTP sites and CD-ROM images. It got replaced by ShrinkIt almost immediately, so it didn't get much traction, and it seems like you could only get it by being an AppleLink-PE subscriber, which cut distribution down significantly.

On a related note...

From that same directory, I ran ALINK.SYS16 instead, which got a little strange. It starts out well enough, but if you click "work offline", you go to an 80-column text mode desktop environment. It appears something is mis-configured, so it only draws every-other column. The leftmost (column zero) is blank, as are all even-numbered columns. The behavior was the same in old KEGS (v0.91, ROM 01) and GSplus (v0.14, ROM 03). I haven't tried it on a real IIgs.

The behavior is the same whether you run it off of the floppy, which boots ProDOS-16, or from GS/OS.

[I am Rob]

JOOC, If ACU didn't get any traction and there are no files that were ever compressed using it, and it is probably inferior to ShrinkIt, what would the purpose be to having it? :)

[fadden]

On Tuesday, September 5, 2023 at 7:05:42 AM UTC-7, I am Rob wrote:
> JOOC, If ACU didn't get any traction and there are no files that were ever compressed using it, and it is probably inferior to ShrinkIt, what would the purpose be to having it? :)

Such files are rare but they do exist, e.g. I found one on Asimov and a few more on the major Apple II CD-ROM images. The old "ground" FTP site has dozens (dig around in https://mirrors.apple2.org.za/ground.icaen.uiowa.edu/Collections/AOL/, e.g. development/applications/).

The format is straightforward, but my attempts to match the checksum algorithm haven't been successful. I was hoping to throw a few files with known contents at it. (It's using the standard CRC-16/XMODEM for the record headers, but the computations on the file data aren't coming out right.)

There's also a meta-concern about software vanishing entirely from existence.

[Kelvin Sherlock]

AppleLink (and AOL) write to text page 1/2 via bank $e0, using $c054/5
to switch between banks (instead of just using bank $e1). That's
apparently a weird thing to do and most emulators don't support it.

MAME and actual hardware display correctly.

>

-------
ProLine: kelvin@pro-kegs

[David Schmidt]

On 9/5/23 10:51 AM, fadden wrote:
> [...]

> The format is straightforward, but my attempts to match the checksum algorithm haven't been successful. I was hoping to throw a few files with known contents at it. (It's using the standard CRC-16/XMODEM for the record headers, but the computations on the file data aren't coming out right.)

I'm sure a quick ChatGPT query will get you the polynomial. If you want
to have some fun for yourself:
https://www.csse.canterbury.ac.nz/greg.ewing/essays/CRC-Reverse-Engineering.html

[fadden]

On Tuesday, September 5, 2023 at 9:21:41 AM UTC-7, David Schmidt wrote:
> I'm sure a quick ChatGPT query will get you the polynomial. If you want
> to have some fun for yourself:
> https://www.csse.canterbury.ac.nz/greg.ewing/essays/CRC-Reverse-Engineering.html

I don't think the problem is the polynomial. I get the correct result for the record header (took a few tries... finally figured out that I needed to include the variable-length filename field too), and it seems unlikely that the author would use one algorithm for the header and a different one for the file body.

The problem may come down to picking the right seed (tried 0x0000 and 0xffff), or computing it on a buffer padded to a certain length. If I can find the original program then I can throw some single-byte files at it and save a lot of time guessing.

[Antoine Vignau]

Hi Andy,
I've uploaded a couple of files at https://www.brutaldeluxe.fr/public/applelink/
The 2mg image has the ACU support in the II.FOLDER/ACU/ - This is where you can pack & unpack files.
Antoine

[Jerry Penner]

Shrinkit 3.4 can open ACU files ($e0/$8001), if that's any help.

--
Jerry jerry+a2 at jpen.ca

[fadden]

On Tuesday, September 5, 2023 at 4:04:28 PM UTC-7, Antoine Vignau wrote:
> I've uploaded a couple of files at https://www.brutaldeluxe.fr/public/applelink/
> The 2mg image has the ACU support in the II.FOLDER/ACU/ - This is where you can pack & unpack files.

Yes, that's it! Another victory in the fight against entropy. :-) Thanks for tracking that down.

I ran some test files, and... it's complicated. CRC-16/XMODEM is an exact match for files up to 256 bytes, whether they're SQueezed or uncompressed (CRC is on the uncompressed data). When the original file exceeds 256 bytes, the CRCs no longer match.

I damaged some smaller files and confirmed that the errors were detected when unpacking with ACU. However, when I damaged a larger file, I found that ACU unpacked the file without complaint. The CRCs are different for 256-byte and 257-byte files filled with a single value, so it's not stopping at 256. Some additional fiddling was inconclusive.

I'll play with it some more, but it may just be broken.

[fadden]

On Tuesday, September 5, 2023 at 10:12:51 PM UTC-7, Jerry Penner wrote:
> Shrinkit 3.4 can open ACU files ($e0/$8001), if that's any help.

I can confirm that ShrinkIt unpacks damaged ACU archives without complaint. I expect it's ignoring the CRCs, possibly because AndyN also discovered that they were bogus.

[Antoine Vignau]

Perhaps, the CRC works with files up to 256 bytes (included) but does not work / fails / is buggy with / files as from 257 bytes. It would mean to be a weak CRC :-)

I have not tried to disassemble the ACU stuff, you are a master at it, so I think you already know the advantage/limits/drawbacks of the current implementation.

Cheers,
Antoine

[fadden]

On Thursday, September 7, 2023 at 12:29:13 PM UTC-7, Antoine Vignau wrote:
> Perhaps, the CRC works with files up to 256 bytes (included) but does not work / fails / is buggy with / files as from 257 bytes. It would mean to be a weak CRC :-)

I'm curious how it managed to go wrong in such a specific way... but not curious enough to actually disassemble the thing. :-)

I put a summary of findings here: https://github.com/fadden/CiderPress2/blob/main/DiskArc/Arc/AppleLink-notes.md

A sample archive with valid and damaged files has been added to the TestData directory: https://github.com/fadden/CiderPress2/tree/main/TestData/acu

The CP2 implementation checks the header CRCs and simply ignores the file data CRCs. Should be good enough.

[Kent Dickey]

In article <ud7kfo$21vgs$1...@dont-email.me>,

KEGS 1.30 displays the AppleLink screen correctly. I was not aware of this
issue previously.

Kent