Suppose an Assembly program needs to read an arbitrary binary file sequentially and process every byte.

If BDOS function 20 Read Sequential reports an end of file condition by returning error code 01 in register A, how can the program tell what's the last byte of the file in a buffer that's likely filled only in part? With text files the program could
search for ^Z in the buffer, but what about binary files?

Similarly, if the program was written in Turbo Pascal and read the input with BlockRead from an untyped file, how would it detect the last byte?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, December 7, 2022 at 7:09:45 AM UTC-6, paolo....@gmail.com wrote:

Suppose an Assembly program needs to read an arbitrary binary file sequentially and process every byte.

If BDOS function 20 Read Sequential reports an end of file condition by returning error code 01 in register A, how can the program tell what's the last byte of the file in a buffer that's likely filled only in part? With text files the program could

search for ^Z in the buffer, but what about binary files?

Similarly, if the program was written in Turbo Pascal and read the input with BlockRead from an untyped file, how would it detect the last byte?

On CP/M 2.2 there is no way to know. Since all files are written in 128-byte record chunks anyway, it's sort of moot. CP/M 3 introduced a way to set a byte count for the last record in a file, see notes in BDOS functions 15 and 30.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, December 7, 2022 at 2:32:52 PM UTC+1, Douglas Miller wrote:

On CP/M 2.2 there is no way to know. Since all files are written in 128-byte record chunks anyway, it's sort of moot. CP/M 3 introduced a way to set a byte count for the last record in a file, see notes in BDOS functions 15 and 30.

Thanks. I'm curious how such a situation was handled on CP/M 2.2, if at all. Did programs typically process all the bytes of the last buffer in full, even if it might contain trailing garbage?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

A binary file is somewhat ambiguous, as it could be an executable (.COM), a relocatable object (.REL), a database file, or almost anything else. COM files are just 128-byte records, and the code within them simply does not ever try to execute past the
last instruction (unless there's a bug). REL files have a specific, sequential access, format and so the end is known by the encountering of a specific pattern. Database files usually have meta data that specifies exactly how many, and which, records are
in use. But in all these cases, full 128-byte records are loaded. They all just have different methods of avoiding uninitialized data - or else are defined such that all data is initialized (in a harmless way).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Douglas Miller <durgadas311@gmail.com> writes:

On CP/M 2.2 there is no way to know. Since all files are written in
128-byte record chunks anyway, it's sort of moot. CP/M 3 introduced a
way to set a byte count for the last record in a file, see notes in BDOS >functions 15 and 30.

Some useful notes on the latter (and on an unfortunate ambiguity) at https://www.seasip.info/Cpm/bytelen.html

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, December 7, 2022 at 12:42:06 PM UTC-6, paolo....@gmail.com wrote:

I wonder about programs that have no knowledge of the file structure, such as file dump utilities and binary editors.

If the program is CP/M 3-aware, it can try to get the byte-count. Otherwise, it operates on 128-byte records.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I wonder about programs that have no knowledge of the file structure, such as file dump utilities and binary editors.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

paolo....@gmail.com schrieb am Mittwoch, 7. Dezember 2022 um 19:42:06 UTC+1:

I wonder about programs that have no knowledge of the file structure, such as file dump utilities and binary editors.

The program bye.com from z80pack used to shutdown the VM's is only 17 bytes, but of course requires
a 128 byte sector to store on disk. A dump of the code:

dump bye.com

0000 DB A0 B7 CA 0A 01 3E AA D3 A0 3E 80 D3 A0 F3 76
0010 C9 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00



I filled the unused bytes with 0, but could have used anything, or just leave the random byes that
were in memory. Doesn't matter, but filling with 0 makes it looking better. As you can see dump
doesn't care, it just shows the bytes in the 1 record long file.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/12/2022 12:43 am, Paolo Amoroso wrote:

On Wednesday, December 7, 2022 at 2:32:52 PM UTC+1, Douglas Miller wrote:

On CP/M 2.2 there is no way to know. Since all files are written in 128-byte record chunks anyway, it's sort of moot. CP/M 3 introduced a way to set a byte count for the last record in a file, see notes in BDOS functions 15 and 30.

Thanks. I'm curious how such a situation was handled on CP/M 2.2, if at all. Did programs typically process all the bytes of the last buffer in full, even if it might contain trailing garbage?

If reading 'text' the application would stop at $1A or physical end-of-file, whichever
came first. With no such convention for binary data files, the application would need
to know beforehand what was the actual length - else treat it all as valid data.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)