+++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + DHOS EII File Structure Format Specification + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + DHS 1 - version 1.0 - released 10/10/1998 + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + By: Jonathan Kaus + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Section 1 ========= This section will give an overview of the specification, along with any information necessary for understanding it. Section 1.1 ----------- This specification describes the way that the Doomsday Horizons Operating System uses the E2 to store data and files. This is completely **incompatible** with the way the original E2 driver for Usgard and ZShell uses the E2 for storage!! Perhaps an Usgard/ZShell program will be created to use this format so that things can be pretty well standardized, but as of yet, no such driver is in the works. Section 1.2 ----------- Any comments or suggestions about this specification, or any other files about the DHOS can be directed at either the Assembly-85 or Shell-Developers Lists at Ticalc.org, or the author himself at kaus@cybrzn.com. Preferably, among the two lists, send to the SD list instead of the A85 list, becasue if large threads of non related material are posted on A85, (Brian Rabaler's idea of non related material :) Brian gets mad. Section 1.3 ----------- This specification is in a quasi-BNF format. If you do not understand BNF, you still may be able to understand the document, it is not that complicated. If you do not, there are many places on the net that can teach you the BNF style. Alternatively, you could get someone to explain it to you (the author might be one), or wait for a translated version is released (I do not know if this will be done). Section 1.4 ----------- Because this specification is in a *Quasi* BNF format, I will go over the format I have used within. Section 1.4.1 Object ::= ... Each object (on the left) is defined by the form on the right. In the above case, each Object is a string of a variable number of other objects. Section 1.4.2 Object ::= | An object can be defined as either one object -or- another, signified by the vertical bar. Section 1.4.3 Object ::= ( ) | ( ) Paranthesis can be used to group objects together. Section 1.4.4 Object ::= $FFFF By not using the angle brackets around a token, the token can be a literal value. Section 1.4.5 Object ::= ($0000 = End of data) Object ::= ( = At the beginning of a data stream) An equal sign can be used to show the meaning of a token. Usually the token and meaning are grouped by parantheses for clarity. Section 1.4.6 Object ::= Within any nonliteral token, a size value may be used to show the size of the token. The actual token follows the colon. Section 1.5 ----------- Each left-justified object has a number to the left of it, which represents its size in bytes. Any alphabetical character in this position represents that the size is variable. What the character represents will be included as a note (indicated by a **n**). Section 2 ========= This section contains the actual protocol for the EII File Structure Format. Section 2.1 ----------- 264 Page **1**::= (| ($0000 = Last Page in chain)) (|) x **2** Data File ::= 20n+2 **3** Directory File ::= 20n+2 **4** Directory Entry ::= ( ) | ($FFFF=No more files in directory file) 26 File Entry ::= (| ($0000=No Pages in chain **5**)) <8*BYTE: Null Padded Filename> <4*BYTE: File Information Field> 4 File Information Field ::= 1 Type Of File ::= |||... **8** Section 2.2 ----------- This Section explains the notes that are referenced in the above specification. Section 2.2.1 On the EII, each page is 264 bytes long, and depending on the size of the E2 memory module (currently on 512K), there are various numbers of pages. For the 512K version, there are approximately 2000 pages. Also, the first page is begins the root directory file for the E2. Likewise, the first file entry in the root directory is considered by the DHOS BootStrap Loader to be the actual kernal module file. Regardless of what is put here, the BSL will load and execute it as though it were the kernal. This is not written into the specification so that if a driver is written for the other OS's that do not use a loadable kernal module, it is not there to clutter things up. Section 2.2.2 The size of the data of a given file is unknowable by this specification, and therefore is represented as 'x' to show this unknowability. Section 2.2.3 The 'n' in 20n+2 is the number of file entries in the directory file. Section 2.2.4 This 'n' is the same as above. Note that I wrote the size of the directory entry to be the same as the size of the directory file. This is because the directory entry object is recursive and therefor does represent the entire directory file. Section 2.2.5 If there is a 0000 in the first page in chain field, it means that the file is 0 bytes long and to save space does not use any pages. Otherwise, an entire 264 byte page would be used up by the empty file. Note however, that if the size grows to one byte, a page will be used, and thence wasting 263 bytes. Section 2.2.6 Local Access Rights is a byte that determines the rights given to the file. A system file, for example, is given a Protected, System attribute, so that it can not be deleted. Other bits represent different attributes, not yet derermined. Section 2.2.7 Remote Access Rights is a byte that is similar to the Local Access Rights, except that it is for networking applications (e.g. a file may be protected against remote deletion, but not against local deletion.) This will not be fully implemented until the Networking parts of the kernal are written and implemented. Section 2.2.8 The File Type byte is how the OS knows what type of file a given file is. This allows it to protect against executing data or text, etc. More types will be developed and designated a byte value for this field as the need arrises.