> # A Grail Millennium Project

> # White Paper

> History | Preface | TOC

> ##### This document is maintained by the author, Lewis A. Sellers, somewhere in the mountains of East Tennessee, the United States of America. It is an informal technical document for a works in progress project called Grail Millennium, or fully, The Minimal Operating System of Object Class Interfaces Holy Grail for the Millennium. In other words, for a new, easy to use, long-lived operating system.

> ## Copyright Notice

> ##### This document and all material therein, unless otherwise stated, is Copyright © 1995,1996, Lewis A. Sellers. All Rights Reserved. Permission to distribute this document, in part or full, via electronic means (emailed, posted or archived) or printed copy are granted providing that no charges are involved, reasonable attempt is made to use the most current version, and all credits and copyright notices are retained.

> ## Distribution Rights

> ##### All requests for other distribution rights, including incorporation in commercial products, such as books, magazine articles, CD-ROMs, and or computer programs should be made to the primary author Lewis Sellers.

> ## Warranty and disclaimer

> ##### This document is provided as is without any express or implied warranties. This is a work-in-progress, and as such will contain outdated or as yet uncorrected or substanstiated assumptions. The author, maintainer and/or contributors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.

> ## WWW Home Sites

> ##### You can currently find home sites to this project at
> - http://www.dwc.edu/grail/
> - http://www.usit.net/public/bcannon/grail/
> If you can not reach them, or they seem to be down, do a key word search on AltaVista, Lycos, or the Web Crawler search engines.

> ## Contact Email

> ##### The primary author of Grail Millennium should be reachable at lsellers@usit.net.

> Preface | TOC

> # OCI/Spec | DISTRIBUTED LONG-TERM MEMORY

> ### DESIGNER

> Lewis A. Sellers (aka Minimalist) lsellers@usit.net

> ### CRITIQUED BY

> - Anis Ahmand bq689@freenet.carleton.ca (pre v0)
> - Cleo Saulnier p8uu@jupiter.sun.csd.unb.ca (v0)
> - Bryan Hanks bhanks@sunfse.ese.lmsc.lockheed.com (v1)

> ### DRAFT

> - August ? 95 revision 0 - .31
> - 2/10/96 revision 0.40
> - 7/31/96 revision 0.50

> TOC

> # (a0.50)

> # Table of Contents

> Legal Notices | Who gets sued and why
> History | Changes and who made them
> Preface | About this document and the people that make it

> Overview |

> TOC

> # An Overview of the Non-local Virtual File Systems

> BY | Lewis A. Sellers lsellers@usit.net

> As stated in the main Filesystem Document, the file system used by Grail pertains to every device that contains files or that has an aperture through which they may be accessed. In general the Grail looks upon files the same way whether they exist on your system or someone else's and whether they are formatted for Grail or some other operating system.

> Grail is currently bound with the device objects and device object reinterpreters to handle, in addition to itself, the DOS, WIN95 DOS and UNIX filesystem extensions and well as communications through the serial port (NULL-modem), hayes-protocol compliant modems, IPX Networks and TCP/IP ISDN and TCP/IP PPP dialups. Grail treats the differences between filesystems and communications protocols roughly the same.

> Local

> Non-local

> Foreign File Systems

> INTERFACING WITH NON-LOCAL FILESYSTEMS

> When through a non-local filesystem interface you move through filespace, tokens are created on your systems representing the non-local systems observed in filespace.

> Say for instance you visit ftp.cdrom.com (Walnut Creek Software) looking for new and exciting programs to download. Grail will create non-local/ if it has not done so already, then it will created non-local/ftp.cdrom.com/. Typically, since you have come in at the top level it will then create a folder for every subdirectory at their site and a token for every file, such as:

> `/non-local/ftp.cdrom.com/ ;folder`

> `bin/ ;folder`

> `pub/ ;folder`

> `readme.txt ;token`

> While the concept of recreating non-local filesystems on your on system may sound a bit distressing at first, don't worry about it too much. All recreations occur in the virtual subroot non-local and all true files have only a token of their existence stored unless your software transfers them. This applies no matter what the source or the means of connection. When you are connected to computer systems that may not present a decernable filesystem (such as most current BBSes) then you must declare it's proper name to be used and all files are grouped into a single common folder. Take for instance, The Other World BBS, which ran under Major BBS software. The folder /non-local/The Other World BBS/ would be created and used.

> See the section on NON-LOCAL FILESYSTEMS for more detail.

> Well, ok. But I also heard file transfers were... unusal.

> They are different to be sure. Not only are hard drives, floppies, CD-ROMs and Tape-drives part of the filesystem, but modems, ethernet cards, etc. All non-local files and folders are by default mirrored through tokens onto your filesystem. As to what that means, say you FTP to ftp.cdrom.com down into /pub/demos/songs and do a directory. Depending on how you have your system setup, Grail would probably create the folder path /ftp/ftp.cdrom.com/pub/demos/songs/ and fill it with token file bindings based on the directory information it got back. If you transfered a file from them the token would be replaced with the actual file.

> Thus, there is typically no such thing as a disk cache under Grail, and you never have to fiddle with deciding where to put a file, etc. No download directories. It handles itself.

> All transfered files have an extra attribute which in effect gives them a life span and makes them easy to purge enmass if you need more space. Unless you specifically increase a file/folders lifespan or make it permanent it will eventually disappear after a certain amount of time or if disk space drops too low. This attribute is called transience. The files are typically called virtual files.

> There was some concern about using path-less BBS systems with Grail. In general, if you interface with a location such as a BBS that does not provide folder or directory path information, they use one common folder for all files. For instance, say you connect with the Otherworlds BBS. You might have a folder path created such as /bbs/OtherWorlds BBS/.

> You can of course, BTW, transfer not files, but streams of data through communications devices, if you so desire.

> FOREIGN FILESYSTEM INTERPRETATION

> Wanting to transfer all your precious data from some other operating system to Grail? That's not much of a problem. Grail's file system is pretty accomodating. If you missed it, filenames can be up to between 2 and 4 billion characters long under the Intel version of Grail. Yes, I said Billion, as in B. If you wanted to you could put the entire contents of The Bible as your filename. :) On 64-bit machines, it's even more, as if you really need it. The point is: don't worry about the conversion. You won't lose anything.

> Grail can read from both the DOS and WIN95 filesystems as well as UNIX EFS. And hopefully, soon, even the Mac Filesystems (who's actual wide-spread use of a two fork filesystem helped in a small, but important way in the shaping of the Grail FS).

> There are two ways to go about the translation. You can once and for move the file into Grail filespace, or you can have Grail pretend this other filesystem is its. If you're going to be using the file much, you might as well move it into Grail space. When accessing foreign filesystems even on your own computer, Grail creates a folder in the local/ folder with the name of this DOS or whatever file partition. It however creates local token files, as opposed to non-locals and thus does not take up to much extra space.

> DOS

> See WIN95.

> WIN95

> The main difference between the DOS and WIN95 filesystems is that WIN95 has added a somewhat ungainly cludge to add support of up to 255 odd characters for a filename. Grail supports DOS and WIN95 through the same interrpreter.

> The translations are fairly staightforward. The main part of the file is stored in the data branch and all of it's attributes and its filename are placed into it's binding and associative branch. Names are translated directly as is so the filenamed "MYCAT.TXT" will remain "MYCAT.TXT" even though dot-extensions look pretty silly under Grail. On that point, the interpreter will classify a program based on those extensions. File with a ".TXT" extension will be classed as Plaintext/ASCII. All ".COM", ".EXE",".DLL" and ".VBX" will be classed as objects/corrupt, by the way. All Images

> Plaintext/ASCII files have their 10, 13 newline sequences stripped out and replaced with a simple unixy 13, which is also what Grail uses.

> UNIX

> ***

> Modem

> IPX

> Dailup PPP Internet Connect

> ISDN Internet Connect

> ***tokens

> 1

> application

> high-level protocol

> protocol

> device object

> Click here for Picture

> **device object

> __MODEM

> __ETHERNET

> __ISDN

> **protocol level

> **fs level

> **

> HOW DO I REFER TO FILES (or FOLDERS)?

> As said, there is is the main root folder (top most heiarchy of the entire system) and the sub-root folders (top heirarchy on each filesystem device) and then finally the normal folders. All may contain files. To make interfacing with other filesystems easier, Grail has adopted a routing and referencing system similiar to UNIX and the URL (Uniform Resource Location) syntax. When referring to a file you must first declare it's general location: Is the file local or non-local?

> To access local files you can use the prefix "local:" or no prefix at all. To access non-local files the prefix is "non-local:". When using

> The root is always called ROOT. If you wish to refer to a file called test_file_1 in the ROOT, it would be:

> /ROOT/test_file_1

> Sub-roots have their own names which reside in the ROOT filespace along with all the system files and system folders. You refer to the file test_file_1 in the sub-root drive3 as:

> /ROOT/Drive3/test_file1

> And so on.

> local (or file):

> Forces a referal to local filespace. These files are typically fairly secure and safe.

> non-local (or ftp):

> Forces referal to a non-local filespace. The term is currently synonomous with ftp.

> When through a non-local filesystem interface you move through filespace, tokens are created on your systems representing the non-local systems observed in filespace.

> Say for instance you visit ftp.cdrom.com (Walnut Creek Software) looking for new and exciting programs to download. Grail will create non-local/ if it has not done so already, then it will created non-local/ftp.cdrom.com/. Typically, since you have come in at the top level it will then create a folder for every subdirectory at their site and a token for every file, such as:

> `/non-local/ftp.cdrom.com/ ;folder`

> `bin/ ;folder`

> `pub/ ;folder`

> `readme.txt ;token`

> While the concept of recreating non-local filesystems on your on system may sound a bit distressing at first, don't worry about it too much. All recreations occur in the virtual subroot non-local and all true files have only a token of their existence stored unless your software transfers them. This applies no matter what the source or the means of connection. When you are connected to computer systems that may not present a decernable filesystem (such as most current BBSes) then you must declare it's proper name to be used and all files are grouped into a single common folder. Take for instance, The Other World BBS, which ran under Major BBS software. The folder /non-local/The Other World BBS/ would be created and used.

> See the section on NON-LOCAL FILESYSTEMS for more detail.

> TOC

> # About Modems

> BY | Lewis A. Sellers lsellers@usit.net
> The bound object class is __MODEM, with a hayes protocol object __HAYESPROTOCOL.

> `__MODEM_Aquisition`

> `__MODEM_DeviceInformation`

> `__MODEM_Status`

> `__MODEM_SetupEnvironment`

> `__MODEM_SetupDevice`

> `__MODEM_Operation`

> `**`

> `win1 = __METAPHOR_TextWindow_Open`

> `print __OBJECT_Function __METAPHOR, TextWindow_Print`

> `if __MODEM_Aquisition >0`

> `{`

> `(memory, accesstime, transferrate) = __MODEM_Information 0`

> `Print "Memory:\t",memory,"\n"`

> `Print "Access Time:\t",accesstime,"\n"`

> `Print "Transfer Rate:\t",transferrate,"\n"`

> `(avg_memory, avg_accesstime, avg_transferrate) = __MODEM_Information 1`

> `Print "Average Memory:\t",memory,"\n"`

> `Print "Average Access Time:\t",accesstime,"\n"`

> `Print "Average Transfer Rate:\t",transferrate,"\n"`

> ``

> `}`

> __METAPHOR_TextWindow_Close win1

> **

> DEVICE_Aquisition

> DEVICE_Device_Information

> Returns information about the device, such as it's memory capacity, speed, etc.

> Group 0: total memory, access time, transfer rate

> Group 1: Average total memory, access time, transfer rate

> Group 2: total memory, access time, transfer rate

> Group 4: total transfer output, input

> DEVICE_Status

> Returns the current mode or operation status of the device.

> DEVICE_Setup_Environment

> Configures and maintains the data structures on the system for the device.

> mode 0 device

> mode 1 exterior-filesystem

> mode 2 filesystem

> DEVICE_Setup_Device

> Talks to the device setting it up for various modes or operations.

> stream

> block

> DEVICE_Operation

> Performs the low-level read and/or write operations.

> mode 0 ?

> mode 1 read

> mode 2 write

> **

> Creation

> Places the interrupt handlers for COMs 1 through 4 into the Asynchronous Exception handler chain.

> Destruction

> Removes all COM handlers from the asynchronous Exception chain.

> Structure of Com List:

> flags

> partial/complete

> disabled/enabled

> null/IRQ handler

> number (COM1,etc)

> type (serial,etc)

> detection routines (cs:eip)

> read routine (cs:eip)

> write routine (cs:eip)

> max speed

> **

> Get Bufferspace Info

> USE: DX=0-3

> RETURN: AL= 2^n size of buffer setting

> Change Bufferspace

> USE: DX=0-3

> AL bytes allocated for buffer space as 2^AL

> AL represents the buffer space as 2^AL (ie 1,2,4,8,16,32,64,etc).

> This allows faster ANDing to pointer as it overflows. This space

> is allocated for both incoming and outgoing. Ie, DX=0 AL=6 means than

> 64 bytes are allocated for outgoing to COM 0 and 64 outgoing for COM 0.

> Flush Buffer

> USE: DX=0-3

> This sets the lastreadposition pointer to position.

> Wait on Buffer Empty

> USE: DX=0-3

> ECX maximum polls to wait for.

> Sits and waits till the out going and incoming buffers are empty. Use before a flush.

> Read Com Status

> USE: DX=0-3

> RETURN: ESI position incoming

> ECX lastread incoming

> EDI position outgoing

> EDX lastread outgoing

> _InitializeCommunications port,

> USE: DX=0-3 communcations port

> AL break (0/1)

> BH parity (0-4)

> 0=no parity

> 1=odd parity

> 2=even parity

> 3=stick parity odd

> 4=stick parity even

> BL stop bits (0/1)

> CH data length 0-8

> 7=7 bits

> 8=8 bits

> CL BPS rate

> 4=1200 baud

> 5=2400 baud

> 6=4800 baud

> 7=9600 baud

> 8=19200 baud

> ?=14400

> ?=28800

> ?33.6

> Com Control

> USE: DX=0-3

> AL 0=read

> 1=write

> if AL=1 BL=modem control register

> RETURN: AH port status

> AL modem status

> BL modem control register

> Read character from Com buffer

> USE: DX=0-3

> RETURNS: AL Character

> AH status

> flag c set if no data

> Places the next character in the incoming buffer into AL (assuming there is data waiting.) and increases the lastreadposition pointer.

> Write character to Com buffer

> USE: DX=0-3

> AL character

> RETURNS: flag c set if buffer full

> Readblock from Com buffer

> USE: DX=0-3 com port selected

> EDI pointer to buffer data is to be copied to.

> ECX the maximum size of the destination buffer. RETURNS: ECX no of bytes read from buffer.

> Writeblock to Com buffer

> USE: DX=0-3

> ESI pointer to data to be written into outgoing buffer space

> ECX size of data to be placed in buffer.

> RETURNS: ECX count of btyes wrote

> ESI pointer to last byte taken.

> flag c is set on error (buffer full)

> TABLE Port Status Bits

> 76543210

> .......1 Data ready

> ......1. Overrun error

> .....1.. Parity error

> ....1... Framing error

> ...1.... Break detected

> ..1..... Transmit holding register (THR) empty

> .1...... Transmit shift register (TSR) empty

> 1....... Timeout

> TABLE Modem Status Bits

> 76543210

> .......1 Change in Clear to Send (CTS) status

> ......1. Change in Data Set Ready (DSR) status

> .....1.. Trailing edge ring indicator

> ....1... Change in receive line signal

> ...1.... Clear to Send (CTS)

> ..1..... Data Set Ready (DSR)

> .1...... Ring Indicator (RI)

> 1....... Recieve line signal detected

> TABLE Modem Control Register Bits

> 76543210

> .......1 Data Terminal Ready (DTR)

> ......1. Request to Send (RTS)

> .....1.. Out1

> ....1... Out2

> ...1.... Loopback Test

> 111..... Reserved

> TOC

> # Network Cards

> BY | Lewis A. Sellers lsellers@usit.net

> TOC

> # ISDN

> BY | Lewis A. Sellers lsellers@usit.net