15

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.

6

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.

  • 2
    Meta aside: I argued myself into this being worthy of posting as a separate answer since I took the time to locate and index the authoritative source material, even though it's just a heavily-referential way of getting to the same answer as paxdiablo has already posted, and which I had previously read. Maybe that's valid reasoning, maybe it's not. Please don't hesitate to tick as community wiki and/or merge into paxdiablo's work if anybody thinks there's even just a spirit-of-the-thing fair play violation here. – Tommy Nov 27 '18 at 20:15
  • 2
    Tommy, there's nothing the least bit borderline unacceptable about this answer. You have provided more info than I did about the WHY of why it might be bad to close improperly. Kudos for the extra effort. – user6464 Nov 27 '18 at 21:32
19

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.

  • 2
    That's exactly how I read those warnings. The disk-drive (and its "self-contained" OS) hasn't closed the files; bits you think you've written may still be in buffers (and, depending on what you do next, may never make it to disk). Reopening one of those "orphaned" files may carry on where you left off or may mix new writes with old, buffered writes in (effectively) unpredictable ways. As King Lear said: that way madness lies! – TripeHound Nov 26 '18 at 14:50
  • 1
    That being a reasonable guess, I'm not sure that failure to flush a buffer is necessarily a problem on the 1541 — with just 2kb to work with, it pretty much just transcodes data and writes it straight out. I'd dare imagine the more likely risk is failure to update catalogues and indexes? (EDIT: and the general disconnect between internal BASIC state and that which it has communicated to the device, I guess, since maybe your floppy drive isn't a 1541 and has some real buffering going on, but this question is re: the 1541 and its manual only) – Tommy Nov 26 '18 at 15:35
  • 1
    @Tommy The1541 uses 254 bytes of data per block on disk and only writes whole blocks, so there is buffering going on and there is a high probability of data in the last block being lost if the file isn't closed properly. At least for sequential files. Which is the majority of files. Of course not updating the block availibility map (BAM) on disk is also a problem as there may be blocks associated with a file but still marked as free in the BAM. Not updating the directory entry is a good thing, because there is a flag indicating not properly closed files, so the user can see there is a problem. – BlackJack Nov 27 '18 at 12:29
  • @BlackJack I feel like PRGs are the majority of files, but stand corrected otherwise. – Tommy Nov 27 '18 at 14:34
  • @Tommy With „sequential files“ I meant the structure from the DOS' point of view. There is no real difference between PRG and SEQ except the type info in the directory entry. – BlackJack Nov 27 '18 at 14:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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