Difference between revisions of "File Formats"

From SpecNext official Wiki
Jump to: navigation, search
m (Added layer resolutions)
 
(16 intermediate revisions by 4 users not shown)
Line 1: Line 1:
The NextZXOS can read and load these kind of files: bas, tap, nex, z80, sna, snx, dot, o, p
+
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, .sna and .snx are Spectrum snapshots, more suitable as emulator compatibility than a real format
+
* '''[https://www.worldofspectrum.org/faq/reference/z80format.htm .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.
* .o is a ZX80 snapshot
+
* '''[https://faqwiki.zxnet.co.uk/wiki/SNA_format .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. Also the NextZXOS will reconfigure the machine based on the type of the SNA file, for example the {{PortNo|$7FFD}} memory banking is locked when 48K SNA file is loaded, etc.. (all of this can be reconfigured through Next registers to unlock/enable all features back, but the initial state is designed to provide maximum compatibility with legacy/original SW)
* .p is a ZX81 snapshot
+
* '''.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.
* [[NEX file format|.nex]] is good for a program that takes over the machine
+
* '''.o''' is a ZX80 snapshot
* .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)
+
* '''.p''' is a ZX81 snapshot
* [[TAP file format|.tap]] is a simple container format that can hold many files, is compatible with emulators and supported by many tools.
+
* '''[[NEX file format|.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 [[Emulators|CSpect]] emulator can open .nex files natively from the F2 dialog. esxDOS cannot open .nex files.
* .bas is the native SD-card format for BASIC programs (first 128 bytes of the file form standard +3DOS header).
+
* '''.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)
* .scr is used for a standard Spectrum screenshot created with ''SAVE "picture.scr" SCREEN$'' (256x192, 15 colours per character cell).  
+
* '''[[TAP file format|.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.
* .shc is used for a screenshot in Timex 8x1 Hi-colour mode (256x192, 15 colors).
+
* '''.bas''' is the native SD-card format for BASIC programs (first 128 bytes of the file form standard +3DOS header).
* .shr is used for a screenshot in Timex Hi-res mode (512x192, mono).
+
* .'''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.
* .slr is used for a lo-res screenshot (128x96, 256 colours).
+
* '''.shc''' is used for a screenshot in Timex 8x1 Hi-colour mode (256x192, 15 colors).
* .sl2 is used for a Layer 2 screenshot (256x192, 256 colour).
+
* '''.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) (when stored by NextBASIC, the binary content of file is: regular 128 bytes +3DOS header, then 256*192 bytes with pixel data, NO palette data = in total 49280 bytes).
 +
* '''.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 [[Miscellaneous#WASPtools|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, [https://github.com/stefanbylund/zxnext_bmp_tools zxnext_bmp_tools] and Jim Bagley's tools.
 +
 
 +
* '''.vid''' is the video format that is can be played back with .playvid. a .vid file can be either 320x240 16.7fps 15.6kHz / 256x240 16.7fps 31.1kHz / 256x192 25fps 23kHz.
 +
 
 +
The most notable of the other file formats is tzx. Although the browser recognises tzx files, they can only be loaded if you have a Raspberry Pi installed in your Next. See the [[FAQ]] for details.

Latest revision as of 21:22, 19 December 2023

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. Also the NextZXOS will reconfigure the machine based on the type of the SNA file, for example the Memory Paging Control ($7FFD / 32765) memory banking is locked when 48K SNA file is loaded, etc.. (all of this can be reconfigured through Next registers to unlock/enable all features back, but the initial state is designed to provide maximum compatibility with legacy/original SW)
  • .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) (when stored by NextBASIC, the binary content of file is: regular 128 bytes +3DOS header, then 256*192 bytes with pixel data, NO palette data = in total 49280 bytes).
  • .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.
  • .vid is the video format that is can be played back with .playvid. a .vid file can be either 320x240 16.7fps 15.6kHz / 256x240 16.7fps 31.1kHz / 256x192 25fps 23kHz.

The most notable of the other file formats is tzx. Although the browser recognises tzx files, they can only be loaded if you have a Raspberry Pi installed in your Next. See the FAQ for details.