In CP/M, how does control-Z (hex 1a decimal 26) not interfere with ordinary file storage?
Consider this - I have made a file called test.bin on a Windows machine. It is exactly 256 bytes long, and contains nothing more than 00 to ff in each byte.
What would happen if I transferred this file to a CP/M system? (in fact this is exactly what I am trying to do).
Since the CP/M end of file marker is control Z or 1A in hex, will CP/M think that my 256 byte file stops when it gets to byte 1A?
I would have thought that hex 1A can appear all over the place in binary files such as executable COM files. How is it that CP/M uses this for an end of file marker without constantly truncating files early?
Is usage of controlZ at end of file a hard rule across CP/M - i.e. do all files have this as an end of file marker?
Is controlZ actually enforced by the operating system in any way, or is it simply a convention?
cp-m
asked 3 hours ago
Duke DougalDuke Dougal
1364
add a comment |
Consider this - I have made a file called test.bin on a Windows machine. It is exactly 256 bytes long, and contains nothing more than 00 to ff in each byte.
What would happen if I transferred this file to a CP/M system? (in fact this is exactly what I am trying to do).
Since the CP/M end of file marker is control Z or 1A in hex, will CP/M think that my 256 byte file stops when it gets to byte 1A?
I would have thought that hex 1A can appear all over the place in binary files such as executable COM files. How is it that CP/M uses this for an end of file marker without constantly truncating files early?
Is usage of controlZ at end of file a hard rule across CP/M - i.e. do all files have this as an end of file marker?
Is controlZ actually enforced by the operating system in any way, or is it simply a convention?
cp-m
asked 3 hours ago
Duke DougalDuke Dougal
1364
I'm pretty sure ^z only counted as a special character to the file system if a file name ends in ".txt". Otherwise files are considered binary and the file system has no interest regarding their actual content.
– RichF
1 hour ago
CP/M is very, very simple. Logic typically went in the transient programs.
– Thorbjørn Ravn Andersen
33 mins ago
add a comment |
Consider this - I have made a file called test.bin on a Windows machine. It is exactly 256 bytes long, and contains nothing more than 00 to ff in each byte.
What would happen if I transferred this file to a CP/M system? (in fact this is exactly what I am trying to do).
Since the CP/M end of file marker is control Z or 1A in hex, will CP/M think that my 256 byte file stops when it gets to byte 1A?
I would have thought that hex 1A can appear all over the place in binary files such as executable COM files. How is it that CP/M uses this for an end of file marker without constantly truncating files early?
Is usage of controlZ at end of file a hard rule across CP/M - i.e. do all files have this as an end of file marker?
Is controlZ actually enforced by the operating system in any way, or is it simply a convention?
cp-m
asked 3 hours ago
Duke DougalDuke Dougal
1364
Consider this - I have made a file called test.bin on a Windows machine. It is exactly 256 bytes long, and contains nothing more than 00 to ff in each byte.
What would happen if I transferred this file to a CP/M system? (in fact this is exactly what I am trying to do).
Since the CP/M end of file marker is control Z or 1A in hex, will CP/M think that my 256 byte file stops when it gets to byte 1A?
I would have thought that hex 1A can appear all over the place in binary files such as executable COM files. How is it that CP/M uses this for an end of file marker without constantly truncating files early?
Is usage of controlZ at end of file a hard rule across CP/M - i.e. do all files have this as an end of file marker?
Is controlZ actually enforced by the operating system in any way, or is it simply a convention?
cp-m
cp-m
asked 3 hours ago
Duke DougalDuke Dougal
1364
asked 3 hours ago
Duke DougalDuke Dougal
1364
edited 3 hours ago
Duke Dougal
asked 3 hours ago
Duke DougalDuke Dougal
1364
asked 3 hours ago
Duke DougalDuke Dougal
1364
asked 3 hours ago
Duke DougalDuke Dougal
1364
1364
I'm pretty sure ^z only counted as a special character to the file system if a file name ends in ".txt". Otherwise files are considered binary and the file system has no interest regarding their actual content.
– RichF
1 hour ago
CP/M is very, very simple. Logic typically went in the transient programs.
– Thorbjørn Ravn Andersen
33 mins ago
add a comment |
I'm pretty sure ^z only counted as a special character to the file system if a file name ends in ".txt". Otherwise files are considered binary and the file system has no interest regarding their actual content.
– RichF
1 hour ago
CP/M is very, very simple. Logic typically went in the transient programs.
– Thorbjørn Ravn Andersen
33 mins ago
I'm pretty sure ^z only counted as a special character to the file system if a file name ends in ".txt". Otherwise files are considered binary and the file system has no interest regarding their actual content.
– RichF
1 hour ago
I'm pretty sure ^z only counted as a special character to the file system if a file name ends in ".txt". Otherwise files are considered binary and the file system has no interest regarding their actual content.
– RichF
1 hour ago
CP/M is very, very simple. Logic typically went in the transient programs.
– Thorbjørn Ravn Andersen
33 mins ago
CP/M is very, very simple. Logic typically went in the transient programs.
– Thorbjørn Ravn Andersen
33 mins ago
add a comment |
2 Answers
2
active
oldest
votes
What would happen if I transferred this file to a CP/M system?
Depends on your transfer utility and how it handles the data presented.
Since the CP/M end of file marker is control Z or 1A in hex, will CP/M think that my 256 byte file stops when it gets to byte 1A?
No, at least not the OS itself. CP/M does not handle CTRL-Z (or any content) special. Your file transfer utility may do so.
Is controlZ actually enforced by the operating system in any way, or is it simply a convention?
No, it doesn't. So it's a convention among text based utilities.
How do I know when I have got to the end of the end of an executable file?
(from a comment)
You don't. At least not on byte level. Loading an executable is always done up to the next 128 byte record.
The long read
CP/M, up to and including 2.2 did not maintain a bytewise file length in its meta data (directory extend). Length was only noted as number of 128 byte records of the last extend. On DOS level read and write operation where always record based i.e. in 128 byte chunks (*1). While there was a function to calculate file size, it did as well only work with 128 byte granuality.
To allow termination of a file holding ASCII data CTRL-Z was used as end marker within the last record. All text oriented utilities did follow that scheme. But there is no hard provision.
CP/M 3.0 utilized a prior unused directory extend byte to note the bytes used within the last record. For compatibility a value of 128 is noted as zero.
*1 - Random access could operate on byte level, still the 128 byte record granuality was to be observed.
answered 3 hours ago
RaffzahnRaffzahn
46.4k5104188
Interesting. Looks like I am using CP/M 2.2 - does 2.2 actually save the exact file length somehow, even for binary files? How do I know when I have got to the end of the end of an executable file?
– Duke Dougal
3 hours ago
Sorry, I had the 2.2 part wrong, it wasn't until 3.0 that an exact file length was introduced. I also added further information to the answer.
– Raffzahn
2 hours ago
add a comment |
To highlight what @Raffzahn said, the ^Z part is part and partial to TEXT files.
Binary files had to deal with the file size issue differently, since you can't rely on ^Z not being in the data.
answered 3 hours ago
Will HartungWill Hartung
3,763821
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "648"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8719%2fin-cp-m-how-does-control-z-hex-1a-decimal-26-not-interfere-with-ordinary-file%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
What would happen if I transferred this file to a CP/M system?
Depends on your transfer utility and how it handles the data presented.
Since the CP/M end of file marker is control Z or 1A in hex, will CP/M think that my 256 byte file stops when it gets to byte 1A?
No, at least not the OS itself. CP/M does not handle CTRL-Z (or any content) special. Your file transfer utility may do so.
Is controlZ actually enforced by the operating system in any way, or is it simply a convention?
No, it doesn't. So it's a convention among text based utilities.
How do I know when I have got to the end of the end of an executable file?
(from a comment)
You don't. At least not on byte level. Loading an executable is always done up to the next 128 byte record.
The long read
CP/M, up to and including 2.2 did not maintain a bytewise file length in its meta data (directory extend). Length was only noted as number of 128 byte records of the last extend. On DOS level read and write operation where always record based i.e. in 128 byte chunks (*1). While there was a function to calculate file size, it did as well only work with 128 byte granuality.
To allow termination of a file holding ASCII data CTRL-Z was used as end marker within the last record. All text oriented utilities did follow that scheme. But there is no hard provision.
CP/M 3.0 utilized a prior unused directory extend byte to note the bytes used within the last record. For compatibility a value of 128 is noted as zero.
*1 - Random access could operate on byte level, still the 128 byte record granuality was to be observed.
answered 3 hours ago
RaffzahnRaffzahn
46.4k5104188
Interesting. Looks like I am using CP/M 2.2 - does 2.2 actually save the exact file length somehow, even for binary files? How do I know when I have got to the end of the end of an executable file?
– Duke Dougal
3 hours ago
Sorry, I had the 2.2 part wrong, it wasn't until 3.0 that an exact file length was introduced. I also added further information to the answer.
– Raffzahn
2 hours ago
add a comment |
What would happen if I transferred this file to a CP/M system?
Depends on your transfer utility and how it handles the data presented.
Since the CP/M end of file marker is control Z or 1A in hex, will CP/M think that my 256 byte file stops when it gets to byte 1A?
No, at least not the OS itself. CP/M does not handle CTRL-Z (or any content) special. Your file transfer utility may do so.
Is controlZ actually enforced by the operating system in any way, or is it simply a convention?
No, it doesn't. So it's a convention among text based utilities.
How do I know when I have got to the end of the end of an executable file?
(from a comment)
You don't. At least not on byte level. Loading an executable is always done up to the next 128 byte record.
The long read
CP/M, up to and including 2.2 did not maintain a bytewise file length in its meta data (directory extend). Length was only noted as number of 128 byte records of the last extend. On DOS level read and write operation where always record based i.e. in 128 byte chunks (*1). While there was a function to calculate file size, it did as well only work with 128 byte granuality.
To allow termination of a file holding ASCII data CTRL-Z was used as end marker within the last record. All text oriented utilities did follow that scheme. But there is no hard provision.
CP/M 3.0 utilized a prior unused directory extend byte to note the bytes used within the last record. For compatibility a value of 128 is noted as zero.
*1 - Random access could operate on byte level, still the 128 byte record granuality was to be observed.
answered 3 hours ago
RaffzahnRaffzahn
46.4k5104188
Interesting. Looks like I am using CP/M 2.2 - does 2.2 actually save the exact file length somehow, even for binary files? How do I know when I have got to the end of the end of an executable file?
– Duke Dougal
3 hours ago
Sorry, I had the 2.2 part wrong, it wasn't until 3.0 that an exact file length was introduced. I also added further information to the answer.
– Raffzahn
2 hours ago
add a comment |
What would happen if I transferred this file to a CP/M system?
Depends on your transfer utility and how it handles the data presented.
Since the CP/M end of file marker is control Z or 1A in hex, will CP/M think that my 256 byte file stops when it gets to byte 1A?
No, at least not the OS itself. CP/M does not handle CTRL-Z (or any content) special. Your file transfer utility may do so.
Is controlZ actually enforced by the operating system in any way, or is it simply a convention?
No, it doesn't. So it's a convention among text based utilities.
How do I know when I have got to the end of the end of an executable file?
(from a comment)
You don't. At least not on byte level. Loading an executable is always done up to the next 128 byte record.
The long read
CP/M, up to and including 2.2 did not maintain a bytewise file length in its meta data (directory extend). Length was only noted as number of 128 byte records of the last extend. On DOS level read and write operation where always record based i.e. in 128 byte chunks (*1). While there was a function to calculate file size, it did as well only work with 128 byte granuality.
To allow termination of a file holding ASCII data CTRL-Z was used as end marker within the last record. All text oriented utilities did follow that scheme. But there is no hard provision.
CP/M 3.0 utilized a prior unused directory extend byte to note the bytes used within the last record. For compatibility a value of 128 is noted as zero.
*1 - Random access could operate on byte level, still the 128 byte record granuality was to be observed.
answered 3 hours ago
RaffzahnRaffzahn
46.4k5104188
What would happen if I transferred this file to a CP/M system?
Depends on your transfer utility and how it handles the data presented.
Since the CP/M end of file marker is control Z or 1A in hex, will CP/M think that my 256 byte file stops when it gets to byte 1A?
No, at least not the OS itself. CP/M does not handle CTRL-Z (or any content) special. Your file transfer utility may do so.
Is controlZ actually enforced by the operating system in any way, or is it simply a convention?
No, it doesn't. So it's a convention among text based utilities.
How do I know when I have got to the end of the end of an executable file?
(from a comment)
You don't. At least not on byte level. Loading an executable is always done up to the next 128 byte record.
The long read
CP/M, up to and including 2.2 did not maintain a bytewise file length in its meta data (directory extend). Length was only noted as number of 128 byte records of the last extend. On DOS level read and write operation where always record based i.e. in 128 byte chunks (*1). While there was a function to calculate file size, it did as well only work with 128 byte granuality.
To allow termination of a file holding ASCII data CTRL-Z was used as end marker within the last record. All text oriented utilities did follow that scheme. But there is no hard provision.
CP/M 3.0 utilized a prior unused directory extend byte to note the bytes used within the last record. For compatibility a value of 128 is noted as zero.
*1 - Random access could operate on byte level, still the 128 byte record granuality was to be observed.
answered 3 hours ago
RaffzahnRaffzahn
46.4k5104188
edited 2 hours ago
answered 3 hours ago
RaffzahnRaffzahn
46.4k5104188
answered 3 hours ago
RaffzahnRaffzahn
46.4k5104188
answered 3 hours ago
RaffzahnRaffzahn
46.4k5104188
46.4k5104188
Interesting. Looks like I am using CP/M 2.2 - does 2.2 actually save the exact file length somehow, even for binary files? How do I know when I have got to the end of the end of an executable file?
– Duke Dougal
3 hours ago
Sorry, I had the 2.2 part wrong, it wasn't until 3.0 that an exact file length was introduced. I also added further information to the answer.
– Raffzahn
2 hours ago
add a comment |
Interesting. Looks like I am using CP/M 2.2 - does 2.2 actually save the exact file length somehow, even for binary files? How do I know when I have got to the end of the end of an executable file?
– Duke Dougal
3 hours ago
Sorry, I had the 2.2 part wrong, it wasn't until 3.0 that an exact file length was introduced. I also added further information to the answer.
– Raffzahn
2 hours ago
Interesting. Looks like I am using CP/M 2.2 - does 2.2 actually save the exact file length somehow, even for binary files? How do I know when I have got to the end of the end of an executable file?
– Duke Dougal
3 hours ago
Interesting. Looks like I am using CP/M 2.2 - does 2.2 actually save the exact file length somehow, even for binary files? How do I know when I have got to the end of the end of an executable file?
– Duke Dougal
3 hours ago
Sorry, I had the 2.2 part wrong, it wasn't until 3.0 that an exact file length was introduced. I also added further information to the answer.
– Raffzahn
2 hours ago
Sorry, I had the 2.2 part wrong, it wasn't until 3.0 that an exact file length was introduced. I also added further information to the answer.
– Raffzahn
2 hours ago
add a comment |
To highlight what @Raffzahn said, the ^Z part is part and partial to TEXT files.
Binary files had to deal with the file size issue differently, since you can't rely on ^Z not being in the data.
answered 3 hours ago
Will HartungWill Hartung
3,763821
add a comment |
To highlight what @Raffzahn said, the ^Z part is part and partial to TEXT files.
Binary files had to deal with the file size issue differently, since you can't rely on ^Z not being in the data.
answered 3 hours ago
Will HartungWill Hartung
3,763821
add a comment |
To highlight what @Raffzahn said, the ^Z part is part and partial to TEXT files.
Binary files had to deal with the file size issue differently, since you can't rely on ^Z not being in the data.
answered 3 hours ago
Will HartungWill Hartung
3,763821
To highlight what @Raffzahn said, the ^Z part is part and partial to TEXT files.
Binary files had to deal with the file size issue differently, since you can't rely on ^Z not being in the data.
answered 3 hours ago
Will HartungWill Hartung
3,763821
answered 3 hours ago
Will HartungWill Hartung
3,763821
answered 3 hours ago
Will HartungWill Hartung
3,763821
answered 3 hours ago
Will HartungWill Hartung
3,763821
3,763821
add a comment |
add a comment |
Thanks for contributing an answer to Retrocomputing Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8719%2fin-cp-m-how-does-control-z-hex-1a-decimal-26-not-interfere-with-ordinary-file%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I'm pretty sure ^z only counted as a special character to the file system if a file name ends in ".txt". Otherwise files are considered binary and the file system has no interest regarding their actual content.
– RichF
1 hour ago
CP/M is very, very simple. Logic typically went in the transient programs.
– Thorbjørn Ravn Andersen
33 mins ago