The first 192 bytes of this area (2818-3007/$0B00-$0BBF) are used for the cassette buffer. When you’re reading from tape, file headers are loaded into this area until one is found with the specified filename. When you’re writing to tape, this area is used to assemble the tape header for the file. When the buffer contains a tape header, the locations are used as follows:
| Location | Function |
|---|---|
| 2816/$0B00 | Header type identifier |
| 2817-2818/$0B01-$0B02 | Starting address for file |
| 2819-2820/$0B03-$0B04 | Ending address for file |
| 2821-3007/$0B05-$0BBF | Filename |
A header type identifier of 1 indicates a relocatable program file; 3 indicates a nonrelocatable program file; 4, a data file; and 5, an end-of-tape marker. A type identifier value of 2 means that the block contains data rather than a header. Although the filename can be up to 187 bytes long, such names are unusual. When a header is read into the buffer, only the first 16 characters of the filename will be displayed following the FOUND message. When a header is being assembled, all unused filename bytes will be set to 32/$20, the value for the space character.
The cassette buffer is used to hold blocks of data when data files are read from or written to tape. When a data file is being written, after the header is written to tape, the first byte here is set to 2, the identifier for a data block; then the remaining 191 bytes are filled with the data to be written to the file. Only when the buffer is completely full is the block of data actually added to the file. This is why it is important to properly close any file opened for writing. If the file is not closed, the last block of data will not be written to tape. When a file is opened for reading, after the proper header is identified, the first block of data is read into the buffer. Subsequent bytes will be read from the buffer-not directly from tapeuntil all 191 data bytes have been read from the buffer; then the next block will be read into the buffer.
In the 128, this area has a second function: the boot sector buffer. If the BOOT_CALL routine $F890 finds a disk in the specified drive when it is called, the contents of sector 0 of track 1 of the disk are read into this area. The first three bytes of the buffer are then examined. If those locations (the first three bytes from the sector) contain the character codes for the letters CBM, then the routine assumes that a boot disk has been found and proceeds with the boot process. It would be possible to simulate a boot by filling the buffer with the proper values, then jumping into the BOOT_CALL routine at address $F8F9.
The BOOT_CALL routine is normally executed during each reset as part of the BASIC cold-start sequence. It can also be called from the Kernal jump table entry at 65363/$FF53, and can be initiated from BASIC via the BOOT statement.
Actually, the cassette buffer is not located absolutely at this area. The base address of the cassette buffer is determined by the value in locations $B2-$B3. Those locations are initialized to 2816/$0B00 during the RAMTAS routine $E093, part of the reset sequence. No system ROM routines change that setting, but another free 192-byte area could be used, with two restrictions: the buffer must start at an address greater than 511/$1FF, and the buffer must be visible in the bank 15 memory configuration. The disk-booting routines, on the other hand, do use the absolute address of this area. This area will always be used as the boot sector buffer, regardless of the value in the cassette buffer pointer.
If tape data storage is not being used, this 256-byte area is available for other uses, such as to hold short machine language routines. The cassette buffer has been a popular area for ML since the days of the first Commodore PET /CBM computers. However, the contents of this area will be overwritten whenever the system attempts to boot a disk, including the time during any reset when the drive is turned on and contains a disk. You should choose another area if you want your machine language to survive intact following a reset.