From Newsgroup: comp.os.cpm

When writing text files intended for a CP/M environment, I've been
padding them with $1A characters such that the length is a multiple
of 128 bytes.

Is this necessary - or will CP/M emulators and/or file transfer tools automatically do this? I know MYZ80 pads with $1A. Is that true of
others?

As a compromise I was considering terminating such files with a single
$1A character. That should at least avoid problems with 'junk fill'.

Any observations or thoughts? Thanks.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

On 7/22/25 8:25 AM, dxf wrote:

When writing text files intended for a CP/M environment, I've been
padding them with $1A characters such that the length is a multiple
of 128 bytes.

Is this necessary - or will CP/M emulators and/or file transfer tools automatically do this? I know MYZ80 pads with $1A. Is that true of
others?

As a compromise I was considering terminating such files with a single
$1A character. That should at least avoid problems with 'junk fill'.

Any observations or thoughts? Thanks.

A properly written program will stop at the EOF marker ($1A), so there
is no need to pad additional $1As after the first one. All that data is 'don't care' mode as it will never be processed. That's the way I've
always done it.

However, more modern coders may not be aware of the EOF marker and
process the remainder of the buffer by mistake. And very strange they
would think all CP/M programs magically end at 128 byte boundaries with
all valid code in there.

Best course of action is to follow the standard and rewrite the errant code.

-J
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

On 23/07/2025 4:37 am, John wrote:

A properly written program will stop at the EOF marker ($1A), so there is no need to pad additional $1As after the first one.-a All that data is 'don't care' mode as it will never be processed. That's the way I've always done it.
...

I think I'll do that from now on. Padding the file length out to a record
was done out of an abundance of caution. But if nobody else has found it necessary, then it's less work for me. I had a utility to pad files but
being an extra step, it was more hassle than worth.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

dxf <dxforth@gmail.com> wrote:

On 23/07/2025 4:37 am, John wrote:

A properly written program will stop at the EOF marker ($1A), so there is no need to pad additional $1As after the first one.? All that data is 'don't care' mode as it will never be processed. That's the way I've always done it.
...

I think I'll do that from now on. Padding the file length out to a record was done out of an abundance of caution. But if nobody else has found it necessary, then it's less work for me. I had a utility to pad files but being an extra step, it was more hassle than worth.

Just to add another data point: all programs I have written so far
would interpret a single $1A as the EOF.
--
Nils M Holm < n m h @ t 3 x . o r g > http://t3x.org
--- Synchronet 3.21a-Linux NewsLink 1.2