Groups | Search | Server Info | Login | Register
| Date | 2025-07-22 13:37 -0500 |
|---|---|
| Subject | Re: Transferring text files to CP/M ? |
| Newsgroups | comp.os.cpm |
| References | <687f914f$1@news.ausics.net> |
| From | John <john@somewhere> |
| Organization | Thundernews - www.thundernews.com |
| Message-Id | <1854a6b2e7fe52fd$82327$1040375$70dd3a6b@news.thundernews.com> |
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
Back to comp.os.cpm | Previous | Next — Previous in thread | Next in thread | Find similar
Transferring text files to CP/M ? dxf <dxforth@gmail.com> - 2025-07-22 23:25 +1000
Re: Transferring text files to CP/M ? John <john@somewhere> - 2025-07-22 13:37 -0500
Re: Transferring text files to CP/M ? dxf <dxforth@gmail.com> - 2025-07-23 12:06 +1000
Re: Transferring text files to CP/M ? Nils M Holm <nmh@sraddha.invalid> - 2025-07-23 09:14 +0000
csiph-web