From b1ea3e652ef3b6aba293726c7e5fb8461a41e8cc Mon Sep 17 00:00:00 2001 From: "B. Watson" Date: Wed, 19 Nov 2025 02:14:31 -0500 Subject: Tweak fileformat.txt. --- doc/fileformat.txt | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) (limited to 'doc/fileformat.txt') diff --git a/doc/fileformat.txt b/doc/fileformat.txt index 3638241..c0fe23c 100644 --- a/doc/fileformat.txt +++ b/doc/fileformat.txt @@ -38,13 +38,20 @@ Other things caused by the limitations of the Atari: the filename terminator, and any remaining bytes in the field will be set to $20 (ASCII spaces, *not* more nulls). +- Atari filenames with no extensions (e.g. "FOO") are stored with + a trailing period (e.g. "FOO.") in the ALF header. Upon extraction, + Atari DOSes will remove the period, so the file will be called + "FOO" again. I'm not sure whether the ARC for the Atari shares this + behavious, but ARC on MS-DOS or Linux doesn't do this. + - ALF files are never embedded inside a self-extracting executable, so the first file's header always starts at the first byte of the file. - ARC and ALF both store the compressed and uncompressed file lengths - as 32-bit unsigned integers... but for ALF, the maximum file size - that can be compressed is probably under 64KB, so both the lengths - should have their last 2 bytes set fo 0. I haven't yet attempted - to compress a file larger than 64KB with ALF on the Atari, so I - may be wrong... + as 32-bit unsigned integers... but the Atari can't deal with really + large files. From examining the disassembled code of UNALF14.COM, + it looks like the highest byte isn't even looked at, meaning the + maximum size for a single file is 16MB. I have actually tested the + Atari ALF and UNALF programs with an emulator (and emulated hard + drive) with a file of 200KB in size, and it worked fine. -- cgit v1.2.3