Movatterモバイル変換


[0]ホーム

URL:


 
 

lif

 LIF: The Logical Interchange FormatThis file describes the LIF media format, and the LIF file formats andtypes 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 TYPESAny 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, 2heads/track, 9 sectors/track)The block size is fixed at 256 bytes.  (The S&B disk drive stored twoblocks per 512 byte sector.)All multi-byte data items are stored most significant byte first ("bigendian").  This is the same as the byte ordering used by M68000processors and reversed from that used by Intel 8086 processors.MEDIA FORMATA 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 (presumablyfor header expansion).- The directory is stored starting in block 2.  A field in the headerindicates 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 setof blocks.  The files must be stored in the same order that theirdirectory entries are in.  However, unused blocks may appear anywherebetween files and unused directory entries may appear anywhere in adirectory.  (You may, for example, have an unused directory entry yethave no space between the files.)HEADER RECORDstartinglengthoffsetin byteswhat02LIF identifier, must be 0x800026volume label84directory start block, must be 2122LIF identifer for System 3000 machines, must be 0x1000142filler, must be zero164length of directory in blocks202LIF version number, must be 1222filler, must be zero244number of tracks per surface284number of surfaces324number of blocks per track366date and time that the volume was initialized[*]40216filler, must be zero[*] Date and time fields are in the format:year - 1900monthday of monthhour (0-23)minutesecondwith each value occupying one byte and stored in BCD.DIRECTORY STRUCTUREA directory consists of a sequence of 32-byte entries.  There are thus8 entries per block.  The total number of files that can be stored isthus fixed at volume initialization time to 8 * the number ofdirectory blocks.  A typical value is 768 files.Each entry is in this format:startinglengthoffsetin byteswhat010file name (lower case mapped to upper,padded with trailing spaces)102file type124start block164allocated length in blocks[*]206date and time that the file was created266miscellaneous data[*][*] The method to determine the actual file length and theinterpretation of the miscellaneous data both vary depending on thefile type.SECURE AND PRIVATE FILESMany 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 isreversible.A "private" file cannot be read from: it can only be executed.  If notsecure, it can be written to, but the values written cannot be readback.  Privacy is not reversible: once a file has been made private,it must remain that way.FILE TYPESAttribute codes:exethe file is executableprithe file can be made privatesecthe file can be made secure or unsecure========== General File Types ==========typeattributesdescription0x0000purged (deleted) file0x0001secstandard LIF text file: -41* AS, -71B text, -75* LIF10xE0D0sec"standard" data file: -41* DA, -71B SDATA stream data0xE0D5secsecure LIF text0xFFFFmarks the last file used in a directoryFor file type 0xE0D0: The miscellaneous data field contains thesevalues:0unused1unused2high byte of (length of file in 8-byte registers)3low byte of (length of file in 8-byte registers)4bits 2^0 to 2^6unusedbit 2^7set if file is secure5unused, must be zeroFor file type 0x0001: These files are made secure by changing the typeto 0xE0D5.Formats:0x0001These files are a sequence of lines, with each line of the form:byte 0high byte of (length of line in bytes)byte 1low byte of (length of line in bytes)byte 2...ntext bytesIf the length of the line is odd, a NUL byte is appended tothe bytes 2...n but not the length.  For example, to write outthe lines "abcd" and "efg", the following bytes are written:decimalchar0^@4^D97a98b99c100d0^@3^C101e102f103g0<pad>A line length of 0xFFFF signals the end of the file.0xE0D0array of 8-byte registers; each register is in -71B format,however -41*-type strings work========== -41* File Types ==========typeattributesdescription0xE020secwhole calculator including XMEM (HOSER ROM)0xE030secextended memory (HOSER ROM)0xE040secall of calculator0xE050secuser keyboard0xE060seccalculator status0xE070exe secROM file0xE080exe pri secFOCAL program[*]0xE0B0secbuffer (HOSER ROM)For all of these files:- The miscellaneous data field contains these values:0unused1unused2high byte of (length of file in 8-byte registers - 1)3low byte of (length of file in 8-byte registers - 1)4bit 2^0set if file is privatebits 2^1 to 2^6unusedbit 2^7set if file is secure5unused, must be zero[*] For these files, the length in bytes 2 and 3 is the length inbytes - 1, not registers.Formats:0xE020array of 7-byte registers0xE030array of 7-byte registers0xE040array of 7-byte registers0xE050array of 7-byte registers (keyboard definition registers only)0xE060array of 7-byte registers (status registers only)0xE070array of 10-bit words?0xE080see your favorite hex table0xE0B0array of 7-byte registers========== -71B File Types ==========typeattributesdescription0xE214exe pri secBasic program0xE215exe pri secsecure Basic program0xE216exe pri secprivate Basic program0xE217exe pri secsecure & private Basic program0xE204exe pri secbinary file (ROM image?)0xE205exe pri secsecure binary file0xE206exe pri secprivate binary file0xE207exe pri secsecure & private binary file0xE0F0secdata file[*]0xE0F1secsecure data file[*]0xE20Cseckeyboard definition0xE20Dsecsecure keyboard definition0xE208exe pri seclanguage extension0xE209exe pri secsecure language extension0xE20Aexe pri secprivate language extension0xE20Bexe pri secsecure & private LEXFor 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:0unused1unused2high byte of (length of file in nybbles)3middle byte of (length of file in nybbles)4low byte of (length of file in nybbles)5unused, must be zeroexcept for the files marked with [*].  For those files, themiscellaneous data field contains these values:0unused1unused2high byte of (length of file in records)3low byte of (length of file in records)4high byte of (length of record in bytes)5low byte of (length of record in bytes)Formats:0xE214don't know this format0xE204array of nybble ?0xE0F0These files are organized into records.  The record size isfixed within a file, but may vary from file to file and isgiven in the header.  If a data item does not fit in a record,the record is padded with 0xEF bytes and the data item startson a new record.  However, the last record is padded with 0xFFbytes instead of 0xEF.The documentation indicates that 0xFF should always be andEOF.  However, the -71B didn't read the documentation anddoesn't agree.  So on input treat both 0xFF and 0xEF as the same.Real numbers are exactly 8 byte long and are encoded in -71Binternal format.  These numbers include NaN's, etc.Strings and are encoded in this form:byte 0[*]byte 1low byte of (length of string in bytes)byte 2high byte of (length of string in bytes)byte 3..ntext data[*] If the entire string fits within a record, it is encoded as:byte 00xDFentire string...<from above>If the string does not completely fit within a record, it isencoded as:byte 00xCFstart of string...<from above>byte 00x7Fmiddle of string (0 or more times)...<from above>byte 00x6Fend of string...<from above>0xE20Cdon't know this format0xE208array of nybble ?========== -75* File Types ==========Keyboard definitions are stored as LIF (not 75) text files.typeattributesdescription0xE051exe priROM file0xE052pritext file0xE053priappointment file0xE088exe priBasic file[*]0xE089exe prilanguage extension0xE08ApriVisiCalc worksheet file[*] Data files are stored as Basic programs consisting only of DATAstatements.For all of these files:- There is no way to determine the actual file length from the headeralone: you must parse the file.- The miscellaneous data field contains these values:00x8010x012password char 13password char 24password char 35password 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 themiscellaneous data field.  A password of four space characters meansthat the file is not private.Formats:-75* files share a common header:startinglengthoffsetin byteswhat02pointer to the next directory entry22file length in bytes - 1841file type51file id letter64date/time created108file name (space characters on disk)1810?? (NUL characters on disk)Also, all -75* files look a lot like tokenized Basic programs.0xE051array of byte?0xE052In these files, the file type of a text file is 0xBE and thefile id letter is 0x54 ('T'). These files are a sequence oflines, with each line of the form:byte 0low byte of (line number in BCD)byte 1low byte of (line number in BCD)byte 2number of characters in line + 1byte 3space character (decimal 32)bytes 4..ntext bytesFor example, line 1234 with the text "abc" would look like:decimalchar524(0x34)18^R(0x12)4^D32 97a98b99cThe maximum line length is 126 characters.  The end of thefile is indicated by an illegally-high line number of:0x990xA90x02the threee bytes starting here may not be required0x8A0x0E0xE053don't know this format0xE088(This document describes DATA files only.)  In these files,the file type of a data file is the same as that of a Basicfile, 0xFE and the file id letter is 0x42 ('B'). These filesare a sequence of lines, with each line of the form:byte 0low byte of (line number in BCD)byte 1low byte of (line number in BCD)byte 2length of rest of record in bytes + 1Real numbers have a length of 11 and are encoded in this form:byte 00x86byte 10x04bytes 2..9number in -71B formatbyte 100x0EIntegers have a length of 6 are are encoded in this form:byte 00x86byte 10x1Abyte 2low two digits of number in BCDbyte 3middle two digits of number in BCDbyte 4high two digits of number in BCDIntegers may be in the range -99999 to 99999.  Positivenumbers are stored as themselves.  Negative numbers are storedas 1,000,000 - the absolute value of the number.Strings have a length of 4 + the number of characters in the stringand are encoded in this form:byte 00x86byte 10x05or,"-ed string constantbyte 10x06or,unquoted string constantbyte 10x96'-ed string constantbyte 2number of characters in the stringbytes 3...n-1text bytesbyte n0x0EThe maximum string length is 251 bytes.NaN's have a length of 11 and are encoded in this form:byte 00x86byte 10x04byte 20x11byte 30xF0bytes 4..90x00byte 100x0EThe end of the file is indicated by an illegally-high line number of:0x990xA90x020x8AEND statement0x0E0xE089array of byte?0xE08Astandard VisiCalc?========== Logic Analyzer File Types ==========These notes apply to the HP 1653B logic analyzer and may apply toother logic analyzers.From Alexander Pruss (arpruss@gmail.com):I believe that on all the HP 165xx logic analyzers (certainly this istrue on mine, and it fits with a disk image I've seen for a 16500),all files are stored in the 256 byte blocks of the LIF filesystem witha two byte header in each block specifying, in big endian format, howmany bytes of the block are used. In practice, this means that everyblock except the last one starts with 0x00FE, and then the last onestarts with length % 254. In my analyzer's ROM code, the file readingand writing routines handle this transparently: when you call the filewriting function, the headers are added and when you call the filereading function, they are removed and you just get the data. But ifyou write code for a PC to read and write the LIF archives, you haveto handle this yourself.

Areas

General

Craig's Articles

 

Google

 
 

I amCraig A. Finseth.

Back to Home.

Back to top.

Last modified Sunday, 2026-02-15T19:53:10-06:00.


[8]ページ先頭

©2009-2026 Movatter.jp