File Formats

NextZXOS can directly read and load these kind of files: bas, tap, z80, sna, snx, dot, o, p. Many other file types are supported by the use of external dot commands.

• .z80 is a Spectrum snapshot file, more suitable as emulator compatibility than a real format. Files can be loaded using the NextZXOS browser, the NextZXOS SPECTRUM keyword, the esxDOS NMI menu, and the exDOS .snapload command.
• .sna is a Spectrum snapshot file, more suitable as emulator compatibility than a real format. Both 48K and 128K SNA files are supported. Files can be loaded using the NextZXOS browser, the NextZXOS SPECTRUM keyword, the esxDOS NMI menu, and the exDOS .snapload command. When loading in NextZXOS, any private data appended to the file is ignored during loading, and the program code may later read it by reopening itself using a hardcoded filename. If private data is appended to them then they cannot be loaded by esxDOS.
• .snx is a Spectrum snapshot file, more suitable as emulator compatibility than a real format. It is identical to a 128K .sna file, but when loaded using the browser or the SPECTRUM command, NextZXOS leaves file handle 0 open for further use by the program. The program is expected close the handle before exiting. .snx files may also have private data appended to them. They are not supported by esxDOS.
• .o is a ZX80 snapshot
• .p is a ZX81 snapshot
• .nex is good for a program that takes over the machine. With some care, it can also be used to load a program without overwriting sysvars, allowing NextZXOS API calls to be used. It can be loaded using the NextZXOS file browser and the .nexload dot command. The CSpect emulator can open .nex files natively from the F2 dialog. esxDOS cannot open .nex files.
• .dot is good for dot commands and programs that can coexist with BASIC/NextZXOS and can return to BASIC safely (i.e. counterpart to nex)
• .tap is a simple container format that can hold many files, is compatible with emulators and supported by many tools. When loading .tap files using the NextZXOS browser, a menu is displayed asking whether you want to load in standard, USR0 or 48K mode.
• .bas is the native SD-card format for BASIC programs (first 128 bytes of the file form standard +3DOS header).
• .scr is used for a standard Spectrum screenshot created with SAVE "picture.scr" SCREEN$ (256x192, 15 colours per character cell). Note that if saved from BASIC, .scr files will have a 128 byte +3DOS header (7,040 bytes), but .scr files created in external PC tools may not have a +3DOS header (6,912 bytes). The NextZXOS browser and the BASIC LOAD statement can cope with both headered and headerless .scr files.
• .shc is used for a screenshot in Timex 8x1 Hi-colour mode (256x192, 15 colors).
• .shr is used for a screenshot in Timex Hi-res mode (512x192, mono).
• .slr is used for a lo-res screenshot (128x96, 256 colours).
• .sl2 is used for a Layer 2 screenshot (256x192, 256 colour).
• .pal is a 9-bit palette format (256 pairs of bytes in %RRRGGGBB, %P000000B format). Files can be loaded and saved from the Screenshots menu in NextZXOS after pressing the M1 button or F9. The P bit sets priority when used in layer 2 palettes. Palette entries with P=1 cause their pixels to appear above everything else, regardless of globally-set layer priorities.
• .npl is a 9-bit palette format. The first 512 bytes are identical to a .pal file. The 513th byte designates transparency - for sprite palettes, the transparency byte is a real index, and for other palettes it is a colour mask. .npl files can be created, saved and loaded by WASPtools.
• .nxi is layer 2 screen format, with optional palette. If the file size is 49,152 bytes, the file contains 256x192 pixels of layer 2 data, indexed with palette values. This is essentially a memory dump of the six sequential layer 2 MMU banks. If the size is 49,664 bytes, the pixel data is prepended with 512 bytes of palette data (256 pairs of bytes in %RRRGGGBB, %P000000B format). .nxi files can be processed by PLOTIT, Dnext, zxnext_bmp_tools and Jim Bagley's tools.