8

On a VIC-20 or C-64, you could open a sequential file on a 1541, write exactly N bytes (say, 47 bytes) to it, then close it. Then you could open the same file for reading and start reading byte by byte (with GET#, for instance). After reading the 47th byte, you would get a special status (reserved variable ST = 64 in BASIC) to tell you the end of file had been reached.

But by my recollection (and this site), the 1541 directory entry only contained a number of blocks, and the only metadata in each block was a track/sector pointer to the next block of the file. I don't see a precise byte count anywhere. And, as far as I know, all byte values (00 through FF) were allowed as content in the file, so no code could be used as an end-of-file marker either. So how did DOS "know" that it had reached the end of file at byte 47? Was there a hardware-level marker in the last sector, or an extra byte in the inter-sector space that wasn't "visible" by applications?

0
12

Excerpted from Inside Commodore DOS, page 53

4.6 Sequential File Storage

The format of a sequential file is very straightforward. All the sectors, except the last one, look like this:

TRACK LINK - SECTOR LINK - 254 BYTES OF DATA

 Byte   Purpose
 0      Track of the next block in this file
 1      Sector of the next block in this file
 2-255  254 bytes of data

The last block in a sequential file is special for two reasons:

  1. It is the last sector.
  2. It is usually only partially full.

To signal the DOS that this is the last block, the first byte is set to $00. The first byte is normally the track link. Since there is no track 0, the DOS knows that this is the last sector in the file. The second byte indicates the position of the last byte in the file. Any bytes beyond this position are garbage.

2

Not the answer you're looking for? Browse other questions tagged or ask your own question.