CIO does not care about the size of a device specification; only that there is a buffer large enough to hold the device-spec, and that its length is properly passed to the CIOV call.

The various file management systems (FMS) present in different disk operating systems (DOS) are another matter, entirely. These differing FMSes impose their own unique limitations, and this discrepancy will become very important as a mapping scheme is implemented for file-level operations in the N: device.

1. The DUP throws a FILENAME TOO LONG error if this limit is breached.
2. A combination of explicit input length limiting and over-eager pre-pending of D1: before N: for any KCP operations make this DOS unsuitable for N: usage in the utility package. An external utility will be needed.
3. For Disk-based SpartaDOS, an implementation of XIO 40 will need to be added so that binary files can be loaded. This is because the binary loader is implemented in the FMS itself, and not the command processor.

To test a particular DOS:

1. Load DOS in Altirra
2. Go into the file management portion of DOS
3. Hit F8 to enable debugger.
4. In the debugger window, type .tracecio on Debugger should answer with affirmative message.
5. Hit F8 to resume the emulation.
6. Try any file operation, such as a BINARY LOAD, or a COPY, where you are offered to enter a filename.
7. Look in the debugger window for a GET RECORD operation from E:, this is an opportunity to get input, and write down the length. This will tell you how long the line can be.
8. Try various filenames, e.g. N:ABCDEFGH.IJK or N:ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890
9. The OS will return with an error 130. This is fine. Record the Filenames that come back in the debugger window in the corresponding OPEN call, and see how they match.
10. If the filenames become corrupted after a certain length, try to find the point at which behavior changes, by trying filenames of different lengths.
11. Once you have a definitive number, come back here and alter the table.