1. Forum
  2. USENET
  3. comp.os.cpm

  • Transferring text files to CP/M ?

    From dxf@dxforth@gmail.com to comp.os.cpm on Tue Jul 22 23:25:34 2025
    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 John@john@somewhere to comp.os.cpm on Tue Jul 22 13:37:22 2025
    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 dxf@dxforth@gmail.com to comp.os.cpm on Wed Jul 23 12:06:35 2025
    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 Nils M Holm@nmh@sraddha.invalid to comp.os.cpm on Wed Jul 23 09:14:51 2025
    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