chysn wrote:By opening a "command channel," I think you're talking about calling TALK and TALKSA. By opening a "file channel," I think you mean opening a file with SETLFS and OPEN. Is that right?
Not quite. The command channel is accessed by opening a file with secondary address 15 on the drive. This can be done both via the high level KERNAL API (OPEN, CHROUT, CHRIN, CLOSE) or the low level IEC calls (TALK and TALKSA being examples of those). In the latter case, there exists not necessarily an entry in the list of open files in the $02xx area.
All other secondary addresses involve data transfer to or from files or buffers, for simplicity I called them "file channels" here to distinct them from the command channel.
If so, I'm finding that the file channel must be open first, or the command channel always reports a syntax error, [...]
A syntax error as report on the command channel is mostly the result of a malformed (or unknown) command. As I wrote, you would normally open the command channel first as an action in a program that involves disk drive access.
[...] and commands don't get run. Also, the file channel must be closed first, or the status string is inaccurate.
You can read out the status from the command channel at any time, not only when the file channel(s) is/are closed. Of course the successful operation on a complete file can only be asserted upon file close. But you can also get the information from the drive, during file write, that the disk is nearly full - while the file is open, CBM DOS then sends a "72,DISK FULL,00,00" to indicate that only two blocks are free and left to fill up the whole disk, which is still sufficient to close the file regularily without incurring a splat file (marked with "*"). Whether that incomplete file is of any use, is another matter.
Again, the command channel should be closed last, as
on the drive all other regular file channels will be closed alongside it. The KERNAL will not notice this situation, and any subsequent data transfer regarding these files will go into the void.
You can go like this to 'supervise' the whole activity of the drive during file operations - the example below first deletes a file with given name and then writes a new file under the same name, and finally reads it back again.
Code: Select all
10 N$="TEST"
11 PRINT"OPEN CMD CHANNEL":OPEN15,8,15:GOSUB25:PRINTDS$:IFNOT(DS=0 OR DS=73)THEN23
12 PRINT"DELETE FILE":PRINT#15,"S0:"+N$:GOSUB25:PRINTDS$:IFDS<>1THEN23
13 PRINT"OPEN FILE FOR WRITE":OPEN2,8,2,N$+",S,W":GOSUB25:PRINTDS$:IFDS<>0THEN22
14 FORT=1TO100
15 PRINT#2,"LINE"+STR$(T):GOSUB25:PRINT DS$:IFDS<>0THEN22
16 NEXT
17 PRINT"CLOSE FILE":CLOSE2:GOSUB25:PRINT DS$:IFDS<>0THEN22
18 PRINT"OPEN FILE FOR READ":OPEN2,8,2,N$+",S,R":GOSUB25:PRINT DS$:IFDS<>0THEN22
19 FORT=1TO100
20 INPUT#2,A$:PRINTA$:GOSUB25:IFDS<>0THENPRINT DS$:GOTO22
21 NEXT
22 PRINT"CLOSE FILE":CLOSE2:GOSUB25:PRINT DS$
23 PRINT"CLOSE CMD CHANNEL":CLOSE15:END
24 :
25 DS$="":FORP=-1TO0:GET#15,A$:DS$=DS$+A$:P=ST=0:NEXT:DS=VAL(DS$):RETURN
During file re-read, the status channel is only printed when there is an error. The scratch command normally returns with "01,..." which itself does not constitute an error but is merely informatory. Upon anything else than 0, 1 (for scratch) or 73 (possible CBM DOS startup message upon OPEN ...,15), the program terminates by jumping forward to either line 22 or 23.
As you see, properly checking the disk status incurs quite some code overhead. Many people just don't bother.
P.S. please note "CD:xxx" is not a regular CBM DOS command. It is a CMD extension supported by their harddisks, VICE VDrive and SD2IECs, but does not work on "regular" CBM DOS drives (or with
TDE on in VICE).
