Csdrhrt

The Commodore 1541 disk drive and other IEC devices are self-contained computers. The operating system runs on the drive itself. This setup significantly improves the flexibility. As a side effect, if there is an error during a disk operation, the computer doesn't know about it. Only the drive knows. You had to open the error channel and listen for error codes to check errors.

When you open the error channel and multiple files at the same time, all open files are closed when you close the error channel. Thanks to this fail-proof mechanism, if you encounter a disk error while working with several files, you can close the error channel and safely quit the program without knowing which files are open. You don't have to keep track of open files, since they all will be closed automatically.

However, the 1541 user manual says that automatically closing files in this way is dangerous because BASIC doesn't know they were closed and this is a very dangerous situation!

What is the danger involved in trying to write a file that's already closed? The only risk I see is getting a write error.

I've copied the warning from the 1541 users manual below:

If you close the error channel while other files are OPEN, the disk
drive will CLOSE them for you, but BASIC will still think they are
open (unless you CLOSE them properly), and let you to try to write to
them.

NOTE: If your BASIC program leads you into an error condition, all
files are CLOSED in BASIC, without CLOSEing them on your disk drive!
This is a very dangerous condition. You should immediately type the
statement CLOSE 12: OPEN 15, 8, 15: CLOSE 15. This will re-initialize
your drive and make all your files safe.

In what might be borderline as acceptably a separate answer from paxdiablo, cf. the 1541 ROM disassembly. It's fully commented, so the following comments are a companion's guide to draw your attention to what I think are the relevant bits, see the full thing for a more thorough treatment.

The main dispatch loop, which listens to the serial bus and acts upon incoming commands, starts at E85B. Notice at E8CE that it'll segue to DAC0 if a CLOSE is received.

That code treats 15 as a special case — if that's received it'll just count down from 14 to 0 calling close file on each; that's the loop that is seeded at DAEC and then consists of DAF0, DAF3 and DAF5. For any regular channel it jumps straight to the close file routine.

The close individual file routine is at DB02 but an immediate corollary:

• the ROM itself treats a request to close all as a simple sequence of CLOSE 14, CLOSE 13 ... CLOSE 0. The outer loop doesn't check whether the files are open, and it ends up at exactly the same place as if you'd typed CLOSE X. Therefore one can assume a priori that it is safe to close files that aren't open.

One doesn't really need to assume though; check out the test from DB04: is there actually anything associated with this channel? If not, stop harmlessly.

Re:

all files are CLOSED in BASIC, without CLOSEing them on your disk drive! This is a very dangerous condition.

and the implication that CLOSEing does something meaningful on the disk drive, skip ahead to DB20. From there there's a sequence of:

• write last block;


• write entry in directory and block;


• write BAM (the table of which blocks on the disk are unoccupied);


• close channel and exit this routine.

Followed by a separate:

• get buffer number;


• write block.

The various selection parts between DB04 and DB20 just make a selection about which of those they start with. But all paths go through at least one 'write'; specifically:

• the last block and directory are skipped if you're involved in direct access, i.e. not performing file operations; and


• the get buffer number/write block path is taken, ignoring the directory and BAM, if you're dealing with a REL file, which are specially allocated to be contiguous so there's no further global bookkeeping once the thing exists.

So for non-REL files, failure to close may lead to the data at the end potentially being missing, and the directory and BAM not being updated.

For REL files, failure to close may lead to the particular section of the file you were working on not being updated.

Re: attempting to write to a file that isn't open, start at CFF1; that jumps to C1C8 if no such file is open, which does as you expect by heading off to E645 harmlessly to report an error.

Just based on the reading, I think you may be misunderstanding the sense of the warning.

You appear to think that the problem is with the disk system closing the files (because you have closed the error channel) and BASIC not knowing about it. I suspect in that case you probably would just get an error if you later tried to access them^(a).

However, the "danger" bit looks like it's the other sense, with BASIC erroring out (closing its files) but without having closed the files on the disk system. If you re-read the warning (my bold), that may be clearer:

NOTE: If your BASIC program leads you into an error condition, all files are CLOSED in BASIC, without CLOSEing them on your disk drive!

This, I'd hazard to guess, may be dangerous because the disk still has them open and it's unclear what would happen then if they were reopened by BASIC, or if they were cached and you powered down, or if the administrative information on the disk weren't updated, or possibly half a dozen other suspect scenarios I could come up with if I had the time and inclination :-)

That's why it's suggesting you execute that (rather arcane) sequence of commands, to safely re-initiliase the disk system and put it in a known state. And, before you go trying this, you should be aware that there's no file # 12 involved anywhere. The reset command is:

CLOSE 15: OPEN 15, 8, 15: CLOSE 15

^(a) Though I can't be sure, having never had the opportunity to even own a C64 - my babies were ZX80, TRS-80, Apple ][ and the very-little-known COMX-35. However, I'm considered reasonably good at decoding documentation, hence my answer.