eSXDOS compatibility
Spectranext provides an eSXDOS-compatible filesystem layer so that software written for the eSXDOS file API can use Spectranext mounts without being rewritten for the native VFS API. Existing TAP programs use their normal RST $08 eSXDOS calls; Spectranext translates the supported calls to the active VFS mount and returns eSXDOS-style results and errors.
This is a compatibility layer, not a NextZXOS replacement. It provides the file, directory, drive, and tape-input features that compatible software commonly needs, backed by XFS, TNFS, HTTPS, and other Spectranext filesystems where the underlying operation is available.
For the full eSXDOS and NextZXOS ABI, including functions that Spectranext does not currently implement, read the NextZXOS and eSXDOS APIs reference.
Using compatible software
From a user's point of view, no configuration is normally needed. Mount the desired filesystem and select its drive, then run a compatible TAP program. The program can open files, enumerate directories, read and write data, and change directories using its usual eSXDOS calls.
Mount points are presented as eSXDOS drives. The exact drive-to-mount mapping is maintained by the compatibility layer, so use the program's own drive-selection UI or eSXDOS drive calls rather than assuming that a particular drive letter always means a specific backend.
The filesystem determines the final behaviour. For example, a read-only mount cannot accept writes, an HTTPS mount may have no writable directory operations, and an XFS path may use the overlay filesystem rules.
Supported calls
The following eSXDOS calls are implemented. They use the eSXDOS API's normal call numbers, register conventions, carry-flag errors, handles, and drive selection semantics.
| Group | Supported calls | What they provide |
|---|---|---|
| Drive | M_GETSETDRV | Get or select the active drive/mount. |
| Tape | M_TAPEIN | Select a TAP file as the source for subsequent Spectrum tape loading. |
| File handles | F_OPEN, F_CLOSE, F_READ, F_WRITE, F_SEEK, F_FSTAT | Open, close, transfer data, position a file, and obtain metadata for an open handle. |
| Paths | F_STAT, F_UNLINK, F_RENAME, F_CHMOD | Inspect, delete, rename, and change supported attributes of a path. |
| Directories | F_OPENDIR, F_READDIR, F_TELLDIR, F_SEEKDIR, F_GETCWD, F_CHDIR, F_MKDIR, F_RMDIR | Enumerate directories, save and restore enumeration positions, and manage the current directory. |
| Capacity | F_GETFREE | Query available space on the selected mount. |
F_TELLDIR and F_SEEKDIR preserve the full four-byte directory cookie supplied by the backing filesystem. Programs must treat this value as opaque: save it unchanged and later pass it back, rather than treating it as a simple entry number.
Unsupported calls return the standard eSXDOS ENOSYS error. A supported call can still return another eSXDOS error when its filesystem cannot perform the requested operation.
File names, paths, and attributes
The compatibility layer accepts eSXDOS paths and maps them to the selected Spectranext mount. Older programs may impose their own 8.3 filename restrictions; that is a property of those programs, not of XFS or the VFS.
F_CHMOD is supported for filesystem attributes. On the local XFS overlay, the +a compatibility attribute commits a RAM-backed file or directory to flash. This maps to the XFS commit flag ($8000) and follows the commit rules. It is not a portable permission bit on remote or read-only mounts.
Tape input
M_TAPEIN selects a TAP file. After it succeeds, use the ordinary Spectrum LOAD command; the tape trap reads from the selected file. The file remains selected until it is replaced, closed by the relevant workflow, or the environment resets.
This feature is for TAP-backed loading. It does not make every tape format, snapshot format, or NextZXOS loader API available.
For programmers
Programs should follow the published eSXDOS register ABI, especially pointer-register conventions and carry-flag error handling. Normal TAP programs retain their eSXDOS compatibility while also being able to call Spectranext services through the native syscall jump table.
For new software, the native libspdos API is usually the better choice when portability to all Spectranext filesystems is the goal. eSXDOS compatibility is primarily there to run existing software unchanged.