LIF: The Logical Interchange Format This file describes the LIF media format, and the LIF file formats and types used by the -41*, -71B, and -75* (*=series) products. Numbers in this file are in decimal except where otherwise indicated. Hexadecimal numbers are indicated by a prefix of 0x. MEDIA TYPES Any media can be used for LIF. Three are known: - Cassette tape - 9114 diskette (3 1/2") - Steinmetz & Brown disk drive (5 1/4", 40 tracks / disk, 2 heads/track, 9 sectors/track) The block size is fixed at 256 bytes. (The S&B disk drive stored two blocks per 512 byte sector.) All multi-byte data items are stored most significant byte first ("big endian"). This is the same as the byte ordering used by M68000 processors and reversed from that used by Intel 8086 processors. MEDIA FORMAT A LIF volume is laid out in four parts: - A header is stored in block 0. It is always exactly one block long. - Block one is an unused filler block and must be zeros (presumably for header expansion). - The directory is stored starting in block 2. A field in the header indicates how many records the directory occupies. - The files themselves follow the directory, starting in block 2 + directory length. Each file is allocated a maximum length and occupies a continguous set of blocks. The files must be stored in the same order that their directory entries are in. However, unused blocks may appear anywhere between files and unused directory entries may appear anywhere in a directory. (You may, for example, have an unused directory entry yet have no space between the files.) HEADER RECORD starting length offset in bytes what 0 2 LIF identifier, must be 0x8000 2 6 volume label 8 4 directory start block, must be 2 12 2 LIF identifer for System 3000 machines, must be 0x1000 14 2 filler, must be zero 16 4 length of directory in blocks 20 2 LIF version number, must be 1 22 2 filler, must be zero 24 4 number of tracks per surface 28 4 number of surfaces 32 4 number of blocks per track 36 6 date and time that the volume was initialized[*] 40 216 filler, must be zero [*] Date and time fields are in the format: year - 1900 month day of month hour (0-23) minute second with each value occupying one byte and stored in BCD. DIRECTORY STRUCTURE A directory consists of a sequence of 32-byte entries. There are thus 8 entries per block. The total number of files that can be stored is thus fixed at volume initialization time to 8 * the number of directory blocks. A typical value is 768 files. Each entry is in this format: starting length offset in bytes what 0 10 file name (lower case mapped to upper, padded with trailing spaces) 10 2 file type 12 4 start block 16 4 allocated length in blocks[*] 20 6 date and time that the file was created 26 6 miscellaneous data[*] [*] The method to determine the actual file length and the interpretation of the miscellaneous data both vary depending on the file type. SECURE AND PRIVATE FILES Many LIF files can be made secure and/or private. A "secure" file is protected from modification, either by changing (writing to or appending to) or deleting. Making a file secure is reversible. A "private" file cannot be read from: it can only be executed. If not secure, it can be written to, but the values written cannot be read back. Privacy is not reversible: once a file has been made private, it must remain that way. FILE TYPES Attribute codes: exe the file is executable pri the file can be made private sec the file can be made secure or unsecure ========== General File Types ========== type attributes description 0x0000 purged (deleted) file 0x0001 sec standard LIF text file: -41* AS, -71B text, -75* LIF1 0xE0D0 sec "standard" data file: -41* DA, -71B SDATA stream data 0xE0D5 sec secure LIF text 0xFFFF marks the last file used in a directory For file type 0xE0D0: The miscellaneous data field contains these values: 0 unused 1 unused 2 high byte of (length of file in 8-byte registers) 3 low byte of (length of file in 8-byte registers) 4 bits 2^0 to 2^6 unused bit 2^7 set if file is secure 5 unused, must be zero For file type 0x0001: These files are made secure by changing the type to 0xE0D5. Formats: 0x0001 These files are a sequence of lines, with each line of the form: byte 0 high byte of (length of line in bytes) byte 1 low byte of (length of line in bytes) byte 2...n text bytes If the length of the line is odd, a NUL byte is appended to the bytes 2...n but not the length. For example, to write out the lines "abcd" and "efg", the following bytes are written: decimal char 0 ^@ 4 ^D 97 a 98 b 99 c 100 d 0 ^@ 3 ^C 101 e 102 f 103 g 0 <pad> A line length of 0xFFFF signals the end of the file. 0xE0D0 array of 8-byte registers; each register is in -71B format, however -41*-type strings work ========== -41* File Types ========== type attributes description 0xE020 sec whole calculator including XMEM (HOSER ROM) 0xE030 sec extended memory (HOSER ROM) 0xE040 sec all of calculator 0xE050 sec user keyboard 0xE060 sec calculator status 0xE070 exe sec ROM file 0xE080 exe pri sec FOCAL program[*] 0xE0B0 sec buffer (HOSER ROM) For all of these files: - The miscellaneous data field contains these values: 0 unused 1 unused 2 high byte of (length of file in 8-byte registers - 1) 3 low byte of (length of file in 8-byte registers - 1) 4 bit 2^0 set if file is private bits 2^1 to 2^6 unused bit 2^7 set if file is secure 5 unused, must be zero [*] For these files, the length in bytes 2 and 3 is the length in bytes - 1, not registers. Formats: 0xE020 array of 7-byte registers 0xE030 array of 7-byte registers 0xE040 array of 7-byte registers 0xE050 array of 7-byte registers (keyboard definition registers only) 0xE060 array of 7-byte registers (status registers only) 0xE070 array of 10-bit words? 0xE080 see your favorite hex table 0xE0B0 array of 7-byte registers ========== -71B File Types ========== type attributes description 0xE214 exe pri sec Basic program 0xE215 exe pri sec secure Basic program 0xE216 exe pri sec private Basic program 0xE217 exe pri sec secure & private Basic program 0xE204 exe pri sec binary file (ROM image?) 0xE205 exe pri sec secure binary file 0xE206 exe pri sec private binary file 0xE207 exe pri sec secure & private binary file 0xE0F0 sec data file[*] 0xE0F1 sec secure data file[*] 0xE20C sec keyboard definition 0xE20D sec secure keyboard definition 0xE208 exe pri sec language extension 0xE209 exe pri sec secure language extension 0xE20A exe pri sec private language extension 0xE20B exe pri sec secure & private LEX For all of these files: - The files are made private or secure by changing the file type: - add one to the type to make it secure - add two to the type to make it private - add three to the type to make it both secure and private - The miscellaneous data field contains these values: 0 unused 1 unused 2 high byte of (length of file in nybbles) 3 middle byte of (length of file in nybbles) 4 low byte of (length of file in nybbles) 5 unused, must be zero except for the files marked with [*]. For those files, the miscellaneous data field contains these values: 0 unused 1 unused 2 high byte of (length of file in records) 3 low byte of (length of file in records) 4 high byte of (length of record in bytes) 5 low byte of (length of record in bytes) Formats: 0xE214 don't know this format 0xE204 array of nybble ? 0xE0F0 These files are organized into records. The record size is fixed within a file, but may vary from file to file and is given in the header. If a data item does not fit in a record, the record is padded with 0xEF bytes and the data item starts on a new record. However, the last record is padded with 0xFF bytes instead of 0xEF. The documentation indicates that 0xFF should always be and EOF. However, the -71B didn't read the documentation and doesn't agree. So on input treat both 0xFF and 0xEF as the same. Real numbers are exactly 8 byte long and are encoded in -71B internal format. These numbers include NaN's, etc. Strings and are encoded in this form: byte 0 [*] byte 1 low byte of (length of string in bytes) byte 2 high byte of (length of string in bytes) byte 3..n text data [*] If the entire string fits within a record, it is encoded as: byte 0 0xDF entire string ... <from above> If the string does not completely fit within a record, it is encoded as: byte 0 0xCF start of string ... <from above> byte 0 0x7F middle of string (0 or more times) ... <from above> byte 0 0x6F end of string ... <from above> 0xE20C don't know this format 0xE208 array of nybble ? ========== -75* File Types ========== Keyboard definitions are stored as LIF (not 75) text files. type attributes description 0xE051 exe pri ROM file 0xE052 pri text file 0xE053 pri appointment file 0xE088 exe pri Basic file[*] 0xE089 exe pri language extension 0xE08A pri VisiCalc worksheet file [*] Data files are stored as Basic programs consisting only of DATA statements. For all of these files: - There is no way to determine the actual file length from the header alone: you must parse the file. - The miscellaneous data field contains these values: 0 0x80 1 0x01 2 password char 1 3 password char 2 4 password char 3 5 password char 4 - All of these files can be made private by use of passwords. Passwords are four characters long and are stored in bytes 2-5 of the miscellaneous data field. A password of four space characters means that the file is not private. Formats: -75* files share a common header: starting length offset in bytes what 0 2 pointer to the next directory entry 2 2 file length in bytes - 18 4 1 file type 5 1 file id letter 6 4 date/time created 10 8 file name (space characters on disk) 18 10 ?? (NUL characters on disk) Also, all -75* files look a lot like tokenized Basic programs. 0xE051 array of byte? 0xE052 In these files, the file type of a text file is 0xBE and the file id letter is 0x54 ('T'). These files are a sequence of lines, with each line of the form: byte 0 low byte of (line number in BCD) byte 1 low byte of (line number in BCD) byte 2 number of characters in line + 1 byte 3 space character (decimal 32) bytes 4..n text bytes For example, line 1234 with the text "abc" would look like: decimal char 52 4 (0x34) 18 ^R (0x12) 4 ^D 32 97 a 98 b 99 c The maximum line length is 126 characters. The end of the file is indicated by an illegally-high line number of: 0x99 0xA9 0x02 the threee bytes starting here may not be required 0x8A 0x0E 0xE053 don't know this format 0xE088 (This document describes DATA files only.) In these files, the file type of a data file is the same as that of a Basic file, 0xFE and the file id letter is 0x42 ('B'). These files are a sequence of lines, with each line of the form: byte 0 low byte of (line number in BCD) byte 1 low byte of (line number in BCD) byte 2 length of rest of record in bytes + 1 Real numbers have a length of 11 and are encoded in this form: byte 0 0x86 byte 1 0x04 bytes 2..9 number in -71B format byte 10 0x0E Integers have a length of 6 are are encoded in this form: byte 0 0x86 byte 1 0x1A byte 2 low two digits of number in BCD byte 3 middle two digits of number in BCD byte 4 high two digits of number in BCD Integers may be in the range -99999 to 99999. Positive numbers are stored as themselves. Negative numbers are stored as 1,000,000 - the absolute value of the number. Strings have a length of 4 + the number of characters in the string and are encoded in this form: byte 0 0x86 byte 1 0x05 or, "-ed string constant byte 1 0x06 or, unquoted string constant byte 1 0x96 '-ed string constant byte 2 number of characters in the string bytes 3...n-1 text bytes byte n 0x0E The maximum string length is 251 bytes. NaN's have a length of 11 and are encoded in this form: byte 0 0x86 byte 1 0x04 byte 2 0x11 byte 3 0xF0 bytes 4..9 0x00 byte 10 0x0E The end of the file is indicated by an illegally-high line number of: 0x99 0xA9 0x02 0x8A END statement 0x0E 0xE089 array of byte? 0xE08A standard VisiCalc?
Last modified Saturday, 2012-02-25T17:30:09-06:00.