RDISK() for properties of the most recent disk operation

[dansanderson]

BASIC has two ways to inquire about the status of the last disk operation: ST for read status flags (end of file), and DS/DS$ for reporting disk errors. A few other properties would be useful.

This issue proposes a new RDISK(<id>) function that takes a property ID and returns a value about the most recent disk operation performed by one of these commands: LOAD, DLOAD, BLOAD, SAVE, DSAVE, BSAVE, BVERIFY, VERIFY, FREAD#, FWRITE#, GET#, INPUT#, LINE INPUT#, PRINT#

• 0 = The number of bytes read or written by the command, up to 65,535 (two bytes)
• 1 = The most recent unit number used (one byte)
• 2 = The most recent drive number used (of a multi-drive IEC device) (one bytes)

Option 0 would allow a BASIC program to perform an operation such as BLOAD, and determine the ending address of the loaded data programmatically. Right now, this information is not available to BASIC. (It is printed to the terminal in direct mode, but not stored.)

Options 1 and 2 would allow a BASIC program to open files from the same drive unit from which it was loaded, even if it wasn't the SET DEF default drive. This is currently available via the GETLFS KERNAL call; this would be a convenience accessor.

These properties are overwritten by the next relevant command, and set to 0 if the command is unsuccessful. If a program wants to keep track of the number of bytes read in total over a session, such as via FREAD# or GET#, it must call RDISK() after each operation and maintain a total in a variable.

Alternatives considered
It'd be even more powerful to offer each of these properties separately for every logical channel, reset on channel open: RDISK(<chan>, <id>) However, this would require remembering quite a bit of information for a rarely used feature. Additional mechanisms to allocate this memory optionally in BASIC variable space might be ok, but would add complexity without adding much utility.

ST and DS are best left the way they are. They could be duplicated on RDISK() indexes, but I don't see the need.

In general, a program is expected to already have access to properties given to these commands as input, e.g. the filename. Options 1 and 2 are available solely to read the values used outside of the context of the program, i.e. by the command that loaded the program. There is no reason to store and expose other properties that are otherwise inputs to these commands.