EOF Marker - CTRL-Z (&1A)

[CP/M User]

I've been trying a bit of Assembly which has been compiling the program as a COM file for use in CP/M. But I found it interesting to note that some COM files have a EOF Marker at the end, and just wanted to know if there was some significance behind this.
I was having problems with my Assembly file, running it multiple times and at random it would crash the whole system - the program & CP/M. I thought this might have been a fault with the program, though then I thought that perhaps CP/M is crashing cause the program wasn't closing properly or something. I did a memory dump of the file and discovered that past the end of my program there was useless garbadge which was unnecessarily, then I remembered that CP/M must save files in 128 byte chunks which was how the rubbish was getting in. So I put a &1A byte at the end of the program and zeroed up the rest so it would be clean and simply found the program only really crashed after doing a number of things in CP/M, though thought to myself that perhaps CTRL-C was a cure. But yeah I wasn't sure what EOF marker does I thought if it offically closes the file then it maybe an important element to have in my programs.

 

[GogglesPisano]

DOS records the exact byte file size with the file. CP/M only stores the chunks of the file and generally assumes the file size is a multiple of those chunks. For binary files, it usually doesn't matter since the structure of the file says exactly what to do with each byte in the file. For text files, the convention is to use Ctrl-Z to mark the end of the file or end of the text stream.

The missing Ctrl-Z in the source code should only affect the compilation of the source code. The binary program file shoudln't need a Ctrl-Z to terminate it.

 

[leeb]

You're right... the COM file is read in as 128-byte chunks... but in a COM file the EOF is figured by the qty of records, not an EOF 'flag'...

While a text file (of variable sorts) will show a 01aH and, likely 'random garbage' to fill out the 128...

Cannot say about the EOF at the end of a COM file... perhaps random chance. Either way, it will not affect the COM file (unless it NEEDS to be there and is not...)

:D

 

[Chuck(G)]

It wasn't unusual to put a 1a near the front of a .COM file, right after the copyright notice. That way, you could TYPE a .COM file to see what version you had.

MS-DOS is still pretty "chunky" also--it used to be that you could find all sorts of interesting junk in the unused part of the last cluster of a manufacturer's disk.

 

[CP/M User]

Okay that's a good way of looking at it, so in the case of a text file do a type - the type finds a &1A and immediately stops the rest from being displayed.

I've asked a few people about this, and in some cases some COM files have EOF markers at the end and some do not. The first COM file I saw like this only had one, but then I noticed other COM files are loaded up with EOF markers until the next record of 128 Bytes is reached.

The thing I was noticed was I was loading an Assembly file into a Word Processor and then Assembling that program into a COM file (it's a bit of a Word-processor come Assembler from the same mob, so it's all good and compatable), but because COM files work in records which are 128 bytes per chunk, some of the stuff I had been doing in the Word Processor was going into my COM file at the end of the program. So I wasn't sure if that was stuffing up my programs. Unfortunately I'm not sure that has been having any impact into why my programs were crashing in CP/M. I've got a feeling it's the Alternative Register set which maybe having an effect on it.

 

[Chuck(G)]

The stray 1A marker may also come from file transfer software from other non-CP/M systems, where it's simply added as part of the transfer from a host that doesn't use 1A as an EOF, regardless of file type. Sorcim, for instance, built a fair amount of SuperWrite and SuperCalc on a VAX 11/730 (as well as a Compupro box and a PC).

 

[JohnElliott]

The thing I was noticed was I was loading an Assembly file into a Word Processor and then Assembling that program into a COM file (it's a bit of a Word-processor come Assembler from the same mob, so it's all good and compatable), but because COM files work in records which are 128 bytes per chunk, some of the stuff I had been doing in the Word Processor was going into my COM file at the end of the program. So I wasn't sure if that was stuffing up my programs. Unfortunately I'm not sure that has been having any impact into why my programs were crashing in CP/M. I've got a feeling it's the Alternative Register set which maybe having an effect on it.

If a bug is causing your program to execute that bit of memory, or depend on data from it, then that might explain why you get different results if you fill it with 1A bytes.

Some systems use the alternate registers in interrupt handlers; if yours is one of them, then any timer interrupt would be liable to corrupt them at a random moment. Even if it isn't, you can't rely on them being preserved across calls to the BDOS or BIOS.

 

[CP/M User]

If a bug is causing your program to execute that bit of memory, or depend on data from it, then that might explain why you get different results if you fill it with 1A bytes.

Some systems use the alternate registers in interrupt handlers; if yours is one of them, then any timer interrupt would be liable to corrupt them at a random moment. Even if it isn't, you can't rely on them being preserved across calls to the BDOS or BIOS.

Hi John, Well I'll owe up to you by saying I've been getting some help with this, though I've been trying a few various things. Naturally I'm using the Cousin to the PCW - the CPC in CP/M 2.2. Have tried Alternative Register routines in my routines with and without Interrupts Disabled. The other thing I read about was making use of the Alternative Register set in the Lower ROM is bad as well - given my program is a COM file running from 100h, I thought maybe that's the issue.

For the routines I've been doing, the only solution I have found at this time is moving the Base Screen Address from &C000 to &4000, though it really limits the amount of memory my program could be, in indeed it needs to be of considerable size.