Other Files =========== .DAT Data files used by level-loader versions of a game (Z80Em does not use a .DAT extension at all; instead files are just numbered, e.g. "1" instead of "GAME1.DAT"). .DCK Used by Warajevo for Timex memory expansions. .MDR Microdrive cartridge file as used by Z80 and xzx v2 amongst others. .NET Used by Warajevo for the Interface I Network. .OUT OUT logs from Z80. .POK Poke files used by the Spectrum Games Database. .SCR Screendumps from Z80, WSpecEm and others. .ROM ROM images. [NEW] .DCK (Warajevo) --------------------- DCK files keeps information about memory content of various Timex memory expansions, and information about which chunks of extra memory are RAM chunks and which chunks are ROM chunks. Such files have relatively simple format. At the beginning of a DCK file, a nine-byte header is located. First byte is the bank ID which has the following meaning: 0: DOCK bank (the most frequent variant) 1-253: Reserved for expansions which allow more than three 64 Kb banks (currently not implemented) 254: EXROM bank (using this ID you may insert RAM or ROM chunks into EXROM bank; such hardware exists for the real TS2068) 255: HOME bank (mainly useless, HOME content is typically stored in a Z80 file); however, using this bank ID you may replace content of Timex HOME ROM, or turn Timex HOME ROM into RAM This numbering of banks is in according to convention used in various routines from the TS2068 ROM. After the first byte, the following eight bytes corresponds to eight 8K chunks in the bank. Organization of each byte is as follows: bit D0: 0 = read-only chunk, 1 = read/write chunk bit D1: 0 = memory image for corresponding chunk is not present in DCK file, 1 = memory image is present in DCK file bits D2-D7: reserved (all zeros) To be more precise, these bytes will have the following values: * 0, for non-existent chunks (reading from such chunks must return default values for given bank; for example, #FF in DOCK bank, and ghost images of 8K Timex EXROM in EXROM bank). * 1, for RAM chunks, where initial RAM content is not given (in Warajevo, such chunks will be initially filled with zeros) * 2, for ROM chunks * 3, for RAM chunks where initial RAM content is given (this is need to allow saving content of expanded RAM; also this is useful for emulating non-volatile battery-protected RAM expansions). After the header, a pure binary image of each chunk is stored in DCK file. That's all if only one bank is stored in DCK file. Else, after the memory image, a new 9-byte header for next bank follows, and so on. [UPDATED] .MDR (Z80, xzx v2, others) [from Z80 documentation] ------------------------------------------------------------- The following information is adapted from Carlo's documentation. It can also be found in the 'Spectrum Microdrive Book', by Ian Logan (co-writer of the excellent 'Complete Spectrum ROM Disassembly'). A cartridge file contains 254 'sectors' of 543 bytes each, and a final byte flag which is non-zero if the cartridge is write protected, so the total length is 137923 bytes. On the cartridge tape, after a GAP of some time the Interface I writes 10 zeros and 2 FF bytes (the preamble), and then a fifteen byte header-block-with-checksum. After another GAP, it writes a preamble again, with a 15-byte record-descriptor-with-checksum (which has a structure very much like the header block), immediately followed by the data block of 512 bytes, and a final checksum of those 512 bytes. The preamble is used by the Interface I hardware to synchronise, and is not explicitly used by the software. The preamble is not saved to the microdrive file: Offset Length Name Contents ------------------------------ 0 1 HDFLAG Value 1, to indicate header block 1 1 HDNUMB sector number (values 254 down to 1) 2 2 not used 4 10 HDNAME microdrive cartridge name (blank padded) 14 1 HDCHK header checksum (of first 14 bytes) 15 1 RECFLG - bit 0: always 0 to indicate record block - bit 1: set for the EOF block - bit 2: reset for a PRINT file - bits 3-7: not used (value 0) 16 1 RECNUM data block sequence number (value starts at 0) 17 2 RECLEN data block length (<=512, LSB first) 19 10 RECNAM filename (blank padded) 29 1 DESCHK record descriptor checksum (of previous 14 bytes) 30 512 data block 542 1 DCHK data block checksum (of all 512 bytes of data block, even when not all bytes are used) --------- 254 times (Actually, this information is 'transparent' to the emulator. All it does is store 2 times 254 blocks in the .MDR file as it is OUTed, alternatingly of length 15 and 528 bytes. The emulator does check checksums, see below; the other fields are dealt with by the emulated Interface I software.) A used record block is either an EOF block (bit 1 of RECFLG is 1) or contains 512 bytes of data (RECLEN=512, i.e. bit 1 of MSB is 1). An empty record block has a zero in bit 1 of RECFLG and also RECLEN=0. An unusable block (as determined by the FORMAT command) is an EOF block with RECLEN=0. The three checksums are calculated by adding all the bytes together modulo 255; this will never produce a checksum of 255. Possibly, this is the value that is read by the Interface I if there's no or bad data on the tape. In normal operation, all first-fifteen-byte blocks of each header or record block will have the right checksum. If the checksum is not right, the block will be treated as a GAP. For instance, if you type OUT 239,0 on a normal Spectrum with interface I, the microdrive motor starts running and the cartridge will be erased completely in 7 seconds. CAT 1 will respond with 'microdrive not ready'. Try it on the emulator... Warajevo uses basically the same format, but ignores the `read-only' final byte (it obtains this information from the file attributes), and also the files do not have to contain all 254 sectors. [NEW] .NET (Warajevo) --------------------- .NET files are used by Warajevo to emulate the Interface I Network, which allowed up to 8 different Spectrums to talk to each other. The format of the network files is very simple. They have 260 bytes (or more, but excess bytes will not be used), with following structure: Byte Length Description 0 2 Package ID (used for fast checking whether content of the Net file is changed) 2 2 Reserved; not yet used 4 256 Content of the package [NEW] .PAL (Warajevo) --------------------- The WARAJEVO.PAL file is used by Warajevo to set its colour palette. They have a very simple 48-byte format: the first three bytes correspond to R, G and B value for color 0, next three bytes correspond to RGB for color 1, etc; the first 24 bytes are related to BRIGHT 0 colors, and next 24 bytes are related to BRIGHT 1. All values must be in the range 0-63. [NEW] .POK (Spectrum Games Database, Sinclair Spectrum Emulator) ---------------------------------------------------------------- [From Martijn van der Heide] The .POK file format is a proprietary format designed for use with SGD (from version 1.20) and was originally used to POKE snapshots prior to launching an emulator to play the specific game. This mechanism works on snapshots only. Each trainer contains one or more POKEs (sometimes a game check needs more than one poke to acquire a result). All trainers for a game are written after each other. The first character in a line of the file determines the content of the line. 'N' means: this is the Next trainer, 'Y' means: this is the last line of the file (the rest of the file is ignored). After the 'N' follows the name/description of this specific trainer. This string may be up to 30 characters. There is no space between the 'N' and the string. The following lines, up to the next 'N' or 'Z' hold the POKEs to be applied for this specific trainer. Again, the first character determines the content. 'M' means: this is not the last POKE (More) 'Z' means: this is the last POKE The POKE line has the format: lbbb aaaaa vvv ooo Where l determines the content, bbb is the bank, aaaaa is the address to be poked with value vvv and ooo is the original value of aaaaa. All values are decimal, and separated by one or more spaces, apart from between l and bbb; however, the bank value is never larger than 8, so you will always see 2 spaces in front of the bank. The field bank field is built from bit 0-2 : bank value 3 : ignore bank (1=yes, always set for 48K games) If the field is in range 0-255, this is the value to be POKEd. If it is 256, a requester should pop up where the user can enter a value. The 'original' field holds the original value at the address. It is used to remove a POKE. Normally, when applying a POKE, the original value can be read from the address. Sometimes however, games as found on the internet are already POKEd, so the original value can not be read. If this field is filled in (non-0) you still have the possibility to remove the trainer. (This format cannot handle the possibility that the original value was 0). .SCR (Z80, WSpecEm, others) --------------------------- These files are just Spectrum screen dumps, and are simply the 6912 bytes of pixel and attribute data found at address 16384, stored on disk in exactly the same way as they are stored in memory. To elaborate; the Spectrum screen is split into four areas; top third, mid third, bottom third and attributes (colours). The thirds each consist of 2048 bytes and the attribute area is 768 bytes (32 characters wide x 24 lines). So the first 6144 bytes are the actual pixel data and the remainder decides what two colours are used in each 8x8 square. Each third of the screen is laid out unusually; the first 32 bytes are the pixels for the top row of the first character line, then the next 32 bytes are the pixels for the top row of the second character line and so on until you reach the ninth load of 32 bytes, which is the second row of the first character line. Next 32 bytes is the second row of the second character line, and so on. It's hard to explain, so the best thing to do is see for yourself; write a program to POKE data to 16384 up and see how the bytes fill in on the screen. .ROM [contributed by J.G.Harston] --------------------------------- &4000 bytes long, loaded into the Spectrum's memory map at &0000 to &3FFF.